DLL-helvede

DLL-helvede eller DLL Hell er en betegnelse for de komplikationer der opstår, når man arbejder med dynamisk linkede biblioteker (DLL-filer) på Microsoft Windows - operativsystemer,^[1] især på de ældre 16-bit udgaver, der alle kører i det samme område af hukommelsen.

DLL-helvede kan manifestere sig på mange forskellige måde f.eks. ved at programmer ikke kan starte eller fungere korrekt.

I nogle tilfælde vil en fejlmeddelelse vises, for eksempel en besked om at "filen xxx.dll mangler". Fejl bliver dog ikke altid fulgt af en fejlmeddelelse.

DLL-helvede er en Windows-økosystem-specifik form af det mere generelle begreb dependency hell.

DLL-filer er Microsofts implementering af delte  programbiblioteker. Delte programbiblioteker gør det muligt at samle fælles kode i en samlet pakke, DLLer, der så kan anvendes af andre programmer på systemet, uden at indlæse flere kopier i hukommelsen. Et simpelt eksempel kunne være en grafisk teksteditor, som bliver brugt af mange programmer. Dette står i modsætning til statiske programbiblioteker, som er funktionelt tilsvarende, men kopierer koden direkte ind i programmet. I dette tilfælde vokser hvert program med størrelsen af alle de programbiblioteker de bruger og det kan være ganske meget for moderne programmer.

Problemet opstår når versionen af en DLL-fil på computeren, er anderledes end den version der blev brugt, da programmet blev udviklet. DLL-filer har ingen indbygget mekanisme der kan sikre bagudkompatibilitet, og selv mindre ændringer i en DLL ændrer den interne struktur så meget i forhold til tidligere versioner, at forsøg på at anvende dem ofte vil resultere i at programmet går ned. Med statiske programbiblioteker undgås dette problem, fordi den version der blev brugt til at bygge programmet, er inkluderet i selve programmet, så selv om der findes en nyere version andetsteds på systemet, vil det ikke berøre programmet.

En væsentlig årsag til versions-inkompatibilitet er DLL-filernes struktur. Filen indeholder en liste over de enkelte metoder (procedurer, rutiner, osv.) der er indeholdt i DLLen samt de datatyper de kaldes med og returnerer. Selv mindre ændringer i DLL-filen kan forårsage at listen bliver om-arrangeret, hvilket betyder at et program der anvender en bestemt metode i den tro, at den er det fjerde element i listen, kan ende med at prøve på at kalde en helt anden og inkompatibel rutine, som normalt resulterer i at programmet går ned.

Der er en række problemer der er almindeligt forekommende i forbindelse med DLLer, især efter mange programmer er blevet installeret og afinstalleret på et system. De vanskeligheder omfatter bl.a. konflikter mellem DLL-versioner, besvær med at fremskaffe de nødvendige DLLer, og at der kan være mange unødvendige kopier af DLLerne på systemet.

Løsninger på disse problemer er blevet indarbejdet i  .Nets viderebygning på DLLer, "Assemblies".

DLL-inkompatibilitet kan blive forårsaget af:

• Begrænset hukommelse, kombineret med manglende adskillelse af processers hukommelse i 16-bit versioner af Windows
• Manglende tvungne standarder for versionering, navngivning, og placering i filsystemet for DLLer
• Manglen på en tvungen standardmetode for software installation og fjernelse (package management);
• Manglen på en central autoritativ støtte for håndtering af DLLers application binary interface og sikkerhedssystemer hvilket gør der muligt at udgive inkompatible DLL-filer, med samme filnavn og interne versionsnumre
• Alt for primitive management-værktøjer, der forhindrer identifikation af ændrede eller problematiske DLL-filer med brugere og administratorer.
• Udviklere der bryder bagud-kompatibiliteten af funktioner i delte programbiblioteker
• Microsoft frigiver rettelser uden for de normale tidspunkter (out-of-band-opdateringer) af operativsystemets komponenter;
• Manglende evne til at køre forskellige versioner af de samme programbiblioteker samtidig (side-by-side)
• Afhængigheden af den aktuelle mappe eller %PATH% miljø-variabelen, som begge kan variere over tid og fra system til system, for at finde afhængige DLL-filer (i stedet for at hente dem fra et eksplicit defineret bibliotek.)
• Udviklere der genbruger ClassIDs fra eksempelprogrammer til COM interfaces af deres programmer, i stedet for at generere deres egne nye GUIDer.

DLL-helvede var et meget udbredt fænomen på versioner af Windows  Microsoft-operativsystemer der kom før Windows NT, den primære årsag er at 16-bit-operativsystemerne ikke begrænsede processer til at køre i deres egen hukommelse, og dermed ikke giver dem mulighed for at indlæse deres egen version af et delt programbibliotek, som at de var kompatible med. Det blev forventet af software installationsprogrammer at de var "ansvarlige borgere" og kontrollerede DLL versionsoplysninger før de overskrev eksisterende system-DLLer. Standardværktøjer der forenkler implementering (som altid indebærer distribution af operativsystem-DLLer programmerne har afhængigheder til) blev leveret af Microsoft og andre tredje parts leverandører. Microsoft krævede endog at programleverandører anvendte et standard-installationsprogram og at de fik deres installationsprogram certificeret til at fungere korrekt, inden der blev givet tilladelse til brug af Microsoft Windows-logoet. Den "ansvarlige borger" tilgang til programinstallation afhjalp ikke problemet, bl.a. fordi den stigende brug af internettet øgede mulighederne for at hente programmer, der ikke fulgte standarderne.

• Getting Out of DLL Hell på Microsoft TechNet
• Simplifying Deployment and Solving DLL Hell with the .NET Framework på MSDN
• Avoiding DLL Hell: Introducing Application Metadata in the Microsoft .NET Framework af Matt Pietrek
• Dr. Dobb's on DLL Hell (detaljer om LoadLibraryEx)
• Joel on Software discussion Arkiveret 30. oktober 2018 hos Wayback Machine
• Article on DLL Hell Arkiveret 3. juli 2008 hos Wayback Machine