What provids C/C++ runtime libraries?

Question

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.

Answer 1

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.