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.
Related
Is there a reason (I guess yes but I try to discover it) to install 2019 redistributable when deploying a C++ application built with vc142 since applications seems to work perfectly with the previous redistributable package (coming with vc141)? I have in mind that both are binary compatible, but more than that, dumpbin /exports of msvcp140.dll and vcruntime140.dll from 2017 and 2019 redistributable produce the same output; file size are identical too.
Did I miss something?
Apparently there is no gotcha, the libraries are comptible, see : https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2019
The article states: "This reflects the fact that both the runtime libraries and the applications compiled with either version of the compiler are binary compatible."
Maybe there are performance related differences.
As vs 2019 supports later c++ standard than 2017, this leaves one to wonder how this is possible with the old runtime libraries. I guess the differences are all built into the main executable/dll and don't require any changes in the runtime dlls.
I'm using Visual Studio 2017 to develop console applications in standard C++. When installing VS2017, I can install both Win 8.1 SDK and Win 10 SDK. VS2017 seems to offer Win 10 SDK by default, but I keep coming across projects that are configured to use Win 8.1 SDK (e.g., MPIR or projects created in previous versions of VS). Thus, I'm wondering:
Which SDK is preferable to use for standard C and C++?
Can I safely link together libraries that use different versions of Windows SDK? E.g., can I have MPIR compiled against Win 8.1 SDK and call it in an application that uses Win 10 SDK?
This Microsoft page suggests that it usually doesn't matter which you use. In particular, it says,
When you deploy your application, you can link it with /MT option to completely avoid CRT related dynamic link libraries and in most cases you don't even need the redistributable run-time then. All the toolset functions are then present in your module and don't need any other dependencies.
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.
I have a C++ project that builds a .NET class library that targets the framework 3.5.
This project has been working seamlessly since ages and the classes can be used from, among others, C# applications. It was developed with Visual Studio 2008 Professional.
Now I need to migrate if to Visual Studio 2012 Professional. I have successfully converted the project.
I meet a first problem, which is that the target framework cannot be changed from the project Common Properties, the field is read-only.
I can work around this by editing the .vcxproj file to insert a TargetedFramework tag. The new version does appear in the Common Properties.
I am also able to add references to the .NET assemblies that the library needs (just System, System.Drawing and System.Windows.Forms). The class library compiles correctly to a Dll and I can see its content in the Object Browser.
Now if I try to use it in an application targeting a framework version below 4, I get the message
1>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.Targets(1605,5): warning MSB3258: The primary reference "MyClasses" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.
I can't see where an indirect reference could come from (my explicit references are to v2.0.50727, which seem to be the file version for 2.0/3.0/3.5).
Do you have any explanation ?
(Expanding on Hans's correct comments)
Visual Studio supports .NET multi-targeting for the C++/CLI language by launching older versions of the C++ compiler.
As a result, the language features are inextricably linked to the .NET framework dependency -- with the newer compilers (Visual C++ 2010 and later), you get C++11 and C++14 features and .NET 4, with the older compilers (Visual C++ 2008 and before) you get .NET 2, but very little C++11 support.
To control this, there's a Platform Toolset selection in the Project Properties, but some manual project file editing is also required.
The Visual C++ Team wrote a blog post about C++ Managed Multi-Targeting in Visual Studio 2010... for later versions, read the documentation on MSDN.
I own VS 2008 Pro, and would like to do compatibility testing with VS 2005's runtime MSVCRT80, but I do not want to buy it just for that. Is there a way to link against MSVCRT80 without getting VS 2005?
Thanks
Official support for native multi-targeting didn't appear until Visual Studio 2010, which allows you to select either v100 or v90 as your "Platform Toolset". There is no such feature in Visual Studio 2008.
There is a discussion here on how one can achieve the same effect in Visual Studio 2008, but it appears you need to have VS 2005 installed on your computer as well in order for this to work. It isn't going to work if you just have the runtime libraries installed because you need the proper version of the compiler and linker, which you'll only have if you install VS 2005.
On that note, I'm not really sure what you mean by "compatibility testing". If you compile your app against v90 in VS 2008, it's not going to work with the older versions of the runtime. You have to compile and link against the version you want your app to use.
Finally, consider whether it's really relevant or not. Since you must include MSVCRT with your application anyway, what's the advantage of trying to link against an older version of the runtime? Just include v90 and be done with it.
Links to a still-working (as of 11 Jan 2011) Microsoft download for Visual C++ Express 2005 can be found here:
http://apdubey.blogspot.com/2009/04/microsoft-visual-studio-2005-express.html
This should let you compile against the VS2005 runtime without having to buy anything.
(in case the blogspot article goes away, the link for the .iso is http://go.microsoft.com/fwlink/?linkid=57034).