Should I redistribute msvcrt.dll with my application?

Asked 2/7, 2009 at 9:53 Answered 7/5, 2010 at 2:45

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.

Baram answered 2/7, 2009 at 9:53 Comment(1)

I'm not going to close vote because the existing answers are important, but readers should note that the question is underspecified. In practice, what you should do depends on which compiler you're using, e.g., with MinGW you have no realistic option but to assume that msvcrt.dll will remain a part of Windows. – Rhizogenic 16/2, 2015 at 4:55

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:

Mccarver answered 2/7, 2009 at 11:11 Comment(0)

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.

More

the decision was made to just give up and declare it an operating system DLL, to be used only by operating system components.

Although MSVCRT.DLL has been an operating system DLL for a long time, and has been documented as off-limits to applications, there are still a lot of people who treat it as a C runtime delivery channel, and those programs create a lot of grief for the product team.

You must redistribute the Microsoft Visual C Runtime with your application, because Windows does not ship with any Microsoft Visual C Runtime. There might happen to be a DLL called msvcrt.dll (which is not guaranteed), it is not the MSVCRT.

Shanleigh answered 2/7, 2009 at 11:46 Comment(12)

Opposite answers to the same question, both sounds reasonable, one is downvoted without any explanation. Which one is right ? Ian, does this still apply to XP / Vista ? – Disobey 12/8, 2009 at 9:34

Yes, it does. The Windows SDK doesn't indicate anywhere that Windows XP/Vista/Seven provides the MSVCRT as a binary you can use. Windows might come with some version of MSVCRT, but it's almost certainly not the exact version of the MSVCRT that you depended on. And Windows Update does not provide your customers newer versions of the runtime. Microsoft developer Raymond Chen's blog has a huge following, where he talks about things people do wrong. It is the correct answer, whether or not a downvoter wants to hear it. – Shanleigh 13/8, 2009 at 14:51

But is the Visual Studio 6 version of msvcrt.dll (the only one that is licensed to be redistributed) supported for more recent versions of Windows? – Rhizogenic 26/4, 2012 at 1:41

This is not correct. For at least 10 years now, msvcrt.dll has been a system DLL. – Throve 26/7, 2013 at 14:20

@DavidHeffernan And as such it is not guaranteed to be there. ("meaning that it is a system component owned and built by Windows. It is intended for future use only by system-level components.") If you want to use it, you need to ship it. If you assume it is, and always will be, present on the user's machine: you are doing it wrong. – Shanleigh 26/7, 2013 at 14:46

Sure it is guaranteed to be there. You try deleting it and see what happens. If you do manage to do so, it will come right back. Because it's a protected DLL. MS tell you not to use it, which is fine. But anyone shipping apps compiled with mingw simply ignore that. The mingw developers are in no position to grant re-dist rights for any version of msvcrt.dll. – Throve 26/7, 2013 at 14:50

@DavidHeffernan You're referring to a protected dll that exists. i'm referring to when it doesn't exist. – Shanleigh 26/7, 2013 at 15:44

@DavidHeffernan i don't have access to a time machine. – Shanleigh 26/7, 2013 at 16:39

Developers should check with a lawyer before following this advice. To the best of my knowledge it is not legal to distribute msvcrt.dll unless you are licensed to use Visual Studio 6, and even then you are only entitled to ship the VS6 version, not the Windows version. (This only applies to msvcrt.dll, not to msvcrtnn.dll.) – Rhizogenic 21/6, 2015 at 21:34

@HarryJohnston People should not confuse MSVCRT with msvcrt.dll. If your application relies on the MSVCRT, then you need to redistribute the appropriate version of the Microsoft Visual C++ Runtime that you were built with - which is never going to be msvcrt.dll (as that's a private dll that you'll never be able to link against) – Shanleigh 22/6, 2015 at 17:56

@IanBoyd: actually MinGW applications link against msvcrt.dll by default - they shouldn't, but they do. My concern is that people are going to assume that you're talking about msvcrt.dll when you say msvcrt. Perhaps you could spell it out - "Microsoft C runtime" instead of "msvcrt" ? And clarify that you mustn't ship msvcrt.dll even if that's what you're linked against? – Rhizogenic 22/6, 2015 at 21:18

From what I can see, @HarryJohnston has made a heroic effort all over this question to clear up the confusion between msvcrt.dll as a specific dll that's been shipped as part of Windows forever, and msvcrt to (confusingly) mean "some version of the c/c++ runtime that your program relies on, named something like msvcrtNN.dll or vcruntimeNNN.dll". Ian Boyd, it seems clear that the OP was asking about the specific DLL msvcrt.dll, and the right answer is that you should NOT ship it. All of your text and protestation seems just to confuse by answering a different question from what was asked. – Inflate 6/3, 2018 at 11:50

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.

Malapropism answered 7/5, 2010 at 2:45 Comment(4)

You should never depend on the msvcrt.dll in system32. It is part of windows and is not documented or presumably tested for general use. One day it might disappear, or the function you need might change as part of a security update and your app will be busted. – Kidron 7/5, 2010 at 2:47

@Stewart: an incompatible function change is unlikely, I think, since it would break any applications built with Visual Studio 6. It might conceivably disappear, but only if installing the version distributed with VS6 would work (which seems doubtful). – Rhizogenic 26/4, 2012 at 1:45

The msvcrt.dll that comes (came?) with VC6 is/was not the same as the one that comes with windows. It happens to have the same name, but the one that comes with windows is an undocumented part of windows, not the CRT for VC6. You shouldn't ever use it. Of course you also shouldn't ever use the msvcrt.dll that came with VC6 either because it has been out of support for some years now and hasn't had all of its security bugs fixed. VC6 is nearly 15 years old now - you really should stop using it. – Kidron 26/4, 2012 at 14:14

@Stewart: applications built with Visual Studio 6, when run on modern versions of Windows, use the built-in msvcrt.dll. Microsoft are committed to backwards compatibility, breaking existing Visual Studio 6 applications is not an option for them. I don't recommend using msvcrt.dll (and really wish MinGW didn't do so by default) but in practical terms the 32-bit version, at least, is unlikely to ever disappear. – Rhizogenic 21/6, 2015 at 21:40

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.

Zermatt answered 2/7, 2009 at 11:3 Comment(5)

Microsoft has said straight out (support.microsoft.com/kb/326922) that msvcrt is no longer a system component. – Shanleigh 11/9, 2009 at 2:40

Except that they have included it in every version of windows since 95 and even today notepad.exe still depends on it in windows 7. – Impost 4/8, 2011 at 17:32

@IanBoyd: as I read it, that article is talking only about msvcrtnn.dll, not plain old msvcrt.dll. – Rhizogenic 26/4, 2012 at 1:37

@rogerdpack: it's incidental and not to be relied on, much like MFC or even .Net. – Rubin 22/8, 2012 at 23:36

First retail version of Windows 95 (4.00.950 without 'a', 'B' or 'C') doesn't have this file. – Boutte 11/7, 2017 at 22:43

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags