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.
Related
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.
I’ve got an app that creates a child process to execute via CLI a compiled C++ library file. What is the best/most portable way of shipping my app with this library? I just need to ensure the compiled C++ code is available on the user’s system and that the executable is compatible with their system.
C++ is compiled for each platform (Windows, macOs, Linux). So you need three different distributions:
Windows - lowest common version (for example Windows 7). You also need to require or include the C++ redistributable for the compiled library.
Linux - most use gcc, so again the lowest common version. No redistributable required.
macOs is similar to Linux.
Each platform supports multiple compilers and IDEs. It’s down to personal choice.
Could anyone shed some light on C++ library versioning and distribution of
GCC library (libgcc, libstdc++,..?)
Microsoft Visual C++ runtime libraries (6.0, 2005, 2008, 2010, 2012, 2013, 2015,....)
With my limited exposure to GCC programming, I have never seen C++ runtime libraries being distributed along with program. That is often the case with MS Windows programs.
Can a relatively old linux system run a newer C++14 program (which is compiled on a newer system and then copied over to old system)?
Do GCC programmers distribute runtime libraries along with programs? If no, Why do Windows programs distribute them? How GCC distributions ensure that a C++ program always works when installed?
What about the frameworks such as Qt, How does Qt handle versioning and distribution on Linux and Windows? Does Qt also distribute runtimes for different versions?
May be it has to do with platform, how Linux is designed vs How Windows is designed.
What is so fundamentally different in approaches GCC & MS Windows take?
GCC's runtime libraries, like GNU's C library, provide a stable binary interface (small footnote: GCC 5.1 kind of blew this up, due to new C++ features that had to be implemented).
Microsoft's libraries don't, and each little version difference may and probably will break the ABI (application binary interface).
Additionally, Microsoft compilers change their ABI with version increments as well, making it a bad idea to combine code built by different versions of their tools. Also here, GCC maintains a strict ABI, which makes object code perfectly compatible (if no ABI breaking codegen options are given of course).
This ABI consists of object size and layout, which a compiler uses when generating code. Therefore running code built against one version but using a different version at runtime may produce unexpected results because the memory layout and use is just different.
GNU/Linux is quite strong in this regard, and is generally able to maintain strong backwards compatibility.
As long as the compiled program was compiled against an older version of the library, it will run perfectly if loaded with a newer version that a user has installed.
The same story goes for Qt, which only breaks ABI between major version numbers (Qt 4 and Qt 5 cannot be loaded at runtime interchangeable).
There are some small exceptions, GCC 5's libstdc++ being a big problem there. I know of no big glibc ABI breakages though.
The new Microsoft Universal CRT attempts to solve this issue, by providing a stable C runtime interface and as the story would have us believe, provide a glibc style library ABI stability. This UCRT is available for Windows Vista and up, but applications need to be compiled specifically against this. The first version of VS that has this capability, is VS2015.
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).
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.