I've stumbled upon the issues with having the wrong MSVC run-time when linking or running apps written in C or C++. Because of that, I try to be exact on using the correct versions.
I see that the SDL (Simple DirectMedia Layer) library is pre-compiled with MSVCRT, which AFAIK is compiled with MSVC 4.2 to 6.0. Still, that pre-compiled library works fine with my apps compiled with the much later Visual Studio 2015 v14.
How come there are no issue with linking old MSVCRT with MSVCR140, e.g. SDL?
Is there a way to make a library be compatible with any greater Visual Studio compiler?
How is this solved with using other compilers, e.g. GCC or even on Linux or Mac?
Because the, let's call them vintage, runtimes are used so widely they're always there. But more recent runtimes, used by a newer Visual C++, might not be automatically present. Also, Visual C++ standardised on a single runtime library for some time, ensuring backwards compatibility with existing applications. Somewhere around Visual Studio 2012 this was dropped in favor of version specific runtimes.
You need to package your application into an installer that also installs the necessary runtime (or runtimes if you require more than one).
Linux applications are packaged (RPM, YUM etc.) with dependencies on runtime components. Basicaly the same as a Windows installer. Dependencies are either part of the package or satified by the distro. Linux shared libraries are versioned, multiple versions can be installed side-by-side and an applications can link against specific versions if required.
Related
I'm doing some experiments with Mingw-w64 and it works great compiling regular C code, linking to the Windows system MSVCRT.DLL C library. But, if I compile C++ code, then mingw's g++ links to what looks like the GNU libstdc++ library. Why? This doesn't happen with regular C binaries. I see commerical Windows software all the time including the Microsoft "C++ redist" package, which I guess matches the version of Visual C++ they use to develop their software. So it seems like there's actually no C++ library by default on Windows. I'd like to use the "system" C++ library and not use the GNU one if possible to reduce the size of the binaries mingw is compiling. But, I also don't want a separate C++ redistributable that needs to be installed. Am I stuck with the GNU library?
MinGW/MinGW-w64 build do use system standard libraries, that are part of Windows.
Visual C++ redistributable and runtime packages are only needed when sources are compiled with MSVC.
If your MinGW/MinGW-w64 build isn't statically linked you may need to ship libstd DLL files, but you can just put them in the same place as your .exe and/or .dll files, along with any other dependancy .dll files.
I actually love the fact that MinGW/MinGW-w64 builds don't need Visual C++ redistributable for several reasons:
The user doesn't need to install yet another Visual C++ redistributable.
The binaries are compact and don't depend on other Microsoft libraries except the ones in the operating system, which increases the chance of your software running well on different Windows versions.
Install (and uninstall) instructions (or installer code) are easier as the Visual C++ redistributable dependancy doesn't need to be installed. In fact you can even run your software as a portable app without installer.
I have following 2 questions wrt to Windows SDK and Platform toolsets and C/C++ runtime library.
a) What is the relation of Windows SDK with C/C++ runtime and platform toolset?
Is it correct to say that BOTH C++ runtime libraries & platform toolsets are provided by Windows SDK?
Since we mostly deal with Platform toolsets from within the Visual Studio project settings, so want to understand that whether under the hood does the Visual Studio controls the C++ runtime library and platform toolset versions by installing the required version of Windows SDK?
b) Another thing i wanted to clarify was that if it is correct to say one version of platform toolset can work with different version of Windows SDK OR these are totally unrelated?
eg. in my Visual Studio i see that 'Windows SDK version' is Windows 10 and Platform toolset is v142. Can i set the 'Windows SDK version' to Windows 8.1 and keep the toolset as v142? If yes, then what does it mean?
This is confusing me a lot and i can't seem to get the correct picture with so many different explanations from different people.
TL;DR: If you are using Visual C++, and use the standard REDIST instructions from Microsoft Docs, then these details shouldn't really matter to you.
With VS 2015 and later, the "C/C++ Runtime" has been refactored into three pieces:
UCRTBASE.DLL is part of the OS and serviced through Windows Update. There are 'down-level' versions of it included in the Visual C++ REDIST package, but generally you should think of this as the "OS" part. This is the "C Runtime". These headers, import libraries, and are in the Windows 10 SDK. You can find the source for it there as well C:\Program Files (x86)\Windows Kits\10\Source\<version>\ucrt.
MSVCP*.DLL This is the "C++ Runtime" library, basically stuff like std::vector et al. The headers, import libraries, and such are in the Visual C++ product. You can find the source to it on GitHub per this blog post.
VCRUNTIME*.DLL has the entry-points needed at runtime for the Visual C++ compiler language features.
There are also a few auxiliary libraries as well for specific scenarios:
VCCORLIB*.DLL is used for C++/CX extensions (a.k.a. /ZW)
VCAMP140.DLL is used for C++ AMP
VCOMP140.DLL is used for OpenMP
CONCRT*.DLL is used to implement C++11 <thread> on Windows XP (not used on newer versions of Windows; it's delay loaded if required)
See this blog post and this one.
Essentially the C runtime (the UCRTBASE) part is a simple extern "C" interface so the ABI is well-defined, and thus is usable with multiple versions of Visual C++ and even other compilers. Exactly which version of the UCRT you are using is therefore primarily depending on the OS and the Windows 10 SDK you are using via WindowsTargetPlatformVersion. You can applocal deploy UCRT as well per this blog.
The C++ Runtime (MSVCP*.DLL) includes a lot of inlines and exposed memory layouts, and historically there was a breaking change between between Visual C++ versions. That said, for VS 2015 Update 3, VS 2017, and VS 2019 the VC team has made a point of keeping 'binary compatibly' here meaning that if you have a static library that uses C++ std namespace components from a PlatformToolset of v140/v141, it will successfully link with a later version of Visual C++ up through v142. It's not clear that this will hold in the future, but it is true for this particular set of releases per Microsoft Docs.
The VCRUNTIME*.DLL needs to match the version of the Visual C++ compiler you are using to build the final link, so this is very much intended to match your PlatformToolset.
We have products that are built with Visual Studio 2013 With No Update. I would like to update our build machine to Visual Studio 2013 Update 3.
We release patches and hot-fixes for our products that contain a subset of the product's binaries. I am concerned about what will happen if I update our build machines and we produce a patch using them. A patched installation of our product would contain a mix of dlls and exes that are built with different versions of compilers and which are built against different versions of the Visual Studio C++ Redistributables.
Would the 2013 Update 3 version of the redistributable need to be redistributed with a patch?
Are different update versions of the redistrubutables compatible, and is this scenario supported?
Soapbox
A patched installation of our product would contain a mix of dlls and exes that are built with different versions ...
And there you already have a problem: Our policy is to always patch everything together. Each set of (our) C++ binaries that is distributed is fully self-contained, we do not do partial updates of any set of C++ binaries - too much chance something might break, independently of VC runtime issues.
(Of course if you have modules that are "firewalled" behind a C DLL API, that's something different.)
As to the Question
The way I understand the Microsoft C(++) Runtime libraries from 2010 onwards, they all get installed into "System32" and are versioned per major version, so normally one Windows system only has one single set of VS2013 Redist installed and available for all applications that use default settings (i.e. no messing with manifests and WinSxS).
This means that all VS2013 redistributable libraries must be fully forwards and backwards ABI compatible, so it should generally not matter if the build server has a different "minor" redist version than the customer machine. As long as all modules use the DLL VCruntime versions, there can only be one loaded into any process at any time, so all modules see the same that should be compatible.
Still, I think you would be doing yourself a favor to include the (newest) VCRedist into your patches to rule out any potential bugs caused by old versions that would only manifest on the customer machine.
The way the VCRedist is shared, you (or anyone else) don't guarantee much about its minor version anyway, so you might as well make sure that the client machines at least run minimal the version you're using.
I know that I have to distribute C / C++ runtime libraries along with my project. I am just wondering why Microsoft does not do that for us? I know that there is Visual Studio 6.0 runtime included in Windows but why there is no new one?
If somebody could give me a link to some explanation article. I am trying to google that without success for a while.
There is a C runtime included with Windows, msvcrt.dll. The MinGW gcc variation uses that library as its base runtime. Microsoft also builds programs that link to that runtime (for example, the programs that are part of the Windows installation).
While the msvcrt.dll that is part of Windows has the same name as the runtime DLL from VC6, it's not necessarily the VC6 runtime. Each new version of Windows has added functions to the msvcrt.dll and probably fixed some bugs.
The WDK used to include build configurations to link to msvcrt.dll (it looks like the last version of the WDK to support this was WDK 7.1). These build configurations also included some compatibility shims, such as msvcrt_win2003.obj, that allow a program built with such a configuration to run against the msvcrt.dll libraries included with older versions of Windows - adding support for newer exception handling and some newer APIs, for example.
I suspect there are various reasons that MS prefers that 3rd party programs link to runtimes that are not part of the Windows system files. A couple possible reasons:
it helps ensure that the 3rd party programs are not broken by a Windows update that includes a newer version of msvcrt.dll.
it helps ensure that 3rd party programs will run against the runtime DLLs that they were tested against (since presumably the 3rd party program's installer also makes certain that the appropriate MSVC redistributable runtime is installed).
I have written a game that uses GLUT, OpenGL and FMOD. The problem is that the binary won't run, unless Visual Studio 2008 is installed on the computer.
Why is this?
Most likely you're linking with DLL versions of the C/C++ runtime. Go to project properties -> C++ -> Code Generation, and set Runtime Library to not be one of "DLL" kinds.
Alternatively, you can link to DLL runtimes, but then you have to redistribute the runtime with your application.
MSDN has more information on various aspects of C++ application deployment: http://msdn.microsoft.com/en-us/library/zebw5zk9.aspx
Also, Dependency Walker (depends.exe) will show what libraries your executable depends on. It ships with some versions of Visual Studio as well.
You mean why is Microsoft Visual C++ 2008 Redistributable Package (x86) needed?
This package installs runtime
components of C Runtime (CRT),
Standard C++, ATL, MFC, OpenMP and
MSDIA libraries. For libraries that
support side-by-side deployment model
(CRT, SCL, ATL, MFC, OpenMP) they are
installed into the native assembly
cache, also called WinSxS folder, on
versions of Windows operating system
that support side-by-side assemblies.
Because they are not installed on all Windows by default, especially the ones that shipped before VS 2008.
Even for
cout << "Hello, World" << endl;
You need a library, which in this case the Standard C++ library.
Welcome to the wonderful world of application deployment.
Run the tool depends on your executable and it will tell you which DLLs you need to also copy along with your EXE.
This program can help you find what dlls (if any) are missing on the the computer that it won't run on
Only the release versions of the C runtime and the C++ standard library dlls are installed with Windows by default. Installing Visual Studio will additionally install the debug versions.
Make sure the version you're deploying is built entirely in release mode.
Try compiling in release mode, and make sure that all required DLLs are installed on the target machine. It works for me.
Do you have dependencies on debug libraries?