I'm installing GTA 5 and it's also installed Visual C++ Redistributables. This got me curious about something, because this happens a lot.
As far as I know, these are needed for linking to VC++ libraries, but I already have .NET 4.8 installed on my system.
I thought when C++ (managed) gets compiled to MSIL, it would then just use the standard .NET Framework libraries.
So essentially the question is, since the .NET Framework libraries are present, why do additional VC++ specific libraries also need to be installed?
Thanks!
Simple answer:
".NET runtime" is to C# as "Visual C++ runtime" is to C++
Explanation:
Applications written in C# or "managed code" require a specific version of the .NET runtime installed. The .NET runtime not only includes the interpreter for the virtual machine code, but also provides all the standard class libraries an application developer might reference in his code. Applications written in C# will need the .NET runtime installed on the target computer.
Applications written in C/C++ or a "native code" typically link with a set of libraries to provide the common set of functions and classes provided by the language standard (e.g. printf and std::string). The application developer can choose to statically link these functions directly into his EXE. But it's often advantageous to link dynamically with a DLL version of these libraries so they can be shared across the system or with binaries within the application. Hence, the redistributable package.
C++ compiles to native code and does not use the .NET runtimes. It uses the VC++ runtime (*), which can be either statically or dynamically linked. In the latter cases, this requires the VC++ redistributables.
(*) It is technically possible to build an application with VC++ that does not use the VC++ runtime at all, but that sacrifices language features and is not common.
Managed flavors such as C++/CLI compile to mixed mode assemblies, which still have an unmanaged part with the same requirements.
Related
I recently read that C/C++ runtime in windows has 2 parts. First is VC Runtime and other is Universal C Runtime.
As per my reading , Universal C runtime is part of the OS.
Question 1 : So does it comes with OS installation by default? Or has the Universal C Runtime to do something with Windows SDK i.e Windows SDK install provides UCRT?
Question 2 : If the UCRT is part of OS, then what supplies the VC Runtime?
Also, I read that platform toolset provides compiler, linker and standard libraries.
Question 3 : So platform toolset has nothing to do with C/C++ runtime (which is split in 2 parts)? Can we say that platform toolset and C/C++ runtime don't come as single unit on windows OS?
Please clarify.
Universal C runtime comes with the OS on Windows 10 (it's installed when you install the OS). On older Windows versions (Vista through 8.1), it is distributed through Windows Update. It can also be locally deployed with your app.
If your app supports an OS older than Windows 10, you need to think how you're going to distribute it. You can either include a copy of it with your app (this is the most common solution) or you can require the Windows Update for it to be installed.
You can read more about it here: https://learn.microsoft.com/en-us/cpp/windows/universal-crt-deployment?view=vs-2019
VC Runtime can be supplied in two ways: through Visual C++ redistributable packages installer, or deployed locally with your app. If you ship an installer with your app, you can have your installer also install VC Runtime packages. If you ship software that doesn't get installed, you will have to drop VC Runtime DLLs next to your application executable. You can read more about deploying with VC Runtime here: https://learn.microsoft.com/en-us/cpp/windows/redistributing-visual-cpp-files?view=vs-2019
Also, I read that platform toolset provides compiler, linker and standard libraries.
This is not entirely correct. It provides standard C++ libraries and runtime (also known as VC Runtime). Standard C libraries and runtime come from Universal C Runtime.
"Universal C Runtime" is, at best, peculiar terminology.
The C compiler comes with a standard library that you link into your code. The standard library provides all of the functions required by the C standard. It's up to the library implementor to figure out how to implement them.
The operating system provides services that are useful to programs: memory management, file system, display screen, keyboard input, mouse, whatever. It has its own interface, and code in the standard library uses it as appropriate.
Different operating systems have different ways of providing these services, so the standard library has to be written differently for different operating systems. But calls to the operating system are not necessarily written in C, which is why "Universal C Runtime" isn't really appropriate. For example, back in the olden days of MSDOS, calling the operating system meant setting some values in processor registers and then generating a software interrupt. That's generally not C code, although some runtime libraries provided a code layer so that you could do that without having to write your own assembly code.
We have a Visual Studio solution with about 90 projects. Most of them are built to DLL files, some are written in C++, others in C#. The projects communicate with each other via COM. We use tlbexp to generate TLB files of some C# projects (the ones that are referenced in C++ projects). And we use tlbimp to generate interop DLLs of the C++ projects. I did not completely dig into the topic, but I think, the interop files just define the interfaces of the C++ classes, to make them usable from other projects is that right?
Now, the question is the following: In order to upgrade the entire solution to Visual Studio 2015 and let it compile against .NET 4.6.1, I inspected the resulting assemblies using dotPeek by JetBrains. I can see, that all the C# projects are correctly using .NET 4.6.1, the C++ DLLs themselves are native and do not reference any .NET. Now, what surprised me was the fact, that dotPeek told me, the interop DLLs (which resulted from the C++ projects), were referencing .NET 4.0.
After a "wonderful" day of trying to make them reference .NET 4.6.1 and lots of research, I finally did not find any way to make the interops reference .NET 4.6.1. Is that even possible? My current guess is, that all interop DLLs generated like this reference just the basic .NET 4.0, just because it uses the same CLR as .NET 4.6.1.
Is that right? It should be possible to execute the assemblies on any system that has .NET Framework 4.6.1 installed, shouldn't it?
You are getting bad info from dotPeek. It doesn't tell you how it figured out what .NET version is targeted. It can be specific on a .NET assembly that's generated by a compiler. Because it automatically inserts a [TargetFramework] attribute into the assembly, it states what version of .NET you selected when you built the project.
But an interop assembly does not specify a .NET version, primarily because it isn't generated by a compiler. Note how you never specified a version when you ran Tlbimp.exe. And can't. All that dotPeek can figure out is that it targets .NET 4, cued by the metadata format. No way it can be more specific.
And it does not matter, since the interop library does not use .NET Framework features. The only point of the library is that your program can use the COM component features. So the version number that dotPeek reports just doesn't matter; any .NET 4.x framework can use the library.
You don't have a real problem.
Are the dynamic runtime libraries for Visual C++ (more specifically 2008) part of the Windows OS nowadays? I noticed that at least on Windows 8 you no longer need to ship these with your application or have the user install the redistributable package from Microsoft.
Is this true? If so, for what Windows versions and for what versions of Visual C++ does this apply to?
No, they've never been part of the Windows distribution. Deploying them yourself is a hard requirement.
It certainly may seem that they are. Starting with msvcrt.dll in the system32 directory, it has the same name as the C++ runtime dll in Visual Studio versions prior to VS2002 (VS6 and earlier). It is however a private copy of the CRT that is used by Windows executables. And protected by the File System Protection feature in Windows, preventing old installers from destroying the operating system.
It certainly often works by accident. There are many programs that need the Microsoft CRT so it isn't unlikely that the user has run an installer before that got the DLLs installed. Clearly you cannot depend on that common accident.
Similarly for Windows 8, the pre-installed Microsoft.VCLibs.110 package matches the package you need for a Store app written in C++. But that's for the same reason as above, Microsoft Store programs were also built with VS2012, just like yours. What's going to happen in the upcoming VS2013 is a bit muddy right now, we'll know soon.
In my opinion, the answer would be both: Yes and No.
Yes: More recent Windows OS are generally shipped with VC runtimes pre-installed (along with more recent versions of the .NET framework). It is because Microsoft uses the latest/newer Visual Studio before they release VS to the public (or even to MSDN subscribers). If not this way, whenever you install some application (legacy application or some downloaded application), the setup would anyway install the required VC++ runtime. Another way is through automatic updates.
No: In case where none of the above mentioned rules applies. Or, when the VC runtime shipped with a new service pack or a patch. You might have developed your application with newer patch/SP, and that must be installed (as Side-by-Side, of course).
Native exe!
that means my program can run easily without any requirement?
even if I use .net classes?
You know I want to write a program that is so light and I don't like to use C# or any other .net programing language because all of them need .net-framework 4.5.
Just think a 2.5 MB programm needs a +250 MB .netframework.
New Update - 12/01/2016:
It's almost 4 years ago when I asked this question. As you know Dotnet Native is announced. It's an interesting feature which compile IL into native code.
Compiling Apps with .NET Native
.NET Native is a precompilation technology for building and deploying
Windows apps that is included with Visual Studio 2015. It
automatically compiles the release version of apps that are written in
managed code (C# or Visual Basic) and that target the .NET Framework
and Windows 10 to native code. Typically, apps that target the .NET
Framework are compiled to intermediate language (IL). At run time, the
just-in-time (JIT) compiler translates the IL to native code. In
contrast, .NET Native compiles Windows apps directly to native code.
For developers, this means:
Your apps will provide the superior performance of native code.
You can continue to program in C# or Visual Basic.
You can continue to take advantage of the resources provided by the .NET Framework, including its class library, automatic memory
management and garbage collection, and exception handling.
Last I checked none of the .NET frameworks were 250+ MB! Yes, the offline installer for .NET Framework 3.5 SP1 is 231MB but it contains x86 and x64 versions of .NET 2, 3 and 3.5 sp1.
You should read this http://www.smallestdotnet.com for details on sizes of various versions of the installers.
Now on to your question:
Yes, It is a little annoying to have your clients install a big framework, even 20-40MB does get annoying. With .NET, the advantage is the ease of programming (In my opionion) compared to other Native options.
Your native options are:
MFC - You need only the VS runtimes installed, which is 1-2MB and is usually installed on newer pcs. Also, you can ship your application with the MFC libraries packaged into a dll which is again <2MB
The trade of here is you need to program in C++, the libraries overall are a very thin layer over the native libraries. and people have had harsh opinions about MFC. I've barely just tried it.
Win32 API - This is going all bare bones, and quite difficult, you could use C or C++ but you'd really have to know a lot about the Win32 API and how windows itself works (Stuff like windows messages, hwnds etc) Its not fun, believe me. But during deployment you would not need any external libraries.
There are tons more options, see here:
Native Windows Application Development Options
https://stackoverflow.com/questions/2711599/what-programming-language-should-i-use-to-create-small-native-windows-applicatio
Here are some links on MFC that might help:
Want to learn Windows Programming,some suggestions?
How do I decide whether to use ATL, MFC, Win32 or CLR for a new C++ project?
C++ MFC vs .NET?
https://stackoverflow.com/questions/557114/stick-with-mfc-or-go-to-net
you are able to create native exe by using c++ Win 32 projects.
Alas, nearly everything requires a download runtime library and even if you have one installed, you'll need to download updates for them almost continually. Even Microsoft C++ apps nowadays come with security updates that have to be installed if you've compiled your app with them.
But.. there is a solution of sorts. If you use C++, it has a feature where only the things you use are compiled into the final app. Normally, this would require linking with all the library dlls, but if you statically link with the library, you will end up with a single .exe that is as small as can be, and you will not need any dlls (as all the code contained in the library will be compiled into the .exe).
The benefits are debatable compared to dlls, but as MS has pretty much broken the idea of shared dlls in .NET (ie, you practically have to put all the shared dlls in the same directory as your running app, giving you a nightmare in maintenance if you have these shared dlls spread around all your apps) then there's not much of a difference anymore. Static linking is getting a little bit of a comeback and sounds like its what you want.
For modern C++ development, you'll probably want to take a look at Qt instead of MFC. Its a lot nicer to use and is cross-platform so you can run Qt apps on your Android or Linux platforms as well as Windows.
What's in MS Visual C++ runtime library? I mean, I googled it, and I always found things like help, app xxxx gives me MS Visual C++ runtime library error, with no explanation.
I thought that Windows C runtime libraries come with Windows? Not with VC++? Thanks.
EDIT:
First, thanks for answers. I thing now I have bad idea of runtime libraries in windows. I mean, the first part, that Windows internally has its win32 API and so, that's OK, I knew it. Also, that Win32API are from kernel and user parts.
But I always thought that functions like GDI are accessed as DLL (which I still believe they are). But I thought even functions like printf and so are in some windows file.
So, am I right, when I know get it that "simple" functions like printf need to be linked directly and than use only Kernel part of OS directly, and more sophisticated Windows API functions are linked as dlls, therefore ARE NOT distributed with compiler but with OS? And they subsequently access Kernel?
I mean, lets say GDI, I tell it to draw picture, it makes all the hard work in user mode and than call kernel function which puts it all in framebuffer?
And last thought, why is this even solved this way? I mean, if VC++ runtime is just layer between C and WinAPI, why cant VC++ call directly WinAPI?
This is an oversimplification, but it will give you the gist. The MSVCRT is a set of DLLs that implements parts of the C++ language. Functions like printf, memcpy and the like are implemented in these DLLs.
Every program that is compiled with a particular compiler and dynamically linked to the C++ runtimes must somehow have the correct version of the CRT binaries on the target machine. As a result, applications that ship to end users are often (usually?) also shipped with a package of these DLLs. This package is called a "redistributable" (or "redist"), and there is a different one for every combination of exact compiler version and target platform. For example, there are seperate and distinct redists for each of the following:
MSVC 10, 64-bit windows
MSVC 10, 32-bit windows
MSVC9, 64-bit windows
MSVC9 SP1, 64-bit windows
et cetera.
Yes, Windows usually "comes with" some version of the CRT. However, it comes with the version(s) that it needs in order to run the apps that shipped with Windows. If Windows and all it's apps were compiled in MSVC8 SP2 and your app is compiled in MSVC10, the CRT you require won't be present on the box simply because it's running Windows.
This is why its common practice to ship apps along with redists.
EDIT:
By way of Houdini like magic, I predict your next question will be "where do I get the redists?"
The answer is, from MicroSoft. Try a google search for "msvc 9 x64 redist" and you will find:
http://www.microsoft.com/downloads/en/details.aspx?familyid=bd2a6171-e2d6-4230-b809-9a8d7548c1b6&displaylang=en
A brief answer would be that the MSVS C/C++ runtime implements functions like malloc/free, stdio, iostream and some c++-stuff like dynamic_cast and exception handling. These differs between versions of visual studio, so there are different runtimes for different versions.
Windows ship mostly with a C API (the Win32 API) which rather different from the C/C++ standard library. The MSVS C/C++ runtime calls into this API to allocate memory, etc etc.
(I suppose some of the applications included with Windows are written with MSVS and in C++, so they do include the MSVS runtime for that version.)
Also, the runtime changes as new Visual Studio versions are released. A Windows release lasts much longer than that.
They are the libraries that implement the C and C++ standard library functions. Standard functions such as printf are implemented in these libraries.
The core Windows libraries only provide interfaces to system calls, i.e. the Win32 API, since that is all you need to build a full-featured Windows application. The VC++ libraries are mostly wrappers around this API, and are analogous to the glibc library on Linux.
As an example, malloc from the C library might in turn use the VirtualAlloc API to allocate memory.
Programs compiled with Visual C++ require a "runtime" - this is a bit of code that handles application startup/shutdown, memory allocation/deallocation, support for reading and writing files, etc.
This is not part of the operating system, and not part of the final application - Because all C++ applications can share it, by default the runtime is a separate installation.
In addition, each version of Visual C++ has its own runtime installer, because with each version there are slight differences and improvements in the way all this works. There are also different verisons of the runtime for different platforms (e.g. x86 and x64)
Hence, there are a number of "Visual Studio XXXX runtime installer (YYY)" downloads available from Microsoft, where the XXXX is the visual studio version (2005, 2008, 2010, etc), and YYY is usually "x86" or "x64".
Most applications that need the runtime will automatically install it if needed, so generally end-users are not very aware of these redistributables.