Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

While looking for an authoritative source for the missing Msvcr71.dll that is needed by a few old applications, I stumbled across the MSDN article Redistribution of the shared C runtime component in Visual C++. The advice given to developers is to drop the DLL into the application's directory instead of system32 since DLLs in this directory are considered before the system paths.

What can/will go wrong if I (as an administrator, not a developer) decide to take the lazy path and install Msvcr71.dll (and Msvcp71.dll while I'm at it) into the system32 directory (of 32 bit Windows XP or Windows 7 systems) instead of putting a copy in each application's directory? Is there another good solution to provide the applications with the needed DLLs that doesn't involve copying stuff to the application directories?

added after first answers: I understand that incompatible API changes may have been made to the mentioned DLLs, but pretty much every mention of incompatibilities I have found using Google had to do with games or video codecs. Right now, I expect that the risk of breakage is pretty small. Am I missing something?

share|improve this question

migrated from serverfault.com Jan 2 '11 at 17:34

This question came from our site for professional system and network administrators.

3 Answers 3

up vote 5 down vote accepted

The main (only?) problem is compatibility between different versions of Msvcr71.dll. Let's say 7.10.0 is slightly incompatible with 7.10.1 and an application App1 depends on the old behavior and an application App2 depends on the new behavior. Additionally both applications do not ship this C++ runtime itself. In this case one of the two applications will fail.

How often are those cases? I don't really know, but I'd say they are seldom.

Depending on the differences between msvcr71.dll versions an application would fail to start or a particular feature would not work.

Another good solution: own PATH for each application. For example, you could write a batch like this:

PATH=c:\PathToMSVCR71.DLL_Version_7.10.0
myapp1.exe

This way you can reuse the same DLL in multiple applications and update it easier.

EDIT It is almost impossible to estimate the danger of a version collision especially as you have not mentioned the applications you use. That is why I have searched for all the different versions on my PC (Windows 7/x64). I have found the following files: alt text

All the files are just copies of these two: 7.10.3052.4 and 7.10.6030.0. 7.10.3052.4 is also what dll-files.com offers.

I have also compared the output of dumpbin /imports /exports msvcr71.dll for these versions and neither exports nor imports have changed (as expected).

share|improve this answer

"More Information" in the article you linked to says placing the CRT in system32 "may cause problems when you run applications that are linked to a different version of the CRT on computers that do not have the correct versions of the CRT DLL installed."

For example, let's say App1 requires version 2.1 of Msvcr71.dll for its SpinMyRainbowPinWheel function to work. The developers of App1 installed Msvcr71.dll in App1's program files directory.

If you come along and place version 2.0 of Msvcr71.dll in system32, App1 will start using the system file instead of what was installed in its program files directory. The SpinMyRainbowPinWheel function won't work anymore, and you'll gett a call from the CEO because the pinwheel isn't spinning on his monitor when he blows into his microphone. The business comes to a screeching halt!

share|improve this answer

Do not, and I repeat do NOT ever replace or add system wide DLLs. I don't understand why you can't just bundle it? That is why you create installer packages. I know Microsoft has a installation creation tool with VS6, and if you don't have it then you could use something like innosetup. And the reason why they tell you to put the DLL in the same folder is because that is where, afaik, the application looks first for the DLL.

Aside from that, two things come to mind:
1) The DLL may already be on the system in question
2) I'm sure Microsoft provides a setup package to install the necessary DLLs if they aren't present. Which is what I would recommended you use instead of just haphazardly replacing/adding DLL files.

A perfect example of why you shouldn't touch system wide DLLs is my experience with GTK. Different applications use different versions of GTK. I remember one application decided to be "lazy" and install a system wide DLL for GTK. The other applications that used GTK didn't work anymore.

share|improve this answer
    
As I stated with the question, my role is not developing the software but making sure that it will run. The DLL in question was not shipped with the system, so I would not replace anything. –  hillu Jan 3 '11 at 10:01
    
See my GTK example. And you didn't answer why you just can't bundle it, I mean innosetup makes it so easy. Once you have a new version compiled you just press a button and it creates a setup program with all the files you specify and put where you want it. –  Nathan Adams Jan 3 '11 at 18:10
    
I am not the author of the software, there is nothing to be compiled. –  hillu Jan 10 '11 at 19:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.