По каким причинам не стоит статически связываться с VC CRT?

Question

Я обнаружил, что при динамическом связывании, даже с SxS, будет обновляться Центр обновления Windows и топать версию CRT VC8 (например, у нее есть уязвимость в системе безопасности), а затем мое приложение не сможет работать со старыми версиями. .

Каковы некоторые из важных причин остаться с динамической связью с VC CRT, кроме увеличения размера ваших двоичных файлов?

Answer 1

• Хорошая причина - оставаться в курсе исправлений безопасности. В противном случае вы несете ответственность за перестройку приложения с фиксированной ЭЛТ и его развертывание для своих клиентов.

• Использование общей ЭЛТ должно привести к снижению занимаемой памяти системы, поскольку большинство страниц DLL могут быть разделены между процессами.

Answer 2

Я предпочитаю статические ссылки. Безопасность не является большой проблемой, поскольку хакеры нацелены на приложения, которые многие пользователи установили в своей системе. Поэтому, если у вашего приложения более 1 миллиона пользователей, я не буду беспокоиться о том, что оно будет использовано хакерами.

Мне не нравятся динамические ссылки. Мне это кажется слишком хрупким.

РЕДАКТИРОВАТЬ: И если вы хотите убедиться, что ваши пользователи имеют последнюю версию вашего приложения, то также напишите приложение для обновления, которое будет автоматически установлено вместе с вашим основным приложением. В Windows это может быть реализовано как служба.

Answer 3

Если все сделано правильно , не должно быть абсолютно никаких проблем с динамическим связыванием, и приложение должно работать без сбоев. Единственная сложная задача - перейти от сборки вашего установщика с любого метода, который вы используете сейчас, к способу, поддерживаемому Microsoft (распространяемые модули слияния - MSM, MSI, динамическое связывание). См. эту ссылку для получения чрезвычайно ценных советов прямо из источника. Некоторые интересные цитаты из блога:

• Чтобы перераспределить библиотеки Visual C ++, все, что вам нужно , это включить соответствующий файл .MSM и сопровождающую его политику .MSM для распространения необходимой библиотеки.
• Опять же, просто чтобы подчеркнуть - не используйте VCRedist * .exe , если вы не используете Click Once для развертывания своего приложения.
• Однако я могу думать о без сценариев , в которых это (мое примечание: статическое связывание) действительно является правильным решением при отправке вашего продукта покупателям.

Я согласен, что вам может потребоваться выполнить нетривиальную работу для реализации этого (возможно, вы не используете MSI прямо сейчас и т. Д.), Но я думаю, что если ресурсы позволяют, вы должны попытаться перейти на рекомендованные методы, описанные выше .

И если вы не сделаете это так, как описано выше, ваше приложение действительно в какой-то момент перестанет работать. И разработчики обвиняют Microsoft, пока они действительно не следовали поддерживаемому пути, описанному выше. Может быть, Microsoft виновата, потому что она не ссылается на блог выше на MSDN, чтобы распространять информацию, но это все.

Answer 4

См. http://people.redhat.com/drepper/no_static_linking.html

Речь идет о Linux, но некоторые идеи применимы.

Answer 5

Тебе повезло в Windows. А Linux буквально состоит из библиотек, и у вас есть такие проблемы со всеми из них. : -)

Насколько я понимаю, поставщики библиотек всегда сохраняют обратную совместимость, особенно если это Microsoft. Таким образом, возможное решение состоит в том, чтобы создать ваше приложение на старой машине, учитывая, что Microsoft разрабатывает библиотеку CRT таким образом, чтобы ваше приложение работало на всех последующих версиях.

Answer 6

Когда ваша программа использует что-то из CRT, что является одной из «утечек безопасности», о которых вы упоминаете. Если вы создадите статическую ссылку, ваши пользователи не будут знать, что они подвержены уязвимости в безопасности и, возможно, находятся под угрозой вируса. С другой стороны, если ваша программа не работает, потому что она динамически связана, они будут вынуждены обновить ее до новой безопасной версии.