Inferno de DLLs: diferenças entre revisões
Conteúdo apagado Conteúdo adicionado
m Substituição de predefinições obsoletas |
Expansão por en:DLL Hell Etiqueta: Inserção de predefinição obsoleta |
||
Linha 2:
O termo foi trazido a público por Rick Anderson, num relatório: ''The end of DLL hell'',<ref>Anderson, Rick (January 2000). [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsetup/html/dlldanger1.asp The End of DLL Hell]. MSDN. Microsoft. Acesso em 18 de Março de 2006</ref> depois de ter sido usada por algum tempo internamente pela [[Microsoft]]{{Carece de fontes|data=Dezembro de 2008}}.
== Problemas ==
DLLs são a implementação da Microsoft de [[bibliotecas compartilhadas]]. As bibliotecas compartilhadas permitem que o código comum seja agrupado em um invólucro, a DLL e usado por qualquer software aplicativo no sistema sem carregar várias cópias na memória. Um exemplo simples pode ser o editor de texto [[GUI]], que é amplamente usado por muitos programas. Ao colocar esse código em uma DLL, todos os aplicativos do sistema podem usá-lo sem usar mais memória. Isso contrasta com as bibliotecas estáticas, que são funcionalmente semelhantes, mas copiam o código diretamente no aplicativo. Nesse caso, todo aplicativo cresce pelo tamanho de todas as bibliotecas que ele usa, e isso pode ser bastante grande para programas modernos.
O problema surge quando a versão da DLL no computador é diferente da versão usada quando o programa estava sendo criado. As DLLs não possuem mecanismo interno para compatibilidade com versões anteriores, e mesmo pequenas alterações na DLL tornam sua estrutura interna tão diferente das versões anteriores que, ao tentar usá-las, geralmente causam falha no aplicativo. As bibliotecas estáticas evitam esse problema porque a versão usada para compilar o aplicativo está incluída, portanto, mesmo que exista uma versão mais recente em outro local do sistema, isso não afeta o aplicativo.
Um dos principais motivos da incompatibilidade de versão é a estrutura do arquivo DLL. O arquivo contém um diretório dos métodos individuais (procedimentos, rotinas etc.) contidos na DLL e os tipos de dados que eles recebem e retornam. Mesmo pequenas alterações no código DLL podem fazer com que esse diretório seja reorganizado; nesse caso, um aplicativo que chama um método específico que acredita ser o quarto item no diretório pode acabar chamando uma rotina totalmente diferente e incompatível, o que Normalmente, o aplicativo falha.
Existem vários problemas comumente encontrados com DLLs, especialmente depois que vários aplicativos foram instalados e desinstalados em um sistema. As dificuldades incluem conflitos entre as versões da DLL, dificuldade em obter as DLLs necessárias e ter muitas cópias desnecessárias da DLL.
As soluções para esses problemas eram conhecidas mesmo quando a Microsoft estava gravando o sistema DLL. Eles foram incorporados à substituição do [[.NET Framework | .Net]], "Assemblies".
=== Versões incompatíveis ===
Uma versão específica de uma biblioteca pode ser compatível com alguns programas que a utilizam e incompatível com outros. O Windows ficou particularmente vulnerável a isso devido à ênfase na vinculação dinâmica de bibliotecas C ++ e objetos [[Object Linking and Embedding]] (OLE). As classes C ++ exportam muitos métodos, e uma única alteração na classe, como um novo método virtual, pode torná-lo incompatível com os programas criados em uma versão anterior. A vinculação e incorporação de objetos tem regras muito rígidas para evitar isso: as interfaces precisam ser estáveis e os gerenciadores de memória não são compartilhados. Isso é insuficiente, no entanto, porque a semântica de uma classe pode mudar. Uma correção de bug para um aplicativo pode resultar na remoção de um recurso de outro. Antes do [[Windows 2000]], o Windows era vulnerável a isso porque a tabela de classes [[Component Object Model | COM]] era compartilhada entre todos os usuários e processos. Somente um objeto COM em uma DLL / EXE pode ser declarado como tendo uma identificação de classe COM global específica em um sistema. Se algum programa precisasse criar uma instância dessa classe, obteria a implementação atual registrada centralmente. Como resultado, uma instalação de um programa que instalou uma nova versão de um objeto comum pode inadvertidamente interromper outros programas que foram instalados anteriormente.
=== DLL pisoteando ===
Um problema comum e problemático ocorre quando um programa recém-instalado substitui uma DLL do sistema em funcionamento por uma versão incompatível anterior. Os primeiros exemplos disso foram as bibliotecas <code> ctl3d.dll </code> e <code> ctl3dv2.dll </code> para [[Windows 3.1]]: bibliotecas criadas pela Microsoft que editores de terceiros distribuiriam com seu software , mas cada um distribuindo a versão com a qual eles desenvolveram e não a versão mais recente.<ref name=Ctl3D>{{cite web |url=http://support.microsoft.com/search/default.aspx?query=CTL3Dv2.DLL |title=A summary of CTL3D.DLL articles in Microsoft Support Knowledge Base |publisher=Microsoft}}</ref>
{{Referências}}
| |||