Programmbibliothek

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

Bibliotheken sind im Unterschied zu Programmen keine eigenständig lauffähigen Einheiten, sondern Hilfsmodule, die Programmen zur Verfügung gestellt werden. Programmbibliotheken, die zu kommerziellen Produkten gehören, werden nicht im Quelltext veröffentlicht, da sie meist ein Firmengeheimnis darstellen. Zum Schutz gegen Dekompilieren werden dann oft ein Obfuscator eingesetzt sowie alle Symbole entfernt.

Quelltextbibliotheken

Quelltextbibliotheken enthalten Sammlungen von Wertedefinitionen, Deklarationen, Funktionen, Klassen, generischen Bestandteilen, usw. (siehe auch: API, C-Standardbibliothek, C++-Standardbibliothek). Im Unterschied zu den anderen Arten von Programmbibliotheken sind die zugehörigen Dateien noch nicht kompiliert, daher der Quelltext im Namen.

Statische Bibliotheken

Statische Bibliotheken sind bereits vorab kompilierter Code. Eine statische Bibliothek wird nach dem Kompiliervorgang des Programms durch einen so genannten Linker mit dem Kompilat verbunden – er setzt aus Bibliothek und Programm ein ausführbares Programm oder auch eine andere ausführbare Komponente zusammen.

Der Linker sucht aus den zugeordneten Bibliotheksdateien die referenzierten Komponenten (Unterprogramme oder Daten) heraus, auf die aus dem Programm verwiesen wird (und für die es im Programm keine Implementierung gibt), und hängt sie dann an das Programm an. Die so entstehende Datei wird entsprechend größer.

Dynamische Bibliotheken

Dynamische Bibliotheken werden erst bei Bedarf (also nach dem Programmstart des „fertigen“ Anwendungsprogramms) von einem sogenannten Lader oder Linker (von englisch „to link”: verknüpfen) in den Arbeitsspeicher geladen. Das geschieht entweder durch eine explizite Anweisung durch das Programm oder implizit durch einen so genannten Laufzeit-Lader, wenn das Programm dynamisch gebunden wurde.

Programme und Bibliotheken, die dynamisch gebunden wurden, müssen sich um das Laden der benötigten dynamischen Bibliotheken nicht selbst kümmern. Beim dynamischen Binden werden Bibliothek und Kompilat nur lose verknüpft. Statt die notwendigen Symbole zu kopieren, wie beim statischen Binden der Fall, werden sie nur referenziert. Um das Laden der dynamischen Bibliotheken und Suchen der Symbole kümmert sich ein sogenannter Laufzeit-Binder. Das Auflösen der referenzierten Symbole geschieht entweder sofort (noch vor Start des eigentlichen Programms bzw. beim Laden der Bibliothek) oder faul, bei der ersten Verwendung des Symbols.

Ein typischer Anwendungsfall dafür, Bibliotheken explizit zu öffnen (die Adresse von Symbolen nach deren Namen zu suchen, um das Symbol zu verwenden), sind Plug-in-Architekturen. Ein weiteres Szenario ist eine optionale Bibliothek, die verwendet wird, falls vorhanden, deren Fehlen aber keinen Fehler darstellt.

Ein Vorteil von dynamischen Bibliotheken ist, dass Programme, die eine dynamische Bibliothek verwenden, von Fehlerbehebungen in der Bibliothek profitieren, ohne neu übersetzt werden zu müssen. Wird beispielsweise ein Fehler in der OpenSSL-Bibliothek gefunden und behoben (die entsprechende Bibliothek wurde ersetzt), so genügt ein Neustart der Programme, die diese Bibliothek verwenden, um den Fehler auch in diesen Programmen zu beheben.

Da die Dateien, in denen dynamische Bibliotheken gespeichert werden, bei der Benutzung nur gelesen und ausgeführt, aber nicht verändert werden, können Betriebssysteme mit virtuellem Speicher dynamische Bibliotheken nur einmal laden und in den Adressraum aller verwendenden Prozesse einblenden („Caching“). Dies ist beispielsweise bei Multitasking-Systemen vorteilhaft, wenn die Bibliotheken insgesamt sehr groß sind und von vielen Prozessen gleichzeitig verwendet werden. (Sollte die DLL interne Zustände oder gespeicherte Daten besitzen, kann dies mit Copy-On-Write abgefangen werden.) Viele moderne Betriebssysteme „laden“ die DLLs jedoch nicht sofort, sondern blenden sie direkt von der Festplatte aus ein – sie werden wie paged-out Memory Pages behandelt. Analog werden nicht benötigte Pages, die zu einer DLL gehören, nicht verändert wurden und paged-out werden sollen, einfach verworfen – sie sind ja (in der DLL-Datei) schon auf der Festplatte.

Bibliotheken in verschiedenen Programmiersprachen

Bibliotheken in Programmiersprachen enthalten Dienste, 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 (C89+Amendments)	1	18	142
C (C99)	1	24	482
C++	1	32 + 18 (C89)
Java 2 (JDK 1.2)	62	1287	ca 18.000
Java 6	202	3.850	21.881
.Net 1.1		8.643	84.112

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, dass die DLLs bis Windows 98 und Windows NT 4.0 nicht kontrolliert werden – jedes Programm darf sie austauschen und kann dem Betriebssystem damit möglicherweise Schaden zufügen. Windows Me, Windows 2000 und die Folgeversionen hingegen verfügen über einen Systemschutz, der auch die DLLs einbezieht.

Vorteile

• Außer Code können auch Daten (zum Beispiel Dialog-Ressourcen) von mehreren Prozessen gemeinsam genutzt werden.
• DLLs werden häufig statisch verlinkt, können aber auch dynamisch (daher der Name) verlinkt 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. Das heißt 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 nach 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 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.

Unixartige Systeme

Auf unixartigen Betriebssystemen (wie z.B. Linux) ist für dynamische Bibliotheken die Bezeichnung shared library (englisch für „gemeinsam genutzte Bibliothek”) gebräuchlich. Sehr verbreitet ist das Executable and Linking Format (ELF), das Standard-Format unter anderem von Linux, FreeBSD und Solaris.

Für diese Dateien hat sich die Endung .so (von shared object, „gemeinsam genutztes Objekt”) etabliert. In der Regel folgt dem Bibliotheksnamen noch die Versionsnummer der Binärschnittstelle (ABI version), so dass mehrere Versionen einer Bibliothek gleichzeitig installiert sein können. Der Laufzeit-Linker wählt anhand von Versions-Informationen im auszuführenden Programm bzw. in der zu ladenden Bibliothek eine Version mit einer kompatiblen Schnittstelle aus. Da sowohl Programme von Bibliotheken abhängen können, als auch Bibliotheken von weiteren Bibliotheken, kann eine Software indirekt von vielen Bibliotheken abhängen. Einige Unixoide Systeme stellen eine Paketverwaltung bereit, die Abhängigkeiten berechnen und benötigte Bibliotheken automatisch installieren können. Beispiele für derartige Paketverwaltungs-Systeme sind APT und YUM.

Von welchen Bibliotheken ein Programm direkt abhängt, lässt sich auf einigen Systemen mit Hilfe des UNIX-Programms ldd(1) herausfinden.

Statische Bibliotheken verwenden den Dateisuffix .a (von „Archiv”) und können mit den UNIX-Programmen ar(1) und nm(1) angesehen und bearbeitet werden. Bei Systemen, die eine Paketverwaltung anbieten, befinden sich statische Bibliotheken oft zusammen mit den Header-Dateien in einem separaten Entwicklungs-Paket.

Bei kommerzieller Software, die nur als Binärversion verfügbar ist (Closed Source Software), muss gewährleistet werden, dass alle benötigten Bibliotheken in einer kompatiblen Version vorliegen. Dies kann folgendermaßen geschehen:

• Angabe einer kompatiblen Betriebssystem-Distribution, zum Beispiel: „Lauffähig unter Debian 5.0 (Lenny)”.
• Verwendung eines distributionsspezifisches Paketes, so dass benötigte Bibliotheken vom Paketmanager nachgeladen werden.
• Mitliefern aller dynamischen Bibliotheken. Diese werden, zusammen mit dem Programm, Dokumentation, etc. in ein separates Verzeichnis kopiert, um nicht mit Versionen, die von der Paketverwaltung installiert wurden, zu kollidieren.
• Verzicht auf dynamische Bibliotheken und Verwendung statischen Bindens.

Objekt- und komponentenorienterte Ansätze können hier realisiert werden, indem in einer Funktion das entsprechende Objekt oder die Komponente instantiiert und zurückgegeben werden.

Vorteile

• Gemeinsame Nutzung von Ressourcen
• Eine enorme Anzahl von freien und mitgelieferten Bibliotheken stehen zur Verfügung
• Bibliotheken können unabhängig vom Hauptprogramm ausgebessert werden und Programmupdates werden kleiner
• Optimierungen an einer Stelle können das ganze System beschleunigen
• Können schnell veränderliche Systemaufrufe verbergen
• Abstrahieren von low-level Problemen

Nachteile

• Probleme in essentiellen Bibliotheken machen Systeme unbenutzbar. Durch entsprechende Skripte der Paketverwaltung ist bei modernen Distributionen jedoch meist sichergestellt, dass dies nicht passieren kann.
• Bei inkompatiblen Veränderungen der Binärschnittstelle müssen alle abhängigen Programme neu kompiliert werden, dies kann durch Versionsnummern und parallele Verwendung von Paketen vermieden werden.
• Bei inkompatiblen Veränderungen der Programmierschnittstelle müssen alle abhängigen Programme entsprechend angepasst werden.

Java

Java ist eine eigene Plattform und verwendet ein Bibliothekskonzept, welches nicht an Betriebssysteme gebunden ist. Alle Klassen werden hier dynamisch geladen. Die Bibliotheken sind hierbei die jar-Files oder auch einzelne class-Files. System-jar-Files sucht die virtuelle Maschine (VM) immer relativ zu ihrem eigenem Verzeichnis.

Da die Bibliotheken erst zur Laufzeit geladen werden, kann das erstmalige Aufrufen einer Funktionalität etwas länger dauern. In Java für Realtimesysteme, aber auch im Standard-Java kann der Klassenlader durch entsprechende Methodenaufrufe dazu bewegt werden, bestimmte oder alle notwendigen Bibliotheken beim Starten zu laden und sie auch nicht mehr zu entladen, so dass bei der Benutzung kein (weiterer) unerwarteter Zeitverzug entstehen kann.

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 am Ende der Tabellen. Somit ist eine Abwärtskompatibilität gegeben.

Als Besonderheit kann bei AmigaOS beim Öffnen einer Library eine Mindest-Versionsnummer angegeben und so sichergestellt werden, dass eine gewünschte Funktionalität auch wirklich verfügbar ist. Wird diese Version nicht vorgefunden, kann das aufrufende Programm sicher auf eine einfachere Funktionalität, wie sie in der älteren Library-Version bereitgestellt wird, zurückschalten.

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

• MFC (Microsoft Foundation Classes)
• VCL (Visual Component Library)
• CLX (Component Library for Cross Platform Development) auch bekannt als VCL für Linux
• NAG Numerical Libraries

Siehe auch

• Komponentenbibliothek