Por que não instalar o Msvcr71.dll no system32?

Question

Enquanto procurava por uma fonte autorizada para o Msvcr71.dll ausente que é necessário para alguns aplicativos antigos, deparei com o artigo do MSDN Redistribuição do componente de tempo de execução C compartilhado no Visual C ++ . O conselho dado aos desenvolvedores é descartar a DLL no diretório do aplicativo, em vez de system32 , já que as DLLs nesse diretório são consideradas antes dos caminhos do sistema.

O que pode / vai dar errado se eu (como administrador, não como desenvolvedor) decidir tomar o caminho preguiçoso e instalar Msvcr71.dll (e Msvcp71.dll enquanto estou nisso) no diretório system32 ( de sistemas Windows XP ou Windows 7 de 32 bits) em vez de colocar uma cópia no diretório de cada aplicativo? Existe outra boa solução para fornecer aos aplicativos as DLLs necessárias que não envolvam a cópia de material nos diretórios de aplicativos?

adicionado após as primeiras respostas: Eu entendo que alterações de API incompatíveis podem foram feitas para as DLLs mencionadas, mas praticamente todas as menções a incompatibilidades que encontrei usando o Google tiveram para fazer com jogos ou codecs de vídeo. Agora, espero que o risco de quebra seja bem pequeno. Estou faltando alguma coisa?

    

Answer 1

O problema principal (apenas?) é a compatibilidade entre diferentes versões do Msvcr71.dll. Vamos supor que 7.10.0 seja ligeiramente incompatível com 7.10.1 e que um aplicativo App1 dependa do comportamento antigo e que um aplicativo App2 dependa do novo comportamento. Além disso, os dois aplicativos não enviam esse próprio tempo de execução do C ++. Nesse caso, um dos dois aplicativos falhará.

Com que frequência são esses casos? Eu realmente não sei, mas eu diria que eles são raramente.

Dependendo das diferenças entre as versões msvcr71.dll, um aplicativo falharia ao iniciar ou um determinado recurso não funcionaria.

Outra boa solução: o próprio PATH para cada aplicativo. Por exemplo, você poderia escrever um lote assim:

PATH=c:\PathToMSVCR71.DLL_Version_7.10.0
myapp1.exe

Dessa forma, você pode reutilizar a mesma DLL em vários aplicativos e atualizá-la com mais facilidade.

EDITAR É quase impossível estimar o perigo de uma colisão de versão, especialmente porque você não mencionou os aplicativos que você usa. É por isso que procurei todas as diferentes versões do meu PC (Windows 7 / x64). Eu encontrei os seguintes arquivos:

Todos os arquivos são apenas cópias destes dois: 7.10.3052.4 e 7.10.6030.0. 7.10.3052.4 é também o que dll-files.com oferece.

Eu também comparei a saída de dumpbin /imports /exports msvcr71.dll para essas versões e nem as exportações nem as importações foram alteradas (como esperado).

    

Answer 2

"Mais informações" no artigo vinculado diz colocar o CRT no system32 "pode causar problemas ao executar aplicativos que estão vinculados a uma versão diferente do CRT em computadores que não têm as versões corretas da DLL CRT instalado. "

Por exemplo, digamos que o App1 requer a versão 2.1 do Msvcr71.dll para que sua função SpinMyRainbowPinWheel funcione. Os desenvolvedores do App1 instalaram o Msvcr71.dll no diretório de arquivos de programas do App1.

Se você vir e colocar a versão 2.0 do Msvcr71.dll no system32, o App1 começará a usar o arquivo do sistema em vez do que foi instalado no diretório de arquivos do programa. A função SpinMyRainbowPinWheel não funcionará mais, e você receberá uma ligação do CEO porque o cata-vento não está girando no monitor quando ele toca no microfone. O negócio chega a um ponto insuportável!

    

Answer 3

Não, e repito, NÃO substitua nem adicione DLLs de todo o sistema. Eu não entendo porque você não pode simplesmente empacotá-lo? É por isso que você cria pacotes de instalação. Eu sei que a Microsoft tem uma ferramenta de criação de instalação com o VS6, e se você não tem, então você pode usar algo como innosetup. E a razão pela qual eles dizem para você colocar a DLL na mesma pasta é porque é aí que, afaik, o aplicativo procura primeiro pela DLL.

Além disso, duas coisas vêm à mente:
1) A DLL pode já estar no sistema em questão
2) Tenho certeza que a Microsoft fornece um pacote de instalação para instalar as DLLs necessárias, se elas não estiverem presentes. Qual é o que eu recomendaria que você usasse, em vez de simplesmente substituir / adicionar arquivos DLL ao acaso.

Um exemplo perfeito de por que você não deve tocar nas DLLs do sistema é a minha experiência com o GTK. Aplicativos diferentes usam diferentes versões do GTK. Eu me lembro de um aplicativo que decidiu ser "preguiçoso" e instalar uma DLL para o GTK. As outras aplicações que usaram o GTK não funcionaram mais.