Microsoft Visual Studio ~ C/C++ Runtime Library ~ Static/dynamic linking

Question

I am a Microsoft Visual Studio user. My question is about the \"C/C++ Runtime Library\".

I created an \"Empty Project\" with a \".cpp\" source file \"main.cpp\" cont

Answer 1

Here goes nothing... please chime in if you find a mistake.

1. Is there a difference between "C/C++ Runtime Library" and "C/C++ Standard Library"?

Yes and no. Sometimes people use runtime library to mean everything and ignore standard library altogether (for Microsoft tools). However, technically, the runtime library is loaded at runtime, so it includes the pair .lib (import lib) and .dll. See here for details: http://msdn.microsoft.com/en-us/library/vstudio/abx4dbyh(v=vs.100).aspx

Technically, the libc* are standard libraries and the *crt are runtime libraries.

2. How do I know if the "C/C++ Runtime Library" library is statically or dynamically linked to the project?

If you're using the IDE (VS2010, others are similar), this is in project properties:

-  configuration properties
        - c/c++
               - code generation
                      [Runtime Library]

3. How do I know where this library is located in the filesystem?

The lib files are in the lib dir of your sdk (if you installed a later windows sdk) or the Visual C++ directory.

4. In case, the "C/C++ Runtime Library" is dynamically linked to the project, how can I know which ".dll" is used and where the used ".dll" is located in the filesystem?

You can figure out which ones are used by using the depends tool. http://www.dependencywalker.com/

The DLLs are somewhere in the Windows directory. They move them around and it's now in funky places with manifests and stuff to keep track of version. I wouldn't worry about this too much. If you have to worry about this, something's probably wrong. For details: http://msdn.microsoft.com/en-us/library/windows/desktop/aa375365(v=vs.85).aspx http://en.wikipedia.org/wiki/Side-by-side_assembly

If this is a concern, you can bundle a redistributable package with your installer: Difference between Visual Studio Redistributable and Visual Studio SP1

5. Suppose that I statically link the "C/C++ Runtime Library" to the project, can I be sure that the executable generated from the source code will work on all Windows Platforms (XP/Vista/Seven/..., 32 bit/64 bit)?

Yes, if you link statically, then you're safer in terms of not being able to find the dll. However, this makes your executable larger. There are other consequences in terms of behavior... It's difficult to enumerate, but the difference comes from the fact that the library is in a dll vs compiled into your exe.

6. What are the advantages/drawbacks of dynamically linking the "C/C++ Runtime Library" to the project?

Why use dll:

a - size. smaller exe size because all the library stuff is in the dll which are supposed to have been installed already on the user's system, although this is sometimes not true.

b - If there are bugs in the runtime, Microsoft can push a new release down to the user. You don't have to deal with it. If you statically link, you have to push a new exe to the user.

Why not to use dll:

a - many issues with dealing with dll. If you forget to bundle the redist, many problems can show up.

b - having more dlls to load and unload causes slower start up and exit time.

Probably other reasons that I haven't thought of...

7. Should the "C/C++ Runtime Library" rather be statically or dynamically linked to the project?

It really depends. I personally prefer statically linked. I hate scrambling around looking for the right redist/dll/etc.

Answer 2

The term "C/C++ Runtime Library" doesn't mean anything, it is roughly the name of a project setting in the IDE. Project + Properties, C/C++, Code Generation, Runtime Library setting. There you can choose between /MD and /MT.

With /MD, the default setting, your program will be using the DLL version of the runtime libraries. On your machine they were copied into c:\windows\system32 and/or c:\windows\syswow64 by the Visual Studio installer. And you've got copies of them in the vc/redist subdirectory of the VS install directory, there for you to use when you create an installer for your program. Three versions of them, x86 for 32-bit Intel processors, x64 for 64-bit Intel processors and arm for ARM processors. Pick the right one based on the Platform you selected in your project.

The relevant DLL names are:

• msvcr110.dll : the C runtime library (memcpy et al)
• msvcp110.dll : the C++ standard library (std::string et al)
• vccorlib110.dll : the runtime library for Windows Store applications
• vcomp110.dll : the runtime library for OpenMP (see #pragma omp)
• atl110.dll : the runtime library for ATL projects
• mfc110*.dll : runtime and localization libraries for MFC projects
• vcamp110.dll : the runtime library for AMP projects

On your machine, you've also got the debug builds of those DLLs, copied to the Windows directory by the VS installer. They have the same name with the letter "d" appended. Useful only to debug your code, you can't redistribute them. The corresponding Runtime Library setting is /MDd.

Most C++ projects only need msvcr110.dll and msvcp110.dll, you'd know when you opt in to use the other libraries since there are specific project templates and settings for them.

A simple way to get all of these DLLs installed on your user's machine is to use the prebuilt installer. You can download it from here (note: current only as of today, this may change when a service pack or update becomes available). Or you can simply copy them into the same directory as your main EXE.

You can avoid taking a dependency on these DLLs by changing the Runtime Library setting to /MT. In which case the runtime support code is linked into your program and you'll have only a single EXE to deploy. It will of course get bigger when you do so, sometimes significantly so, especially when you use MFC.

Using /MT is risky if you create DLLs as well as an EXE. You'll end up with multiple copies of the CRT in your program. This was especially a problem with earlier versions of VS where each CRT would get its own heap, not so much with VS2012. But you can still have ugly runtime problems when you have more than one "errno" variable for example. Using /MD is highly recommended to avoid such lossage.

Your program will run on Windows Vista, 7 and 8. Support for XP is waning, you'll need VS Update 1 and change the toolset setting in the project from "v110" to "v110_xp" to create a program that still runs on XP. Some functionality is lost when you do so, associated with locale and thread-local storage, testing is required.