DLL-Hölle

Der Ausdruck DLL-Konflikt (auch DLL Hell, deutsch: „DLL-Hölle“ genannt) bezeichnet ein Problem, das 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, Windows Server) entstehen kann. Vorwiegend sind ältere Windowsversionen betroffen, da diese nur beschränkte Möglichkeiten besitzen, um System-Dateien und DLL-Bibliotheken zu verwalten. Auch bei älteren Versionen von Mac OS treten ähnliche Probleme auf, die als Extension Conflicts (Erweiterungskonflikte) bezeichnet werden.

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 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 voraus, dass 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.

Je mehr alte und neue Programme gemeinsam verwendet werden, desto höher ist das Risiko für das Auftreten von DLL-Konflikten. 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 Reste gelöschter Installationen darstellen.

Auf modernen Systemen 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 Einträgen in der Systemregistrierung, alleine die Tatsache, dass das System immer größere Zustände des Chaos aufweist und somit unbegründet Rechenleistung verbraucht sowie potenzielle Instabilitäten erzeugt, ein grundsätzliches Problem dar.

Ursachen

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 Windows-Registrierungsdatenbank eingetragen. Dies spart Speicherplatz und kann die Programmausführung deutlich beschleunigen, da das System weniger Zeit benötigt, um die für das Programm jeweils richtige DLL-Version zu finden. Andererseits kann die Installation eines neuen Programms dazu führen, dass eine neue DLL die alte Version überschreibt. Die neue Version kann eventuell bei der älteren Software aufgrund einer schlechten oder ungenauen Spezifikation der Schnittstelle oder einer falschen Nutzung der Programmierschnittstelle Kompatibilitätsprobleme verursachen. Dies ist ein Zeichen mangelhaften Softwaredesigns. Die Probleme werden oft durch die Nutzung undokumentierter Funktionsaufrufe seitens der Anwendungsentwickler oder unspezifizierte Änderung des Verhaltens einer DLL seitens der Bibliotheksentwickler ausgelöst.

Bei Macintosh-Betriebssystemen wird dieser Nachteil vermieden, indem solche Systemdateien nicht an zentraler Stelle, sondern im jeweiligen Programmverzeichnis abgelegt werden. Diese Redundanz führt nicht nur zur Belegung zusätzlicher Festplattenkapazität, sondern kann auch zu Einbußen bei der Rechenleistung eines Systems führen. Aufgrund der inzwischen enorm gestiegenen Festplattenkapazitäten und der hohen Rechenleistungen moderner Prozessoren sind diese Nachteile jedoch in den Hintergrund gerückt.

Methoden zur Vermeidung

Es gibt erprobte Methoden, wie sich diese DLL-Konflikte vermeiden lassen. Diese Empfehlungen können jedoch nur wirksam sein, wenn sie in ihrer Gesamtheit umgesetzt werden.

• Angabe einer Versionsbezeichnung im DLL Dateinamen (z.B. atl80.dll, atl90.dll) um unterschiedliche Versionen gemeinsam installieren zu können.
• Leistungsfähige Paketmanager können DLL-Abhängigkeiten von Programmen verfolgen. Um dessen Wirksamkeit zu gewährleisten, muss er natürlich von jedem Softwarehersteller zur Installation der Programme eingesetzt werden.
• Bibliotheken sollten vom 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, können die Entwickler den Programmcode direkt in ihr Programm einbauen (die Bibliothek wird statisch gelinkt). Oder sie erstellen ein neues Paket unter einem anderen Namen für diese Bibliothek.
• Sorgfalt und Bedachtsamkeit muss bei der Entwicklung vorrangig sein. Wenn eine DLL das Ziel, modular von vielen Programmen gleichzeitig verwendet werden zu können, nicht erfüllt, ist es besser, wenn ihre Funktionen direkt im Programm übernommen werden.
• Microsoft .NET erlaubt Programmen, eigene DLLs wahlweise 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.

DLL-Konflikte als Herausforderung für .NET

2001 veröffentlichte Microsoft die .NET Umgebung, welche ihr eigenes Paketverwaltungssystem, die so genannten Assemblies mitbringt. 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 kompatibel ist zugewiesen bekommt.

Kritik an Programmiertechniken

Dieser Artikel oder Abschnitt ist nicht hinreichend mit Belegen (Literatur, Webseiten oder Einzelnachweisen) versehen. Die fraglichen Angaben werden daher möglicherweise demnächst gelöscht. Hilf Wikipedia, indem du die Angaben recherchierst und gute Belege einfügst. Bitte entferne erst danach diese Warnmarkierung.

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 Windows zitiert.

Weblinks

• DLL Hell: The Inside Story (engl.)
• MSDN: Vereinfachen der Weitergabe und Lösen der "DLL Hell" mit dem .NET Framework
• MSDN: The End of DLL Hell (engl.)
• DLL-Files: Download of DLLs (engl.)
• 28000+ DLL Files - Seite zum Herunterladen von DLL-Dateien (engl.)