Die DLL-Hölle oder - Warum Dlls Nicht in Systemverzeichnisse Gehören

Unter Windows kann es zuweilen passieren, dass Programme eine bestimmte Bibliothek (dll) benötigen, die aber aus irgend einem Grund nicht mit dem Programm mitgeliefert wurde und aus diesem Grund nicht gefunden werden kann. Man muss sich die dll also von irgendwo besorgen*. Ist das dann erledigt kommt aber schon die nächste Frage: „Wohin damit?”. Einige Möchtegernexperten werden euch sicher den Tip geben, die dll ins System32- oder ein anderes Windows-Verzeichnis zu legen. Genau das solltet ihr aber auf keinen Fall tun! Warum – und was die Alternativen sind, das erkläre ich in diesem Artikel.

*Bitte ladet nicht einfach dlls von irgendwelchen zwielichtigen Seiten herunter, sondern fragt eventuell einen Freund, bei dem das Programm von Anfang an funktionierte oder macht es wie ich im Tutorial zu separate+ und nehmt die dlls aus alten Programmversionen. Die Gefahr, sich einen Virus einzufangen ist gerade bei solchen zwielichtigen „dll-Archivseiten” relativ hoch.

Wie werden Dlls von Programmen geladen?

Um das zu verstehen, können wir uns einfach mal ansehen, was genau passiert, wenn ein Gimp-Plugin (was auch einfach nur ein normales Programm ist) eine dll laden möchte:

DLL Suchreihenfolge
Das Gimp-Plugin sucht die DLL-Datei in einer festen Abfolge von Ordnern.

Wie man im Screenshot sieht, sucht das Plugin beim Laden einer dll an ganz unterschiedlichen Orten. Die Reihenfolge ist dabei immer gleich:

Zuänchst wird im Startverzeichnis des Plugins/Programms selbst gesucht. Wird die dll dort nicht gefunden, geht die Suche in den drei wichtigsten Systemverzeichnissen weiter. Wird die dll auch dort nicht gefunden, kommt noch das Verzeichnis des aufrufenden Programms dran (In diesem Fall handelt es sich um das Plugin separate, welches beim Start von Gimp geladen wird, daher wird entsprechend auch im Gimp-Installationsordner gesucht).

Wo liegt jetzt also das Problem?

Wenn ihr euch den oben gezeigten Ablauf genau anschaut, entstehen unter Umständen Probleme, wenn ihr einfach dll-Dateien in eines der Systemverzeichnisse werft. Um das ganze nicht zu kompliziert zu machen, bleiben wir mal bei gimp-plugins. Ihr habt also zunächst PluginA installiert und habt das Problem, dass eine dll fehlt oder im Gimp-Hauptverzeichnis eine falsche Version der dll liegt (Das zeichnet sich normal durch die Fehlermeldung „Prozedureinsprungspunkt nicht gefunden aus). Nun ladet ihr euch die passende dll herunter und packt sie in ein Systemverzeichnis. Bis hierhin wird alles wunderbar funktionieren und (wahrscheinlich auch) noch keine Probleme auftauchen.

Nun ladet ihr euch aber PluginB herunter, das genau die gleiche dll benötigt – ABER: in einer anderen Version als ihr sie für PluginA installiert habt! Wenn ihr jetzt Gimp startet, wird von nun an immer PluginB schon beim laden crashen, weil es ja eine dll mit passendem Namen findet, nur aufgrund der falschen Version nicht damit zurecht kommt. Da kann sogar im Gimp-Installationsverzeichnis die richtige dll liegen – da die falsche aber im Systemverzeichnis liegt, wird sie früher gefunden als die passende und damit kommt es gar nichtmehr so weit, dass die richtige dll gefunden wird.

Wohin sollen dlls denn dann sonst?

Wie schon oben beschrieben: Dlls werden immer zuerst im selben Ordner gesucht, in dem auch die exe des suchenden Programms liegt. Der sicherste Weg, einem einzelnen Programm eine dll zur Verfügung zu stellen, ist also, diese direkt in den Installationsordner des Programmes zu packen. Und um beim Beispiel der Gimp plugins zu bleiben: Hier ist es am sichersten, den einzelnen Plugins jeweils eigene Ordner zu geben, damit können Konflikte hoffentlich dann komplett vermieden werden.

Im Zweifelsfall gilt also immer: Hände weg von Systemordnern, wenn ihr nicht zu 100% wisst, was ihr da tut – man kann sich ganz einfach Probleme einfangen, die zunächst nicht bemerkbar sind, später dann aber umso mehr nerven, da man die Ursache nur noch schwer findet.