MSVCRT под Windows, как glibc (libc) под * nix?

Question

Я часто сталкиваюсь с программами Windows, которые связывают MSVCRT (или их более современные эквиваленты) с исполняемыми программами. На обычном ПК я бы нашел много копий того же самого .DLL. Я понимаю, что MSVCRT - это библиотека времени выполнения C, несколько похожая на glibc/libc.so под * nix.

Почему программы Windows должны использовать вместе с ними библиотеки C, а не просто обмениваться общесистемным libc?

---

Обновление: благодаря Shog9, я начал читать о SxS, которая дополнительно открыл мне глаза на вопросы DLL подъёмник (DLL Hell) - http://blogs.msdn.com/b/martynl/archive/2005/10/13/480880.aspx это один полезный интро к вопросу ...

Answer 1

[Я Текущие сопровождающая технологии Native SxS на Microsoft]

Новых версий MSVCRT выпускаются с новым версии Visual Studio и отражают изменения в наборе инструментов C++. Таким образом, программы, скомпилированные с версиями VS, выпущенными после того, как определенная версия Windows может работать с нисходящим уровнем (например, проекты VS 2008 в Windows XP), MSVCRT является распространяемым, поэтому его можно установить там.

Установка CRT распаковывает библиотеки в% windir% \ winsxs \, что является глобальным местоположением системы, требующим прав администратора для этого.

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

Answer 2

Программы связаны с конкретной версией среды выполнения, и эта требуемая версия не гарантированно существует на целевой машине. Кроме того, сопоставление версий было проблематичным.

В мире Windows очень жаль, что ваши пользователи могут выйти и найти и установить отдельную библиотеку для использования вашего приложения. Вы убедитесь, что любые зависимости, не входящие в состав хост-системы, включены в ваше приложение.

В мире Linux это не всегда так просто, так как существует гораздо больший разброс в отношении того, как может выглядеть хост-система.

Answer 3

Короткий ответ? Потому что, вплоть до SxS, MSVCRT не надежно версировал! Можете ли вы представить себе безумие, которое может возникнуть, если программы, скомпилированные и протестированные против libc 5, беззвучно начнут использовать libc 6? Такова ситуация, в которой мы находились в течение многих лет в Windows. Большинство из нас, как только никогда доверять MS с сохранением критических изменений из версии

Answer 4

В Windows нет действительно «системного libc».

В * nix существует, как правило, один компилятор, один компоновщик, а с ними - четко определенный формат объектного файла, соглашение о вызове и спецификация mangling. Обычно этот материал поставляется с ОС. Полуспециальный статус компилятора (плюс акцент на переносимости по разным * nixes) означает, что некоторые вещи могут быть ожидаемым быть там и быть названными и/или версиями таким образом, чтобы программы могли легко находить и использовать их ,

В Windows вещи более фрагментированы. Компилятор не поставляется с ОС, поэтому люди должны получить свои собственные.Каждый компилятор предоставляет свой собственный CRT, который может или не может иметь в нем такие же функции, как MSVCRT. Там также нет One True Spec при вызове соглашений или как имена должны появляться в библиотеках, поэтому разные компиляторы (с разными способами делать вещи) могут иметь проблемы с поиском функций в библиотеке.

Кстати, имя должно быть ключом здесь; MSVCRT не подходит для «MicroSoft Visual C++ RunTime». Это не совсем «общесистемная» библиотека так же, как, скажем, kernel32 - это просто библиотека времени исполнения, используемая компиляторами MS, которые, по-видимому, используются при создании Windows. Другие компиляторы могут, по-видимому, связываться с ним, но (1) могут возникнуть проблемы с лицензированием; и (2) компиляторы свяжут свой код с MS-значением (2a), у них больше не будет возможности добавить к среде выполнения или исправить ошибки, не дожидаясь, что MS их исправит; и (2b), если MS решит изменить то, что находится в RTL (что они могут делать по желанию и, вероятно, иметь в каждой новой версии VC++), или как появятся имена, эти другие программы могут сломаться.