After browsing here and there, i have come to following conclusion
Visual Studio Platform Toolset - Compiler, Linker, Assembler etc which changes with each version of Visual Studio (mostly).
Note : If your project is built with previous version of Platform
toolset then it may not work as such with newer version of platform
toolset as they may be incompatible.
Runtime Library - A library which assists in running the code(program) you write by acting as an intermediary between Program and Operating system. It has various options like /Mt /Mtd /MD /MDd which stand for multithreaded static, multithreaded staticdebug, multithreaded dynamic, multithreaded dynamic debug respcetiviely
Note: All modules of your code must be using same Runtime to be
compatible i.e one module built with /Mt should be used with
application too using Runtime library as /Mt else there may be issues.
Am i right in my summary above? Or still i am not clear about this? Can anyone provide their inputs
I have googled, played tutorials and tried to consolidate all the information above. Not sure did i understand it or still having some bits and pieces missing.
SHARED ABOVE
The platform toolset consists of the C++ compiler (cl.exe) and linker (link.exe), along with the C/C++ standard libraries. Since Visual Studio 2015, the major version of the toolset has remained at 14, which means that projects compiled with Visual Studio 2019 or Visual Studio 2017 are ABI-backwards-compatible with projects compiled with Visual Studio 2015.
The Microsoft run-time library provides routines for programming for the Microsoft Windows operating system. These routines automate many common programming tasks that are not provided by the C and C++ languages.The C Run-time Library (CRT) is the part of the C++ Standard Library that incorporates the ISO C99 standard library. The Visual C++ libraries that implement the CRT support native code development, and both mixed native and managed code. All versions of the CRT support multi-threaded development. Most of the libraries support both static linking, to link the library directly into your code, or dynamic linking to let your code use common DLL files.
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.
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 need to modify the C runtime which ships with VS2010 because the 2010 CRT relies on functions released in Windows XP SP2, and I need to be able to deploy to Windows 2000.
Specifically, I need to remove any and all calls to EncodePointer and DecodePointer.
The source for the C runtime is included in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\src, so it seems like it should be possible to build the runtime after slightly modifying the source.
Oh, I don't need to be able to build the dynamic versions of the runtime -- static versions only. (I cannot rely on the user installing the CRT on their system either).
With VS2008 and earlier, there was a tutorial in MSDN describing how to build the CRT, but I can't seem to find it for 2010.
Is such a thing possible?
Here's an MSDN link. It looks like you have to do it yourself in VS2010.
You can use the following compiler and linker options to rebuild the MFC, CRT, and ATL libraries. Starting in Visual C++ 2010, scripts for rebuilding these libraries are no longer shipped.
If it is a option, I would consider using the VC++ 2008 toolset within VS2010 instead of building a custom CRT. The procedure is explained here.
"Oh, I don't need to be able to build the dynamic versions of the runtime -- static versions only."
Since you only need static linking, you can try this trick to provide implementations of EncodePointer and DecodePointer.
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?