DLL-Konflikt
Der Ausdruck DLL Hell (auf deutsch "DLL-Hölle") stammt aus dem Computerjargon und bezeichnet Probleme, die durch die Installation von Dynamic Link Library (DLLs) auf den Betriebssystemen der Windows-Reihe (Windows 3.x, Windows 9x, Windows ME, Windows NT, Windows 2000, Windows XP, Windows Vista) entstehen können.
Solche DLLs werden von verschiedenen Programmen in unterschiedlichen Versionen benötigt, aber in der Regel an zentraler Stelle (im Windows- oder System-Verzeichnis) abgelegt und in der Registry eingetragen. Dies spart Speicherplatz und kann die Programmausführung deutlich beschleunigen. Andererseits kann dadurch die Installation eines neuen Programmes dazu führen, daß eine von einem vorhandenen Programm benötigte DLL überschrieben wird.
Gute Installationsroutinen überschreiben zwar nur ältere DLLs mit neueren Versionen, aber aufgrund schlechter Spezifikation der Schnittstelle oder falsche Nutzung der Programmierschnittstelle funktionieren nicht immer alle Programme mit neueren Versionen einer DLL. Schlechte Installationsroutinen überschreiben gelegentlich auch neuere DLLs mit älteren.
Bei Macintosh-Betriebssystemen wurde dieses Dilemma umgangen, indem DLLs nicht an zentraler Stelle, sondern jeweils im Programmverzeichnis abgelegt werden. Diese Redundanz führt nicht nur zur Belegung zusätzlicher Festplattenkapaziät, sondern kann auch zu Einbußen bei der Rechenleistung eines Systems führen. Aufgrund der in den letzten Jahren enorm gestiegenen Festplattenkapazitäten und der hohen Rechenleistungen moderner Prozessoren sind diese vermeintlichen Nachteile jedoch in den Hintergrund gerückt. Systemstabilität sollte bei der Entwicklung moderner Applikationen Vorrang vor Einsparungen in der Speicherkapazität haben.
Microsoft .NET erlaubt Programmen, eigene DLLs im Programmverzeichnis abzulegen oder sie im Global Assembly Cache (GAC) zentral zu speichern, wobei der GAC jedem installierten Programm die von ihm geforderte Version der DLL zur Verfügung stellen kann.
Die DLL Hell ist ein Beispiel schlechten Softwaredesigns. Die Probleme werden in den meisten Fällen durch die Nutzung undokumentierter bzw. unspezifizierter Funktionsaufrufe seitens der Anwendungsentwickler oder unspezifizierte Änderung des Verhaltens einer DLL seitens der Bibliotheksentwickler ausgelöst. Könnten sich alle Seiten auf Schnittstellen und deren genaue Funktion einigen und diese einhalten, würde das Problem nicht auftreten.
Das Problem
Grundsätzlich erlauben DLLs Computerprogrammen, auf ihren Programmcode und ihre Ressourcen zuzugreifen, um so identischen Code, den sonst jedes Programm selbst mitbringen müsste, zusammenzufassen. Jedoch bringen neue Programme oft auch neue Versionen einer bereits vorhandenen DLL (shared library) mit. Nun hat das Programm die Wahl, ob es bei der Installation die alte DLL überschreibt (was aber zu Kompatibilitätsproblemen mit anderen Programmen führen kann) oder eine weitere Kopie auf dem System installiert.
Virtueller Speicher ermöglicht der Prozessverwaltung eines Betriebssystems, weite Teile gemeinsam benutzter Bibliotheken in gemeinsam verwendeten Seiten physischen Speichers abzulegen. Wenn viele Programme dieselbe Bibliothek verwenden, wird der gesamte Speicherbedarf damit deutlich kleiner als die Summe aller Prozesse. Dieses Verfahren setzt aber voraus, daß es sich um dieselbe Datei, nicht nur um einen identischen Inhalt handelt. Mehrere verwendete Kopien der gleichen Bibliothek benötigen daher nicht nur zusätzlichen Festplattenspeicher, sondern auch mehr Hauptspeicher.
Auch bei Vorhandensein lediglich unterschiedlicher Versionen wird zumindest die Ausführungsgeschwindigkeit von Programmen verlangsamt, da das System nun längere Zeit benötigt, um die für das Programm jeweils richtige DLL-Version zu finden).
Je länger eine Betriebssystems-Installation benutzt wird, desto größer wird die Wahrscheinlichkeit für das Auftreten des DLL Hell-Problems. Da installierte Programme, die vom Benutzer wieder deinstalliert werden, keine Möglichkeit haben, zu überprüfen, ob ein anderes Programm von den von ihnen installierten DLLs abhängig ist, werden die DLLs oft auf dem System belassen und damit zu potenziellen „DLL-Leichen“. Das kann zu einer unüberschaubaren Menge verschiedener DLL-Dateien führen, die zum Teil vom Betriebssystem selbst benötigt werden (und deshalb auf keinen Fall entfernt werden dürfen), zum Teil aber auch unbenötigte Restbestände früherer Installationen darstellen, die, mittlerweile nutzlos geworden sind, unnötig Festplattenkapazität und eventuell Rechenleistung beanspruchen. Auf modernen System kann zwar davon ausgegangen werden, dass die verfügbare Festplattenkapazität durch redundante DLL-Versionen kaum beeinträchtigt sein wird, jedoch stellt (ähnlich wie bei verwaisten Registry Einträgen) alleine die Tatsache, dass das System immer größere Zustände des Chaos aufweist und somit unbegründet Rechenleistung verbraucht sowie auch potenzielle Instabilitäten erzeugt, ein grundsätzliches Problem dar.
Auftreten
Die DLL Hell stellt insbesonders bei älteren Versionen von Microsoft Windows ein sehr häufiges Problem dar, da diese nur beschränkte Möglichkeiten besitzen, um System-Dateien und DLL-Bibliotheken zu verwalten (und vorhandene Programme, die diesen Zweck erfüllen sollen, ignorieren oft das bestehende System und tragen nur dazu bei, zukünftige Fehler zu bereinigen bzw. zu vermeiden). Das Problem betrifft hauptsächlich Microsoft Windows; bei anderen Betriebssystemen ist das DLL-Höllen-Problem nicht so stark ausgeprägt. Nur bei älteren Versionen von Mac OS treten ähnliche Probleme auf, die als extension conflicts (Erweiterungs-Konflikte) bezeichnet werden. Aus technischer Sicht liegen die Ursachen für diese Konflikte aber woanders. Mit der Einführung des UNIX-basierten Mac OS X im Jahre 2000 wurden auch diese Konflikte aus der Welt geschafft.
Einer ähnlichen Problematik wie dem DLL-Höllen-Problem steht aktuell die Gecko Runtime Engine gegenüber, die unter anderem vom Mozilla-Projekt für diverse Anwendungsprogramme unter Microsoft Windows, Linux und Mac OS X verwendet wird. Diese Anwendungsprogramme enthalten oft verschiedene Versionen der Gecko Runtime Engine, begründet in den teils sprunghaften Änderungen der Programmierschnittstelle. Also wird von Thunderbird, Firefox und Sunbird jeweils eine eigene Kopie der (benötigten Version der) GRE-Engine mitgeliefert. Zusätzlich greift zum Beispiel Nvu wiederum auf spezielle Versionen der Engine zurück. Nun benötigen aber Programme, die ebenfalls auf die Gecko Runtime Engine angewiesen sind, wie in etwa Epiphany, eventuell eine andere Version der Engine als jene, die auf dem System schon teilweise mehrfach vorhanden ist, was zu Komplikationen führen kann.
Methoden zur Vermeidung
Es gibt einige Empfehlungen, die Probleme wie die DLL Hell zu vermeiden helfen sollten. Diese Empfehlungen können jedoch nur wirksam sein, wenn sie in ihrer Gesamtheit umgesetzt werden.
- Das Betriebssystem sollte über einen leistungsfähigen Paketmanager verfügen, der imstande ist, DLL-Abhängigkeiten von Programmen zu verfolgen. Um dessen Wirksamkeit zu gewährleisten, muss er natürlich auch von jedem Softwarehersteller zur Installation der Programme eingesetzt werden.
- Bibliotheken sollten im System zentral verwaltet werden. Eine solche zentrale Verwaltung kann zum Beispiel die Kompatibilität alter Bibliotheksversionen zu neuen überprüfen und, sollte eine solche Versionsverträglichkeit nicht vorhanden sein, diese über den Einbau einer Schnittstelle in die Bibliothek wieder gewährleisten.
- Wenn Softwareentwickler Änderungen an einer DLL vornehmen müssen und sich die ursprüngliche Bibliothek nicht in die neue einbinden lässt, dann müssen die Entwickler entweder den Programmcode direkt in ihr Programm einbauen (d.h. die Bibliothek statisch linken) oder ein neues Paket (mit einer anderen Bezeichnung) für diese Bibliothek erstellen.
- Sorgfalt und Bedachtsamkeit muss bei der Entwicklung vorrangig sein. Die Idee hinter einer DLL ist, dass sie modular von vielen Programmen gleichzeitig verwendet werden kann. Sollte sie diesen Zweck nicht erfüllen, so ist es besser, wenn sie direkt ins Programm übernommen wird. Im Vergleich zu vielen verschiedenen DLL-Versionen im System spart das Platz und kann unter Umständen zu einer Geschwindigkeitssteigerung führen.
DLL Hell als Herausforderung für .NET
2001 veröffentlichte Microsoft die .NET Umgebung, welche ihr eigenes Paketverwaltungssystem, die sogenannten assemblies mitbringt [1]. Diese Umgebung stellt vielverwendete Funktionen in einer Bibliothek bereit (es wird vor allem Programmcode aus mehreren DLLs in einer Klasse zusammengefasst).
In .NET kann jedes Programm seine eigenen Libraries mitbringen und diese im Programmverzeichnis ablegen. Alternativ können Assemblies aber auch zentral im Global Assembly Cache (GAC) abgelegt werden. Dieser ist jedoch im Gegensatz zu früheren Windows-Systemen in der Lage, mehrere Versionen einer Assembly zu verwalten, so dass jedes laufende Programm die Version die DLL, mit der es arbeiten möchte, auswählen kann.
Kritik an der DLL Hell
Die Idee, verschiedene Versionen einer Datei zu verwalten, wird oft als Überrest veralteter Programmiertechniken angesehen. Viele Betriebssysteme, so zum Beispiel bereits OpenVMS, fanden Möglichkeiten, mit dem Problem umzugehen - vor allem deshalb wird die immer noch vorhandene Aktualität der Problematik von Kritikern gerne als Beispiel der technischen Unterlegenheit von Microsoft Windows zitiert.