Почему бы не устанавливать Msvcr71.dll в system32?
При поиске авторитетного источника для пропавших без вести Msvcr71.dll это необходимо нескольким старым приложениям, я споткнулся через Перераспределение статьи MSDN общего компонента во время выполнения C в Visual C++. Совет, данный разработчикам, состоит в том, чтобы бросить DLL в каталог приложения вместо system32 так как DLLs в этом каталоге рассматривают перед системными путями.
Что может/, идут не так, как надо, если я (как администратор, не разработчик) решаю выбрать путь ленивое и установку Msvcr71.dll (и Msvcp71.dll в то время как я в нем) в system32 каталог (Windows XP на 32 бита или систем Windows 7) вместо того, чтобы поместить копию в каталог каждого приложения? Там другое хорошее решение состоит в том, чтобы предоставить приложениям необходимый DLLs, который не включает копирование материала к каталогам приложения?
добавленный после первых ответов: Я понимаю, что несовместимые изменения API, возможно, были внесены в упомянутый DLLs, но в значительной степени каждое упоминание о несовместимостях, я нашел Google использования, имело отношение к играм или видеокодекам. Прямо сейчас я ожидаю, что риск поломки является довольно маленьким. Я пропускаю что-то?
3 ответа
Основное (только?) проблемой является совместимость между различными версиями Msvcr71.dll. Скажем, 7.10.0 является немного несовместимым с 7.10.1, и приложение App1 зависит от старого поведения, и приложение App2 зависит от нового поведения. Дополнительно оба приложения не поставляют это время выполнения C++ само. В этом случае одно из этих двух приложений перестанет работать.
Как часто те случаи? Я действительно не знаю, но я сказал бы, что они редко.
В зависимости от различий между версиями msvcr71.dll приложению не удалось бы запуститься, или конкретная функция не будет работать.
Другое хорошее решение: владейте ПУТЕМ для каждого приложения. Например, Вы могли записать пакет как это:
PATH=c:\PathToMSVCR71.DLL_Version_7.10.0
myapp1.exe
Таким образом, можно снова использовать тот же DLL в нескольких приложениях и обновить его легче.
РЕДАКТИРОВАНИЕ почти невозможно оценить опасность коллизии версии тем более, что Вы не упомянули приложения, которые Вы используете. Именно поэтому я искал все различные версии на своем ПК (Windows 7/x64). Я нашел следующие файлы: 
Все файлы являются просто копиями этих двух: 7.10.3052.4 и 7.10.6030.0. 7.10.3052.4 также, что предлагает dll-files.com.
Я также сравнил вывод dumpbin /imports /exports msvcr71.dll для этих версий и ни экспорт, ни импорт не изменились (как ожидалось).
"Больше информации" в статье, с которой Вы связались, говорит, что размещение CRT в system32 "может вызвать проблемы при запуске приложений, которые связаны с другой версией CRT на компьютерах, которые не имеют правильных версий DLL CRT установленными".
Например, скажем, App1 требует, чтобы версия 2.1 Msvcr71.dll для ее функции SpinMyRainbowPinWheel работала. Разработчики App1 установили Msvcr71.dll в каталоге программных файлов App1.
Если Вы приедете и поместите версию 2.0 Msvcr71.dll в system32, то App1 начнет использовать системный файл вместо того, что было установлено в его каталоге программных файлов. Функция SpinMyRainbowPinWheel не будет больше работать, и Вы будете gett вызов от генерального директора, потому что завихрение не вращается на его мониторе, когда он дует в свой микрофон. Бизнес резко останавливается!
Не делайте, и я, никогда повторяюсь не заменяют или добавляют DLLs в масштабе всей системы. Я не понимаю, почему Вы не можете просто связать его? Именно поэтому Вы создаете пакеты установщика. Я знаю, что Microsoft имеет инструмент создания установки с VS6, и если у Вас нет его затем, Вы могли бы использовать что-то как innosetup. И причина, почему они говорят Вам помещать DLL в ту же папку, состоит в том, потому что это - то, где, afaik, приложение сначала ищет DLL.
Кроме этого, приходят на ум две вещи:
1) DLL может уже быть в рассматриваемой системе
2) Я уверен, что Microsoft обеспечивает установочный пакет для установки необходимого DLLs, если они не присутствуют. То, которое является тем, что я был бы, рекомендовало использовать вместо того, чтобы просто случайно заменить/добавить файлы DLL.
Идеальным примером того, почему Вы не должны касаться DLLs в масштабе всей системы, является мой опыт с GTK. Различные приложения используют различные версии GTK. Я помню, что одно приложение решило быть "ленивым" и установить DLL в масштабе всей системы для GTK. Другие приложения, которые использовали GTK, больше не работали.