Inferno de DLLs

Inferno de DLLs (do inglês DLL hell) é uma designação dada a complicações no lidar com DLLs.

O termo foi trazido a público por Rick Anderson, num relatório: The end of DLL hell, depois de ter sido usada por algum tempo internamente pela Microsoft^{[carece de fontes]}.

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, "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 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 ctl3d.dll e ctl3dv2.dll 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.

Ligações externas

• «Entendendo o DLL Hell» (PDF). por Gustavo Chaves.