# 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$^[$.

## 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.