Should I redistribute msvcrt.dll with my application and use the private dll if some of the application's libs dynamically depend on msvcrt.dll? I.e. are any incompatibility issues possible with the system's msvcrt.dll (dll hell)? Application is targeted for Windows Server systems.
msvcrt.dll has become a defacto part of the OS distribution. On windows 98 and 95 and possibly NT4 it was possible to get OS installs without it if one went to care to strip apps like WordPad out of the installation.
Given its ubiquty however, and the fact that since those OSs very few app developers have bothered to ship it, at least since windows 2000 its been an official part of the OS.
Microsoft support has a tool that you can use to double check what products DLLs are shipped with.
Perform a search like this and you can see that msvcrt.dll vsrsion 7.0.3790.0 was part of the Windows server 2003 release.
msvcrt - is a dynamic library for the Microsoft Visual C++ runtime.
There are two options for using the C runtime in Windows:
link with static runtime libs.
Use either the/MT
or the/MTd
option to cl.exe. In this case, you will have no dependency on the msvcrt DLL, and therefore you will not have to redistribute it. In Visual Studio, right click on the Project or Solution, Properties > C/C++->Code Generation->Runtime library use Multithreaded and Multithreaded debug respectively. This is the easier way. The downside is that the resulting executable is larger.link with the dynamic C Runtime library.
You will use either the/MD
or the/MDd
option to cl.exe.
In Visual Studio, right click on the Project or Solution, Properties > C/C++->Code Generation->Runtime library use Multithreaded Dynamic Link and Multithreaded Dynamic Link debug respectively. This results in a smaller EXE, but the downside is that you must install the required MSVCRT when installing your application.
Each release of the VC++ compiler ships with a version of the C runtime (CRT). Visual Studio 2005 shipped with v8 of the compiler, and v8 of the CRT. The actual DLL for v8 was msvcrt80.dll. For VS2008, it was v9, and the dynamic CRT was msvcrt90.dll. But, the CRT is updated and patched more frequently than is the C/C++ compiler. A developer can download an updated CRT, and build against that.
If you compile with the dynamic CRT library, you MUST download a redistributable package for the necessary version of the runtime from microsoft.com and perform a (potentially silent) install of it during your app install.
Prior to VS2005, developers built apps to depend on the MSVCRT that was in the Windows operating system. This would give the benefit of the DLL (small image size) while not incurring the requirement of shipping the CRT DLL in the application install. Prior to Windoes 2000, developers would even install a new MSVCRT.dll in the \Windows installation folder. But, sharing the CRT across many apps and the OS too, turned out to be a really bad idea. With WinXP SP2, the CRT included with Windows changed significantly, and any apps that depended on that version of the CRT were at risk of breaking.
At this point Microsoft tells developers that the MSVCRT.dll that is included with Windows is part of the OS, and may be serviced or patched at any time. It is not supported to build an app against it. Therefore applications should use one of the methods above.
References:
You must ship msvcrt with your application. It is not a guaranteed part of the operating system. If a particular version of Windows happens to have it, it's only because something in Windows is using it.
Applications have broke when newer versions of Windows didn't happen to contain the binaries people assumed Windows came with. Applications have broke when the user chose not to install WinFax, which meant that msvcrt wasn't installed with it.
From Raymond Chen:
Depending on what version of Windows you're running, there may be a variety of support DLLs for things that aren't formal product components, but which are merely along for the ride.
...
This problem persists today. People go scrounging around the binaries that come with Windows looking for something they can remora. And then they're surprised when those binaries change or vanish entirely.
From KB326922 - Redistribution of the shared C runtime component in Visual C++:
...the CRT DLL is no longer considered a system file, therefore, distribute the CRT DLL with any application that relies on it. Because it is no longer a system component, install it in your applications Program Files directory with other application-specific code. This prevents your application from using other versions of the CRT library that may be installed on the system paths.
You must ship msvcrt with your application, if you link to MSVCRT.
Chris's answer shouldn't be voted down because both are right.
The matter is that there're two different sets of MSVCRTs. One set is the msvcrt80.dll, msvcrt90.dll, etc. which comes with Visual Studio. This is what people normally used. And they must be redistributed, as talked in other answers.
The other is the msvcrt.dll (with no numbers in the file name) in System32 folder, which is intended to be used ONLY by the OS itself since some time ago. And applications should never replace/reinstall it. However, some applications do link to it, for some reasons like to remove the extra dependencies to install. But be aware that it is not guaranteed to be available in future Windows version.