Programmbibliothek

Eine Programmbibliothek bezeichnet in der Programmierung eine Sammlung von Programmfunktionen für zusammengehörende Aufgaben.

Bibliotheken sind im Unterschied zu Programmen keine eigenständigen Einheiten, sondern Hilfsmodule, die Programmen zur Verfügung stehen.

Quelltextbibliotheken

Quelltextbibliotheken enthalten Sammlungen von Wertedefinitionen, Deklarationen, Funktionen, Klassen, generischen Bestandteilen, usw. (siehe auch: API, C-Standardbibliothek, C++-Standardbibliothek)

Statische Bibliotheken

Statische Bibliotheken werden nach dem Kompiliervorgang durch einen so genannten Linker oder Binder in einem eigenen Schritt mit dem ausführbaren Programm verbunden.

Der Linker (Binder) sucht aus den Bibliotheksdateien Unterprogramme heraus, für die es im Programm keine Implementierung gibt. Diese werden dann aus den Dateien extrahiert und an das Programm gebunden, d.h. der Unterprogrammcode wird an den Programmcode angefügt und die Aufrufverweise werden auf die Unterprogrammadressen gerichtet.

Dynamische Bibliotheken

Dynamische Bibliotheken werden erst bei Bedarf in den Arbeitsspeicher geladen und durch den sogenannten Lader mit dem ausführbaren Programm verbunden. Dadurch muss eine Bibliothek, die von mehreren Programmen genutzt wird, nur einmal im Speicher gehalten werden.

Dies ist beispielsweise bei Multitasking-Systemen vorteilhaft, wenn die Bibliotheken insgesamt sehr groß sind und von vielen Prozessen gleichzeitig verwendet werden. Dort wird eine Bibliotheksdatei bei ihrer ersten Verwendung in den Speicher geladen. Trifft ein Programm auf den Verweis zu einem Unterprogramm, das noch nicht eingebunden wurde, dann wird ein Laufzeitbinder aktiviert. Dieser sucht das Unterprogramm in den im Speicher vorhandenen Bibliotheken, fügt die Adresse am Aufrufpunkt ein und führt das Unterprogramm erstmalig aus.

Bei jedem weiteren Aufruf des Unterprogramms ist dann die Adresse vorhanden, so dass das Unterprogramm direkt aufgerufen wird. Die Ausführungszeit, insbesondere die Startzeit eines Programms, ist hier geringfügig erhöht. Dies wird in Kauf genommen, da der Programmcode der Bibliotheksfunktionen von allen Prozessen geteilt wird. Der Speicherbedarf aller Programme zusammen ist daher in der Regel kleiner als beim statischen Linken.

Bibliotheken in verschiedenen Programmiersprachen

Bibliotheken in Programmiersprachen enthalten Leistungen, die nicht im Compiler implementiert sind, sondern in der Sprache selbst programmiert sind und mit dem Compiler zusammen oder völlig von ihm getrennt dem Programmierer zur Verfügung stehen. Im ersten Fall ist die Bibliothek meist in der Sprachbeschreibung festgelegt. Im zweiten Fall spricht man von einer externen Bibliothek.

In der Sprachbeschreibung festgelegte Bibliotheken unterscheiden sich teilweise stark im Umfang.

Sprache	Teile/Pakete	Header/Klassen	Funktionen/Methoden/Konstruktoren
C (C88+Amendments)	1	18	142
C (C99)	1	24	482
C++	1	32 + 18 (C88)
Java 2 (JDK 1.2)	60	ca 1.800	ca 18.000
Java 5 v5	166	3.279	?
.Net 1.1		ca. 8.643	ca. 84.112

Bei C99 ist zu beachten, dass es sich weitestgehend nicht um wirklich neue Leistungen handelt, sondern um Varianten schon in C88 bestehender Leistungen für andere (float, double, long double) oder neue (wchar_t) Datentypen.

Bibliotheken bei verschiedenen Betriebssystemen

Windows

Bei den Betriebssystemen Windows (und auch bei OS/2) wird eine Bibliotheksdatei, die dynamisch bindet, als DLL (für Dynamic Link Library) bezeichnet. Entsprechend haben diese Dateien meist die Dateiendung .dll. Ihr Dateiformat ist Portable Executable.

Unter Windows kann noch zwischen zwei Arten von DLLs unterschieden werden: Einsprungs-DLLs und ActiveX-DLLs. Einsprungs-DLLs enthalten Funktionen, ActiveX-DLLs enthalten Klassen.

Problematisch ist bei Windows 95, Windows 98 und Windows Me, dass durch unzureichende Schutzmaßnahmen die DLLs nicht kontrolliert werden - jedes Programm darf sie austauschen und kann dem Betriebssystem damit möglicherweise Schaden zufügen. Windows 2000 und Windows XP hingegen verfügen über einen Systemschutz, der auch die DLLs einbezieht.

Vorteile

Außer Code können Daten (z.B. Dialog-Ressourcen) geshared werden.

DLLs werden häufig statisch gelinkt, können aber auch dynamisch (daher der Name) gelinkt werden. Dynamisch heißt hier, dass die DLL explizit vom Programm zur Laufzeit geladen wird und die Funktionen, die sich in der DLL befinden, "per Hand" mit dem Programm verbunden werden. Dadurch wird es möglich, durch Austauschen der DLL die Funktionalität des Programms zur Laufzeit zu verändern.

DLLs können unabhängig vom Hauptprogramm gewartet werden. D.h. Funktionen in der DLL können ohne Wissen des Programms verändert werden. Danach wird die DLL einfach ausgetauscht (die alte DLL-Datei wird überschrieben), ohne dass das Hauptprogramm verändert werden muss.

Da die DLL als unabhängige Datei dem Hauptprogramm beiliegen muss, können Anbieter von Programmcode besser sicherstellen, dass Programmierer, die die Funktionen ihrer DLL nutzen, dafür auch bezahlen. Die Funktionalität der DLL verschwindet so nicht (wie bei einer Library) im Code des Programms. Dieser Vorteil wird von Befürwortern freier Software als Nachteil gesehen.

Nachteile

Änderungen in DLLs ziehen oft auch Änderungen im Programm mit sich. Dadurch kommt es leicht zu Versionskonflikten, die oft nur sehr schwer aufzuspüren sind.
Eine der Grundideen der DLLs war, Programmcode zwischen mehreren Programmen zu teilen, um so kostbaren Speicher zu sparen. In der Praxis ist es jedoch dazu gekommen, dass viele Programme bei der Installation DLLs in das Windows-Systemverzeichnis schreiben, die außer diesem speziellen Programm kein anderes benutzen kann.
Außerdem ist die Entwicklung und insbesondere die Anbindung im Vergleich aufwändiger als zur statischen Bibliothek.

Quintessenz

DLLs sollte man nur benutzen, wenn man ihre spezielle Funktionalität benötigt und man ausschließlich unter Windows arbeitet. Sind statische Bibliotheken für den Zweck ausreichend, sollte man diese vorziehen. In der Praxis ergeben sich keinerlei Einsparungen bei der Größe des Codes. Bei den heutigen Speichergrößen spielt die Größe des Programmcodes ohnehin kaum noch eine Rolle.

Unix-artige

Auf Unix-artigen Betriebssystemen (Unix, Linux, usw.) ist für dynamische Bibliotheken die Bezeichnung shared library (englisch shared, geteilt) gebräuchlich.

Für diese Dateien hat sich die Endung .so (shared object) eingebürgert. In der Regel folgt dem Bibliotheksnamen noch eine Versionsnummer.

Bibliotheken unter z/OS

Bei z/OS werden alle Partitioned Data Sets (PDS) als Bibliotheken bezeichnet. Die einzelnen Elemente dieser Bibliotheken werden allgemein Member oder, wenn es sich um ausführbaren Programmcode handelt, auch Module genannt.

Statische Module müssen in einer Bibliothek liegen, die dem Linkage Editor als SYSLIB bekanntgegeben wird, dynamische Module werden zur Laufzeit entweder aus der STEPLIB oder aus der JOBLIB geladen und wenn sie hier nicht gefunden werden, aus einer Bibliothek in der LINKLIST.

Bibliotheken unter AMIGA OS

Beim AmigaOS werden alle Bibliotheken als shared Library verwendet. Sie werden also zur Laufzeit vom Programm beim System angefordert, das dann die Basisadresse der Bibliothek im Speicher (bis OS3.9) oder die entsprechende Schnittstelle (ab OS4.0) zur Verfügung stellt. Das Programm verwendet dann relative Adressen, um über eine Sprungtabelle vor der Basisadresse an die eigentlichen Funktionen (hinter der Basisadresse) zu kommen. Diese Funktionen sind eintrittsinvariant (reentrant).

Selbst bei Änderungen der Bibliothek sind die bestehenden Einträge der Sprungtabellen immer gleich. Es kommen ggf. lediglich neue Einträge hinzu. Somit ist eine Abwärtskompatibilität gegeben.

Bibliotheksdateien tragen die Endung .library und befinden sich meist im Verzeichnis LIBS: der Systempartition. Das Betriebssystem überprüft bei der Suche nach einer Bibliothek auch das Programmverzeichnis des anfragenden Programms.

Beispiele

Siehe auch

Komponentenbibliothek

Bibliothek (Programmierung)

Gourt Home::Gourt :: Programmbibliothek