É MSVCRT no Windows como glibc (libc) sob * nix?

Question

Eu freqüentemente deparamos com programas Windows que pacote em MSVCRT (ou seus equivalentes mais atuais) com os executáveis ??do programa. Em um PC típico, eu iria encontrar muitas cópias da mesma DLL do. Meu entendimento é que MSVCRT é a biblioteca C runtime, algo análogo ao glibc / libc.so sob * nix.

Por que os programas do Windows tem de trazer suas bibliotecas C com eles, em vez de apenas compartilhando o libc todo o sistema?

---

Update: graças a Shog9, comecei a ler sobre SxS, que tem ainda abriu meus olhos para os problemas DLL de ligação (DLL inferno) - http://blogs.msdn.com/b/martynl/archive/2005/10/13/480880.aspx é uma introdução útil para a questão ...

Answer 1

[Eu sou o mantenedor atual da tecnologia Native SxS no Microsoft]

Novas versões do MSVCRT são liberados com novas versões do Visual Studio, e refletir alterações no conjunto de ferramentas C ++. Assim que os programas compilados com versões do VS lançados após a versão específica do Windows continuam nível inferior lata de trabalho (como VS 2008 projectos no Windows XP), o MSVCRT é redistribuído, para que ele possa ser instalado lá.

instalação CRT cai as bibliotecas em% windir% \ winsxs \, que é um local global do sistema, exigindo privilégios de administrador para fazê-lo.

Uma vez que alguns programas não quer enviar com um instalador, ou não deseja que o usuário privilégios de administrador necessidade na máquina para executar seu instalador, eles agrupar o CRT diretamente no mesmo diretório do aplicativo, para uso privado. Então, em uma máquina típica, você vai encontrar muitos programas que optaram por esta solução.

Answer 2

Não há realmente um "libc todo o sistema" no Windows.

Em * nix, há geralmente um compilador, um vinculador, e com elas um formato de arquivo objeto bem definido, convenção de chamada, eo nome desconfiguração spec. Este material geralmente vem com o OS. O status do compilador semi-especial (além de uma ênfase na portabilidade entre diferentes * nixes) significa que certas coisas podem ser esperado para estar lá, e para ser nomeado e / ou controle de versão, de tal forma que os programas podem facilmente encontrar e usá-lo.

No Windows, as coisas estão mais fragmentado. Um compilador não vem com o sistema operacional, para que as pessoas precisam para obter a sua própria. Cada compilador fornece sua própria CRT, que pode ou não pode ter as mesmas funções nele como MSVCRT. Também não há One True Spec em chamar convenções ou como nomes devem aparecer nas bibliotecas, de modo diferentes compiladores (com diferentes formas de fazer as coisas) pode ter funções constatação de problemas na biblioteca.

BTW, o nome deve ser uma pista aqui; MSVCRT é a abreviação de "Microsoft Visual C ++ runtime". Não é realmente uma biblioteca "system-wide", da mesma forma que, digamos, kernel32 é - é apenas a biblioteca de tempo de execução usado por compiladores de MS, que presumivelmente utilizados na construção do Windows. Outros compiladores pode conseguir vincular contra ele, mas (1) pode haver problemas de licenciamento; e (2) os compiladores seria amarrar seu código para MS de - ou seja, (2a) que eles já não têm qualquer forma de adicionar ao tempo de execução ou corrigir erros, falta de esperança MS irá corrigi-los; e (2b) se o MS decide mudar o que está no RTL (que eles podem fazer à vontade, e provavelmente tem em cada nova versão do VC ++), ou como os nomes aparecem, esses outros programas podem quebrar.

Answer 3

curta resposta? Porque, até SxS, MSVCRT não era confiável Versioned ! Você pode imaginar a loucura que resultaria se os programas compilados e testados contra libc 5 silenciosamente começar a usar libc 6? Essa é a situação em que estávamos há muitos anos no Windows. A maioria de nós, tão logo nunca mais MS confiança com mantendo quebra muda a partir de uma versão

Answer 4

Os programas são ligados contra uma versão específica do tempo de execução, e que versão necessária é não garantida a existir na máquina de destino. Além disso, combinando-se as versões utilizadas para ser problemático.

No mundo Windows, é maneiras muito ruins para esperar que seus usuários para sair e encontrar e instalar uma biblioteca separada para usar o aplicativo. Você se certificar de todas as dependências que não fazem parte do sistema host estão incluídos com o aplicativo.

No mundo do linux isso nem sempre é tão simples, uma vez que há uma variação muito maior de como o sistema host pode parecer.