Под Windows * MSVCRT похож на glibc (libc) под * nix? - PullRequest
21 голосов
/ 25 сентября 2008

Я часто сталкиваюсь с программами 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 - одно полезное введение в проблему ...

Ответы [ 4 ]

13 голосов
/ 06 ноября 2008

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

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

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

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

12 голосов
/ 22 июня 2011

В Windows нет "общесистемного libc".

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

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

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

11 голосов
/ 25 сентября 2008

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

2 голосов
/ 25 сентября 2008

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

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

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

...