3
1
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?
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 – 2011-01-03T10:01:04.360
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. – Natalie Adams – 2011-01-03T18:10:23.603
I am not the author of the software, there is nothing to be compiled. – hillu – 2011-01-10T19:21:13.930