Nächste Seite: A. Anhang Aufwärts: Dynamische Bibliotheken unter Windows Vorherige Seite: 6 Wie eine dynamische Inhalt
Unter Windows gibt es keinen echten Mechanismus, mehrere Versionen einer DLL auf einem Rechner zu halten, und verschiedenen Programmen gezielt bestimmte Versionen zuordnen zu können. Als Ausweg bleibt eigentlich nur, zu jedem Programm die passenden DLLs in das selbe Verzeichnis zu kopieren, und auf die richtige Suchreihenfolge seitens Windows zu vertrauen (siehe Wie eine dynamische Bibliothek gefunden wird).
Damit wird zwar die Platzersparnis durch dynamische Bibliotheken verschenkt, aber was will man machen. Hier rächt sich halt das konzeptlose Umsetzen einer an sich guten Idee.
Eigentlich sollte das alles kein Problem sein, weil Microsoft verlangt, daß von einer DLL mit einem bestimmten Namen immer nur die neueste Version auf einem Rechner vorhanden sein soll, und diese Version alles kann, was alle älteren Versionen auch konnten - und zwar so kompatibel, daß Programme, die mit einer älteren LIB-Datei gelinkt wurden, keinen Unterschied erkennen können.
Bei jeder Installation einer DLL soll das Installationsprogramm eine ältere Version einfach überschreiben, und die alten Programm müssten ungestört weiter funktionieren.
(Soweit die Theorie.)
Unter Unix und Linux dagegen hat es sich eingebürgert, alle Bibliotheken, also auch shared objects, mit einer (meist) dreistufigen Versionsnummer zu versehen. Diese drei Zahlen werden einfach mit Punkten getrennt an den Dateinamen angehängt.
Die Bibliothek mit den Funktionen aus awutil.h, also libawutil.so, heißt also in Wirklichkeit libawutil.so.1.0.0, wenn sie in der ersten Version vorliegt.
Der eigentliche Name der Bibliothek (ohne Versionsnummern, also etwa libawutil.so) wird dann als symbolischer Link (siehe man 1 ln) auf die höchste existierende Hauptversion (libawutil.so.1) angelegt. Diese Datei ist wiederum nur ein symbolischer Link auf ihre zugehörige höchste Unterversion (libawutil.so.1.0); diese ist dann analog ein symbolischer Link auf ihre höchste Unterversion (libawutil.so.1.0.0).
Bei kleineren Änderungen (beispielsweise reine Fehlerkorrekturen) ändert man nur die letzte Nummer, und installiert also bei mehreren Korrekturen nacheinander die Versionen libawutil.so.1.0.1, libawutil.so.1.0.2 und libawutil.so.1.0.3. Der symbolische Link libawutil.so.1.0 wird dabei jeweils angepaßt, so daß neu gelinkte Programme immer die aktuelle Version bekommen.
Wenn man Erweiterungen der Bibliothek vornimmt, die rückwärtskompatibel sind, dann erhöht man die mittlere Zahl. Die zugehörigen Fehlerkorrekturen drücken sich dann wieder in der letzten Zahl aus. Beispielsweise würde man dann nacheinander die Versionen libawutil.so.1.1.0, libawutil.so.1.1.1 und libawutil.so.1.1.2 installieren.
Dabei sind wieder die symbolischen Links anzupassen.
Auf einem konkreten Rechner könnte das anfangs so aussehen:
klaus@aw33:~ > ls -l /usr/local/lib/ ... lrwxrwxrwx 1 root root 14 Sep 29 2000 libawutil.so -> libawutil.so.1 lrwxrwxrwx 1 root root 16 Sep 29 2000 libawutil.so.1 -> libawutil.so.1.0 lrwxrwxrwx 1 root root 18 Sep 29 2000 libawutil.so.1.0 -> libawutil.so.1.0.0 -rwxr-xr-x 1 root root 110500 Sep 29 2000 libawutil.so.1.0.0 ...Wenn ein Programm mit einer der Bibliotheken libawutil.so, libawutil.so.1, libawutil.so.1.0 oder libawutil.so.1.0.0 gelinkt wird, dann wird in allen drei Fällen effektiv dieselbe Bibliothek verwendet. Jedes so gelinkte Programm wird dementsprechend nach dem Starten Funktionen aus libawutil.so.1.0.0 aufrufen können.
Installiert man jetzt eine fehlerbereinigte Version libawutil.so.1.0.1 und danach libawutil.so.1.0.2, dann paßt man die symbolischen Links entsprechend an; das Inhaltsverzeichnis könnte dann etwa so aussehen:
klaus@aw33:~ > ls -l /usr/local/lib/ ... lrwxrwxrwx 1 root root 14 Sep 29 2000 libawutil.so -> libawutil.so.1 lrwxrwxrwx 1 root root 16 Sep 29 2000 libawutil.so.1 -> libawutil.so.1.0 lrwxrwxrwx 1 root root 18 Dec 24 2000 libawutil.so.1.0 -> libawutil.so.1.0.2 -rwxr-xr-x 1 root root 110500 Sep 29 2000 libawutil.so.1.0.0 -rwxr-xr-x 1 root root 110508 Sep 29 2000 libawutil.so.1.0.1 -rwxr-xr-x 1 root root 121760 Dec 24 2000 libawutil.so.1.0.2 ...Beim Linken von Programmen mit libawutil.so, libawutil.so.1, libawutil.so.1.0 oder libawutil.so.1.0.2 wird jetzt effektiv die Bibliothek libawutil.so.1.0.2 verwendet; so gelinkte Programme verwenden diese auch zur Laufzeit. Auch Programme. die früher bereits mit libawutil.so, libawutil.so.1, libawutil.so.1.0 gelinkt wurden, verwenden diese. Nur Programme, welche explizit mit libawutil.so.1.0.0 oder libawutil.so.1.0.1 gelinkt wurden, rufen die Funktionen daraus auf.
Wenn kurz danach eine erweiterte Version libawutil.so.1.1.0 installiert wird, die mehr Funktionalität bietet, aber rückwärtskompatibel zu libawutil.so.1.0.2 ist, dann hat das Verzeichnis so auszusehen:
klaus@aw33:~ > ls -l /usr/local/lib/ ... lrwxrwxrwx1 root root 14 Sep 29 2000 libawutil.so -> libawutil.so.1 lrwxrwxrwx1 root root 16 Dec 31 2000 libawutil.so.1 -> libawutil.so.1.1 lrwxrwxrwx1 root root 18 Dec 24 2000 libawutil.so.1.0 -> libawutil.so.1.0.2 lrwxrwxrwx1 root root 18 Dec 31 2000 libawutil.so.1.1 -> libawutil.so.1.1.0 -rwxr-xr-x1 root root 110500 Sep 29 2000 libawutil.so.1.0.0 -rwxr-xr-x1 root root 110508 Sep 29 2000 libawutil.so.1.0.1 -rwxr-xr-x1 root root 121760 Dec 24 2000 libawutil.so.1.0.2 -rwxr-xr-x1 root root 128106 Dec 31 2000 libawutil.so.1.1.0 ...
Schade daß es unter Windows keine symbolischen Links gibt...