Почему бы не установить Msvcr71.dll в system32?

Question

В поисках авторитетного источника для отсутствующего Msvcr71.dll который необходим нескольким старым приложениям, я наткнулся на статью MSDN Перераспределение общего компонента времени выполнения C в Visual C++. Совет разработчикам - помещать DLL в каталог приложения вместо system32 поскольку библиотеки DLL в этом каталоге рассматриваются перед системными путями.

Что может / пойдет не так, если я (как администратор, а не разработчик) решу выбрать ленивый путь и установить Msvcr71.dll (и Msvcp71.dll пока я на нем) в каталог system32 (32-битной Windows XP или системы Windows 7) вместо того, чтобы помещать копию в каталог каждого приложения? Есть ли другое хорошее решение для обеспечения приложений необходимыми библиотеками DLL, которые не включают копирование содержимого в каталоги приложений?

добавлено после первых ответов: я понимаю, что несовместимые изменения API могли быть внесены в упомянутые библиотеки DLL, но почти все упоминания о несовместимости, которые я обнаружил при использовании Google, были связаны с играми или видеокодеками. Прямо сейчас, я ожидаю, что риск поломки довольно мал. Я что-то пропустил?

Answer 1

Основное (только?) Проблема заключается в совместимости между различными версиями Msvcr71.dll. Скажем, 7.10.0 немного несовместим с 7.10.1, и приложение App1 зависит от старого поведения, а приложение App2 зависит от нового поведения. Кроме того, оба приложения не поставляют эту среду выполнения C++. В этом случае произойдет сбой одного из двух приложений.

Как часто эти случаи? Я действительно не знаю, но я бы сказал, что они редко.

В зависимости от различий между версиями msvcr71.dll приложение не запустится или не будет работать определенная функция.

Еще одно хорошее решение: собственный PATH для каждого приложения. Например, вы могли бы написать партию как это:

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 для этих версий, и ни экспорт, ни импорт не изменились (как и ожидалось).

Answer 2

"Дополнительная информация" в статье, на которую вы ссылаетесь, говорит о том, что размещение CRT в system32 «может вызвать проблемы при запуске приложений, связанных с другой версией CRT, на компьютерах, на которых не установлены правильные версии DLL CRT».

Например, допустим, что App1 требует версии 2.1 файла Msvcr71.dll, чтобы его функция SpinMyRainbowPinWheel работала. Разработчики App1 установили Msvcr71.dll в каталог программных файлов App1.

Если вы зайдете и поместите версию 2.0 Msvcr71.dll в system32, App1 начнет использовать системный файл вместо того, который был установлен в каталоге его программных файлов. Функция SpinMyRainbowPinWheel больше не будет работать, и вам позвонит генеральный директор, потому что вертушка не вращается на его мониторе, когда он дует в микрофон. Бизнес замирает!

Answer 3

Не надо, и я повторяю, никогда не заменяйте и не добавляйте общесистемные библиотеки DLL. Я не понимаю, почему ты не можешь просто связать это? Вот почему вы создаете установочные пакеты. Я знаю, что у Microsoft есть инструмент для создания установки с VS6, и если у вас его нет, вы можете использовать что-то вроде innosetup. И причина, по которой они советуют вам помещать DLL в одну и ту же папку, заключается в том, что именно здесь, в первую очередь, приложение ищет DLL.

Кроме того, на ум приходят две вещи:
1) DLL может быть уже в рассматриваемой системе
2) Я уверен, что Microsoft предоставляет установочный пакет для установки необходимых библиотек DLL, если их нет. Это то, что я бы порекомендовал вам использовать вместо простой замены / добавления DLL-файлов.

Прекрасным примером того, почему вы не должны касаться общесистемных библиотек DLL, является мой опыт работы с GTK. Разные приложения используют разные версии GTK. Я помню, одно приложение решило "лениться" и установить общесистемную DLL для GTK. Другие приложения, которые использовали GTK, больше не работали.