DLL-Konflikt

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 Microsoft Windows-Reihe entstehen kann. Vorwiegend sind ältere Windowsversionen betroffen^[1], 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. In den verschiedenen Linux-Distributionen werden Bibliothekskonflikte meist durch den distributionseigenen Paketmanager verhindert, jedoch nicht immer ^[2].

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

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 Systemverzeichnis) 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.

• Es ist prinzipiell abzuwägen ob die potentiellen Nachteile einer DLL überhaupt in einem speziellen Anwendungsfall durch Vorteile überwogen werden. 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.
• 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)^[3].
• Lokal gespeicherte DLL-Versionen für eine Anwendung, genannt Private DLLs ^[1]. Unter Windows haben diese DLL-Versionen, die im Programmordner der Anwendung abgelegt sind, eine höhere Priorität als die systemweit verfügbaren DLLs^[4].
• 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.
• Angabe einer Versionsbezeichnung im DLL Dateinamen (z.B. atl80.dll, atl90.dll) um unterschiedliche Versionen gemeinsam installieren zu können.
• Installationsprogramme oder Paketmanager können DLL-Abhängigkeiten von Programmen verfolgen.
• Bibliotheken vom Betriebssystem zentral verwaltet lassen. 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.

DLL-Konflikte als Herausforderung für .NET

2001 veröffentlichte Microsoft die .NET-Programmierumgebung, die ein eigenes Paketverwaltungssystem, die so genannten Assemblies, enthält. 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 eigene Bibliotheken verwenden und diese im Stammverzeichnis des Programms 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 der DLL, mit der es verknüpft ist, zugewiesen bekommt.

Die Idee, verschiedene Versionen einer Datei zu verwalten, wird teilweise als Überrest veralteter Programmiertechniken begriffen.

Quellen

1. ↑ ^{a b} Rick Anderson (11. Januar 2000): The End of DLL Hell. microsoft.com. Archiviert vom Original am 5. Juni 2001. Abgerufen am 7. Juli 2010.
2. ↑ James Donald: Improved Portability of Shared Libraries. 2003-01-25. Abgerufen am 9. April 2010. (englisch)
3. ↑ Tim Pfeiffer (1. Juni 1998): Windows DLLs: Threat or Menace?. Dr. Dobbs Journal. Archiviert vom Original am 20. Juni 2006. Abgerufen am 7. Juli 2010.
4. ↑ Arnaud Desitter (15. Juni 2007): Using static and shared libraries across platforms; Row 9: Library Path. ArnaudRecipes. Archiviert vom Original am 1. Juni 2008. Abgerufen am 7. Juli 2010.

Weblinks

• DLL Hell: The Inside Story (Englisch)
• MSDN: Vereinfachen der Weitergabe und Lösen der "DLL Hell" mit dem .NET Framework
• DLL-Files: Download of DLLs (englisch)