In der Computerwissenschaft ist DLL Hölle ein Begriff für die Komplikationen, die entstehen, wenn sie mit dynamischen Verbindungsbibliotheken (DLLs) arbeiten, der mit Windows von Microsoft Betriebssysteme, besonders Vermächtnis-16-Bit-Ausgaben der der ganze Lauf in einem einzelnen Speicherraum verwendet ist.

Während der Ausdruck mit Windows spezifisch ist und eine Abstammung der allgemeinen Quer-Plattform Ausdrucks "Abhängigkeitshölle", macht der Reim "DLL Hölle" seinen Gebrauch populär, für einen allgemeinen Windows-zusammenhängenden Abhängigkeitshölle-Fall zu besprechen.

DLL Hölle kann sich auf viele verschiedene Weisen äußern; normalerweise fahren Anwendungen nicht los oder arbeiten richtig. Anwendungen auf modernen Versionen von Windows leiden weniger unter diesem Problem im Anschluss an die Einführung des.NET Fachwerks, COM ohne Registrierungen und der Eigenschaften im Betriebssystem, die Systemdateien davon abhalten, überschrieben zu werden.

Probleme

Es gibt mehrere Probleme, die allgemein mit DLLs - besonders gestoßen sind, nachdem zahlreiche Anwendungen installiert und auf einem System deinstalliert worden sind.

Die Schwierigkeiten schließen Konflikte zwischen DLL Versionen ein, Schwierigkeit vorzuherrschen hat DLLs verlangt, und viele unnötige DLL-Kopien zu haben.

Unvereinbare Versionen

Eine besondere Version einer Bibliothek kann mit einigen vereinbar (und mit anderem unvereinbar sein) Programme, die sie verwenden. Windows ist dafür wegen seiner Betonung auf der dynamischen Verbindung von C ++ Bibliotheken und Gegenstand-Verbindung und das Einbetten (OLE) Gegenstände besonders verwundbar gewesen. C ++ exportieren Klassen viele Methoden, und eine einzelne Änderung zur Klasse (wie eine neue virtuelle Methode) kann es unvereinbar mit Programmen machen, die gegen eine frühere Version gebaut wurden. Gegenstand, der sich Verbindet und Einbettet, hat einige sehr strenge Regeln, das zu verhindern — Schnittstellen sind erforderlich, stabil zu sein, und Speicherbetriebsleiter werden nicht geteilt. Aber das ist nicht genug, weil sich die Semantik einer Klasse ändern kann. Eine "üble Programmfehler-Lage" für eine Anwendung kann die Eliminierung einer "Eigenschaft" von einem anderen sein. Vor Windows 2000 war Windows dafür verwundbar, weil der COM Klassentisch über alle Benutzer und Prozesse geteilt wurde. Nur ein COM-Gegenstand, in einem DLL/EXE konnte erklärt werden als, einen spezifischen globalen COM Klassenpersonalausweis auf einem System zu haben. Wenn ein Programm ein Beispiel dieser Klasse schaffen musste, hat es bekommen, dass der Strom war, zentral hat Durchführung eingeschrieben. Infolgedessen kann eine Installation eines Programms, das eine neue Version eines allgemeinen Gegenstands installiert, andere Programme unachtsam brechen, die vorher installiert wurden.

Stampfender DLL

Ein allgemeines und lästiges Problem kommt vor, wenn ein kürzlich installiertes Programm ein Arbeitssystem DLL mit einer früheren, unvereinbaren Version überschreibt. Ein frühes Beispiel davon war und Bibliotheken für Windows 3.1, das zahlreiche aktualisierte Versionen hatte, die in freier Wildbahn erscheinen. Stampfender DLL kommt weil vor:

:* Microsoft im vorigen verteilten DLLs während Laufzeit als geteilte Systembestandteile, (ursprünglich C:\WINDOWS und C:\WINDOWS\SYSTEM), als ein Weg, effizient Code in einem geteilten Gedächtnis OS mit dem beschränkten RAM und Speicherplatz zu teilen. Folglich haben Drittentwickler auch diese auf solcher Art und Weise verteilt.

:* Anwendungsmonteure werden normalerweise in einem privilegierten Sicherheitszusammenhang durchgeführt, der Zugang hat, um DLLs in die Systemverzeichnisse zu installieren, und die Systemregistrierung zu editieren, um neuen DLLs als COM Gegenstände einzuschreiben. Ein schlecht geschriebener oder misconfigured Monteur kann deshalb eine Systembibliothek auf Vermächtnis-Versionen von Windows degradieren, auf dem Windows-Dateischutz oder Windows-Quellenschutz die Änderung nicht wiederholen. Auf der Windows-Aussicht und später kann nur der "vertraute Monteur" Rechnung Änderungen mit Kernbetriebssystembibliotheken vornehmen.

:* Windows-Anwendungen wurden erlaubt, OS-Aktualisierungen in ihre eigenen Installationsprogramme einzuschließen. D. h. viele Microsoft DLLs ist wiederverteilbar, die Anwendungen vorhabend, kommen, um sie einzuschließen, wenn sie die Dienstleistungen der besonderen Bibliotheken brauchen.

:* Vor dem Windows-Monteur waren Windows-Monteure historisch kommerzielle Produkte; viele Menschen haben versucht, ihre eigenen Monteure zu schreiben, überblickend oder versioning Probleme im Prozess misshandelnd.

:* Einige Entwicklungsumgebungen haben keine Versionsquelle in ihren kompilierten Bibliotheken automatisch hinzugefügt, so viele Entwickler haben diesen Aspekt überblickt. Die Überprüfung von Dateidaten, das Überschreiben vorhandener Dateien oder das Auslassen der Kopie-Operation, wenn der DLL bereits installiert wurde, waren die einzigen anstatt richtigen versioning verfügbaren Optionen.

:* Manchmal hat der OS selbst entfernt oder hat DLLs durch ältere oder veraltete Versionen ersetzt. Zum Beispiel würde Windows 2000 schwarzen und weißen Drucker DLLs oben auf farbenbewusstem DLLs installieren, wenn ein schwarzer und weißer Drucker nach dem Farbendrucker installiert würde.

Falsche COM Registrierung

In COM und anderen Teilen von Windows, vor der Einführung von nebeneinander Bauteilen ohne Registrierungen, wurde die Registrierung verwendet, um der zu bestimmen, DLL unterliegend, um zu verwenden. Wenn eine verschiedene Version eines Moduls eingeschrieben würde, würde dieser DLL statt des erwarteten geladen. Dieses Drehbuch konnte durch widerstreitende Installationen verursacht werden, die verschiedene Versionen derselben Bibliotheken einschreiben, in welchem Fall die letzte Installation vorherrschen würde.

Geteilte Module im Gedächtnis

16-Bit-Versionen von Windows (und Windows auf Windows) laden nur ein Beispiel von irgendwelchem gegeben DLL; alle Anwendungen bringen in derselben Kopie im Gedächtnis Verweise an, bis keine Anwendungen sie verwenden und sie auswendig ausgeladen wird. (Für 32-bit- und 64-Bit-Versionen von Windows kommt Zwischenprozess, der sich teilt, vor nur dort, wo verschiedene executables ein Modul aus genau demselben Verzeichnis laden; der Code, aber nicht der Stapel wird zwischen Prozessen durch einen Prozess genannt "kartografisch darstellendes Gedächtnis" geteilt.) So, selbst wenn der gewünschte DLL in einem Verzeichnis gelegen wird, wo, wie man erwarten kann, er, solcher als im Systemverzeichnis oder dem Anwendungsverzeichnis gefunden wird, wird keines dieser Beispiele verwendet, wenn eine andere Anwendung mit einer unvereinbaren Version aus einem dritten Verzeichnis angefangen hat. Dieses Problem kann sich als ein 16-Bit-Anwendungsfehler äußern, der nur vorkommt, wenn Anwendungen in einer spezifischen Ordnung angefangen werden.

Fehlen Sie von der Brauchbarkeit

Im direkten Konflikt mit dem DLL stampfendes Problem: Wenn Aktualisierungen zu einem DLL alle Anwendungen nicht betreffen, die ihn verwenden, dann wird es viel härter, den DLL 'zu bedienen' - d. h. Probleme zu beseitigen, die in den jetzigen Versionen des DLL bestehen. (Üble Sicherheitslagen sind ein besonders zwingender und schmerzhafter, Fall.), Anstatt gerade die letzte Version des DLL zu befestigen, muss der implementor ihre üblen Lagen ideal machen, und sie für die Vereinbarkeit auf jeder veröffentlichten Version des DLL prüfen.

Ursachen

DLL Inkompatibilität ist verursacht worden durch:

• Speichereinschränkungen, die mit dem Mangel an der Trennung des Prozess-Speicherraums in 16-Bit-Versionen von Windows verbunden sind
• Fehlen Sie vom erzwungenen Standard versioning, dem Namengeben und den Dateisystempositionsdiagrammen für DLLs;
• Fehlen Sie von einer erzwungenen Standardmethode an der Softwareinstallation und (Paket-Management) umziehend;
• Zentralisierte herrische Unterstützung für die DLL Anwendung binäres Schnittstelle-Management und Schutz, unvereinbarem DLLs mit demselben Dateinamen und inneren zu veröffentlichenden Versionsnummern erlaubend;
• Allzu vereinfachte Verwaltungswerkzeuge, die Identifizierung von geändertem oder problematischem DLLs durch Benutzer und Verwalter verhindernd.
• Entwickler, die rückwärts gerichtete Vereinbarkeit von Funktionen in geteilten Modulen brechen;
• Microsoft, das Aktualisierungen aus dem Band zu Betriebssystemlaufzeitbestandteilen veröffentlicht;
• Unfähigkeit von früheren Versionen von Windows, um nebeneinander widerstreitende Versionen derselben Bibliothek zu führen;
• Das Vertrauen auf dem aktuellen Verzeichnis oder der %PATH %-Umgebungsvariable, von denen beide sich mit der Zeit und vom System bis System ändern, um abhängigen DLLs zu finden (anstatt sie aus einem ausführlich konfigurierten Verzeichnis zu laden.)
• Entwickler, die ClassIDs aus Beispielanwendungen für die COM Schnittstellen ihrer Anwendungen wiederverwenden, anstatt ihren eigenen neuen GUIDs zu erzeugen.

DLL Hölle war ein sehr allgemeines Phänomen auf Versionen des Vorwindows NT des Microsofts Betriebssysteme, die primäre Ursache, die ist, dass die 16 Bit, haben Betriebssysteme Prozesse auf ihren eigenen Speicherraum nicht eingeschränkt, dadurch ihnen nicht erlaubend, ihre eigene Version eines geteilten Moduls zu laden, mit dem sie vereinbar waren. Wie man erwartete, waren Anwendungsmonteure gute Bürger und haben DLL Versionsinformation vor dem Überschreiben des vorhandenen Systems DLLs nachgeprüft. Standardwerkzeuge, um Anwendungsaufstellung zu vereinfachen (der immer das Verschiffen des abhängigen Betriebssystems DLLs einschließt) wurden von Microsoft und anderen 3. Parteiwerkzeug-Verkäufern zur Verfügung gestellt. Microsoft hat sogar verlangt, dass Anwendungsverkäufer einen Standardmonteur verwendet haben und ihr Installationsprogramm bescheinigen lassen haben, richtig zu arbeiten, bevor es des Gebrauches des Firmenzeichens von Microsoft gewährt wird. Die gute Bürger-Monteur-Annäherung hat das Problem nicht gelindert, weil der Anstieg der Beliebtheit des Internets mehr Gelegenheiten zur Verfügung gestellt hat, nonkonformistische Anwendungen zu erhalten.

Gebrauch durch malware

Die Zweideutigkeit, mit der DLLs, die nicht völlig qualifiziert werden, in Windows Betriebssystem geladen werden können, ist durch malware in den letzten Jahren ausgenutzt worden, eine neue Klasse der Verwundbarkeit öffnend, die Anwendungen von vielen verschiedenen Softwareverkäufern, sowie Windows selbst betrifft.

Lösungen

Verschiedene Formen der DLL Hölle sind gelöst oder im Laufe der Jahre gelindert worden.

Statische Verbindung

Eine der einfachsten Lösungen der DLL Hölle in einer Anwendung soll sich gegen alle Bibliotheken statisch verbinden. Das ist in C/C ++ Anwendungen üblich, wo, anstatt beunruhigend sein zu müssen, über den Version dessen MFC42.DLL installiert wird, die Anwendung kompiliert wird, um gegen dieselben Bibliotheken statisch verbunden zu werden. Das beseitigt den DLLs völlig, und ist für eigenständige Anwendungen lebensfähig, die nur Bibliotheken verwenden, die eine statische Auswahl anbieten, wie Microsoft Foundation Class Library tut. Der Hauptzweck von DLLs (Laufzeitbibliothek, die sich zwischen Programmen teilt, um Gedächtnis oben zu reduzieren), wird geopfert obwohl, mehr Software bloat gebend, und kann richtige Fortpflanzung von üblen Sicherheitslagen verhindern.

Windows-Dateischutz

Überschreibendes Problem des DLL (verwiesen auf als DLL, der innerhalb des Microsofts Stampft), wurde mit Windows File Protection (WFP) etwas reduziert, der in Windows 2000 eingeführt wurde. Das hält unerlaubte Anwendungen davon ab, System DLLs zu überschreiben, wenn sie spezifisches Windows APIs nicht verwenden, die das erlauben. Es kann noch eine Gefahr geben, dass Aktualisierungen von Microsoft mit vorhandenen Anwendungen unvereinbar sind, aber diese Gefahr wird normalerweise in jetzigen Versionen von Windows durch den Gebrauch von nebeneinander Bauteilen reduziert.

Drittanwendungen können auf OS Dateien nicht stampfen, wenn sie legitime Windows-Aktualisierungen mit ihrem Monteur nicht stopfen, oder wenn sie den Windows-Dateischutzdienst während der Installation, und auf der Windows-Aussicht unbrauchbar machen oder später auch Eigentumsrecht von Systemdateien nehmen und sich Zugang gewähren. Das SFC Dienstprogramm konnte diese Änderungen jederzeit zurückkehren.

Das Laufen, das DLLs gleichzeitig kollidiert

Die Lösungen hier bestehen daraus, verschiedene Kopien desselben DLLs für jede Anwendung sowohl auf der Platte als auch im Gedächtnis zu haben.

Eine leichte manuelle Lösung von Konflikten legte die verschiedenen Versionen des Problems DLL in die Mappen der Anwendungen, aber nicht eine allgemeine weites System Mappe. Das arbeitet im Allgemeinen, so lange die Anwendung 32 Bit oder 64 Bit ist, und dass der DLL geteiltes Gedächtnis nicht verwendet. Im Fall von 16-Bit-Anwendungen können die zwei Anwendungen nicht gleichzeitig auf einer 16-Bit-Plattform, oder in derselben virtuellen 16-Bit-Maschine weniger als ein 32 Bit Betriebssystem durchgeführt werden. OLE hat das vor Windows XP verhindert, weil frühere Versionen von Windows eine einzelne Registrierung von COM-Gegenständen für alle Anwendungen hatten.

Windows XP hat eine Lösung genannt Nebeneinander der Zusammenbau eingeführt

(MSDN Seite), der getrennte Kopien von DLLs für jede Anwendung lädt, die sie verlangt (und erlaubt so Anwendungen, die verlangen, dass das Widersprechen DLLs gleichzeitig läuft). Diese Annäherung beseitigt Konflikte, indem sie Anwendungen erlaubt wird, einzigartige Versionen eines Moduls in ihren Adressraum zu laden, während sie den primären Vorteil bewahrt, DLLs zwischen Anwendungen zu teilen (d. h. Speichergebrauch zu reduzieren), durch das Verwenden von Speichertechniken der kartografisch darstellenden, um allgemeinen Code zwischen verschiedenen Prozessen zu teilen, die wirklich noch dasselbe Modul verwenden. Und doch kann DLLs das Verwenden von geteilten Daten zwischen vielfachen Prozessen nicht diese Annäherung nehmen. Eine negative Nebenwirkung ist verwaiste Beispiele von DLLs kann während automatisierter Prozesse nicht aktualisiert werden.

Tragbare Anwendungen

Tragbare Anwendungen (auch bekannt als "tragbarer apps") sind eine wirksame Weise, DLL Probleme zu reduzieren, da jedes Programm ihren erforderlichen DLLs gestopft - in (auch manchmal genannt "private Bibliotheken") enthält. Mechanismus ist geteilte Bibliothekspolitik von Windows, die lokal (Anwendungsverzeichnis) verfügbaren DLLs vor demjenigen im Systembibliothekspfad bevorzugt. Manchmal laufen Anwendungen in einer "Luftblase" mit der Anwendungsvirtualisierung, die vermeidet, DLL Dateien ins Betriebssystem zu installieren.

Andere Gegenmaßnahmen

Es gibt andere Gegenmaßnahmen, um DLL Hölle zu vermeiden, von denen einige gleichzeitig können verwendet werden müssen:

Einige andere Eigenschaften, die helfen, das Problem zu lindern, sind

• Installationswerkzeuge werden jetzt in Microsoft Visual Studio, eine der Hauptumgebungen für die Windows-Entwicklung gestopft. Diese Werkzeuge führen Version durch, die vor der DLL Installation überprüft, und können vorherbestimmte Installationspakete in eine.MSI Installation einschließen. Das erlaubt Drittanwendungen, OS Teilaktualisierungen zu integrieren, ohne ihre eigenen Monteure für diese Bestandteile schreiben zu müssen.
• System stellt Wieder her kann ein System von einer schlechten Installation einschließlich des Registrierungsschadens wieder erlangen. Während das das Problem nicht verhindert, macht es es leichter sich zu erholen.
• WinSxS (Windows Nebeneinander) Mappe, die vielfachen Versionen derselben Bibliotheken erlaubt zu koexistieren.
• Führen Sie 16-Bit-Anwendungen im getrennten Speicherraum weniger als eine 32-Bit-Version von Windows, um zwei Anwendungen zu erlauben, widerstreitende Versionen desselben DLL zur gleichen Zeit zu verwenden.
• Verwenden Sie eine Version von Windows, das Windows-Dateischutz einschließt. Windows Ich und Windows 2000, beide befreit 2000, unterstützt diese Form des Systemdateischutzes, wie Windows XP und Windows Server 2003 tun. Sein Ersatz, Windows-Quellenschutz, wurde in der Windows-Aussicht und dem Windows-Server 2008 eingeführt, und verwendet eine verschiedene Methode, Systemdateien davor zu schützen, geändert zu werden.
• Registrierungsfreier COM: Windows XP hat eine neue Weise der COM-Gegenstand-Registrierung genannt "Registrierungsfreier COM" eingeführt. Diese Eigenschaft macht es möglich für Anwendungen, die COM-Gegenstände installieren müssen, die ganze erforderliche COM Registrierungsinformation im eigenen Verzeichnis der Anwendung, statt in der globalen Systemregistrierung zu versorgen. So stellt es einen Mechanismus für vielfache Versionen desselben DLL zur Verfügung, der zur gleichen Zeit durch vielfache Anwendungen einzuschreiben ist (Microsoft nennt das "Nebeneinander Zusammenbau"). DLL Hölle kann mit Registrierungsfreiem COM wesentlich vermieden werden, die einzige Beschränkung, die es ist, verlangt mindestens Windows XP oder spätere Windows-Versionen, und dass es für EXE COM Server oder weites System Bestandteile wie MDAC, MSXML, DirectX oder Internet Explorer nicht verwendet werden muss.
• Das Verschiffen des Betriebssystems mit einem fähigen Paket-Verwaltungssystem, das im Stande ist, die DLL Abhängigkeiten zu verfolgen, den Gebrauch des Paket-Betriebsleiters und die entmutigende manuelle Installation von DLLs fördernd. Windows-Monteur, der mit Windows Ich, Windows 2000 und alle späteren Versionen eingeschlossen ist, stellt diese Funktionalität zur Verfügung.
• Eine Hauptdatenbank oder Autorität für die DLL-Konfliktentschlossenheit und den Softwarevertrieb habend. Änderungen zu einer Bibliothek können zu dieser Autorität vorgelegt werden; so kann es sicherstellen, dass Vereinbarkeit in den entwickelten Zweigen bewahrt wird. Wenn eine ältere Software mit der aktuellen Bibliothek unvereinbar ist, kann die Autorität eine Vereinbarkeitsschnittstelle dafür zur Verfügung stellen, oder die alte Version als ein verschiedenes Paket stopfen.
• Wenn Softwareentwickler eine Bibliothek kundengerecht anfertigen müssen, und wenn die Hauptbibliotheksausgabe kaum die Änderungen vereinigen wird, die sie brauchen, können sie den kundengerecht angefertigten DLL für den privaten Gebrauch des Programms (allgemein verladen, indem sie sie ins private Verzeichnis des Programms legen), oder statisch das Programm gegen die kundengerecht angefertigte Bibliothek verbinden.
• Während DLLs für modularizing Anwendungen und die Bestandteile des Systems und als Drittbibliotheken am besten sind, ist ihr Gebrauch in allen Fällen auf modernen Systemen nicht befehlend, wo Gedächtnis nicht mehr eine Einschränkung ist. Zum Beispiel, wenn eine Anwendung eine Bibliothek braucht, die irgendwo anders nicht verwendet wird, kann sie statisch ohne Raumstrafe und mit einem Geschwindigkeitsgewinn verbunden werden.
• Windows-Aussicht und späterer Gebrauch ein spezieller Dienst von TrustedInstaller, Betriebssystemdateien zu installieren. Anderer Benutzer legt einschließlich des SYSTEMS Rechenschaft ab, haben Sie keinen Zugang, um Kernsystemdualzahlen zu überschreiben. Windows 7 breitet diese Funktionalität zu einigen kritischen Teilen der Registrierung aus.
• Webbasierte Anwendungen vermeiden viele nebeneinander Probleme durch das Laufen des Hauptteils des Codes auf einem Server und das Verwenden einer Browser-Schnittstelle auf dem Kunden.

Siehe auch

• Abhängigkeitshölle
• Tragbare Anwendung
• Tragbare Anwendungsschöpfer
• GLAS-Hölle

Links

• Aus DLL Hölle auf Microsoft TechNet herauskommend
• Die Vereinfachung der Aufstellung und das Lösen der DLL Hölle mit dem.NET Fachwerk auf MSDN
• Das Vermeiden DLL Hölle: Das Einführen der Anwendung Metadata im Microsoft.NET Fachwerk durch Matt Pietrek
• Dr Dobb auf der DLL Hölle (Details auf LoadLibraryEx)
• Joel auf der Softwarediskussion
• Artikel über die DLL Hölle