Bibliothek (Informatik) - Wikipedia

"Software-Bibliothek" leitet hier um. Es ist nicht mit Bibliotheksoftware zu verwechseln.

In diesem Artikel geht es um ein Softwareentwicklungskonzept. Ein Archiv digitaler Assets finden Sie unter Digitale Bibliothek.

Illustration einer Anwendung, die mit libvorbisfile eine Ogg Vorbis-Datei abspielt.

In der Informatik ist eine Bibliothek eine Sammlung nichtflüchtiger Ressourcen Wird von Computerprogrammen verwendet, häufig für die Softwareentwicklung. Dazu können Konfigurationsdaten, Dokumentation, Hilfedaten, Meldungsvorlagen, vorgefertigter Code und Unterprogramme, Klassen, Werte oder Typspezifikationen gehören. In OS / 360 von IBM und seinen Nachfolgern werden sie als partitionierte Datensätze bezeichnet.

Eine -Bibliothek ist auch eine Sammlung von Verhaltensimplementierungen, die in Form einer Sprache geschrieben sind und über eine gut definierte Schnittstelle verfügen, über die das Verhalten aufgerufen wird. Zum Beispiel können Personen, die ein Programm auf höherer Ebene schreiben möchten, eine Bibliothek verwenden, um Systemaufrufe durchzuführen, anstatt diese Systemaufrufe immer wieder zu implementieren. Darüber hinaus wird das Verhalten für die Wiederverwendung durch mehrere unabhängige Programme bereitgestellt. Ein Programm ruft das durch die Bibliothek bereitgestellte Verhalten über einen Sprachmechanismus auf. Beispielsweise wird in einer einfachen imperativen Sprache wie C das Verhalten in einer Bibliothek unter Verwendung des normalen Funktionsaufrufs von C aufgerufen. Was den Aufruf als eine Bibliotheksfunktion auszeichnet, im Gegensatz zu einer anderen Funktion im selben Programm, ist die Art und Weise, wie der Code im System organisiert ist.

Der Bibliothekscode ist so organisiert, dass er von mehreren Programmen verwendet werden kann, die keine Verbindung zueinander haben, während Code, der Teil eines Programms ist, so organisiert ist, dass er nur innerhalb dieses einen Programms verwendet werden kann. Diese Unterscheidung kann eine hierarchische Vorstellung gewinnen, wenn ein Programm groß wird, beispielsweise ein Programm mit mehreren Millionen Zeilen. In diesem Fall können interne Bibliotheken vorhanden sein, die von unabhängigen Unterabschnitten des großen Programms wiederverwendet werden. Das Unterscheidungsmerkmal besteht darin, dass eine Bibliothek zum Zwecke der Wiederverwendung durch unabhängige Programme oder Unterprogramme organisiert ist und der Benutzer nur die Schnittstelle und nicht die internen Details der Bibliothek kennen muss.

Der Wert einer Bibliothek liegt in der Wiederverwendung des Verhaltens. Wenn ein Programm eine Bibliothek aufruft, erhält es das in dieser Bibliothek implementierte Verhalten, ohne dieses Verhalten selbst implementieren zu müssen. Bibliotheken fördern die modulare gemeinsame Nutzung von Code und erleichtern die Verteilung des Codes.

Das von einer Bibliothek implementierte Verhalten kann in verschiedenen Phasen des Programmlebenszyklus mit dem aufrufenden Programm verbunden werden. Wenn während des Erstellens des aufrufenden Programms auf den Code der Bibliothek zugegriffen wird, wird die Bibliothek als statische Bibliothek bezeichnet. ^[1] Eine Alternative besteht darin, die ausführbare Datei des aufrufenden Programms zu erstellen und diese unabhängig von der Bibliotheksimplementierung zu verteilen. Das Bibliotheksverhalten wird verbunden, nachdem die ausführbare Datei zur Ausführung aufgerufen wurde, entweder als Teil des Prozesses zum Starten der Ausführung oder während der Ausführung. In diesem Fall wird die Bibliothek als dynamische Bibliothek bezeichnet (zur Laufzeit geladen). Eine dynamische Bibliothek kann geladen und verknüpft werden, wenn ein Programm zur Ausführung vom Linker vorbereitet wird. Alternativ kann eine Anwendung während der Ausführung explizit anfordern, dass ein Modul geladen wird.

Die meisten kompilierten Sprachen verfügen über eine Standardbibliothek, obwohl Programmierer auch eigene benutzerdefinierte Bibliotheken erstellen können. Die meisten modernen Softwaresysteme stellen Bibliotheken bereit, die die Mehrheit der Systemdienste implementieren. Solche Bibliotheken haben die Dienste modernisiert, die eine moderne Anwendung erfordert. Daher wird der meiste von modernen Anwendungen verwendete Code in diesen Systembibliotheken bereitgestellt.

Geschichte [ edit ]

Die frühesten Programmierkonzepte, die analog zu Bibliotheken waren, sollten Datendefinitionen von der Programmimplementierung trennen. JOVIAL machte 1959 das Konzept "COMPOOL" (Communication Pool) auf sich aufmerksam, übernahm jedoch die Idee der großen SAGE-Software. Nach den Informatikgrundsätzen der Trennung von Anliegen und dem Verbergen von Informationen bestand "der Zweck von Comm Pool darin, die gemeinsame Nutzung von Systemdaten durch eine zentralisierte Datenbeschreibung zu ermöglichen." ^[2]

COBOL schloss 1959 "primitive Fähigkeiten für ein Bibliothekssystem" ein, ^[3] aber Jean Sammet beschrieb sie rückblickend als "unzureichende Bibliotheksmöglichkeiten". ^[4]

Ein weiterer wichtiger Beitrag zum modernen Bibliothekskonzept kam hinzu in Form des Unterprogramms Innovation von FORTRAN. FORTRAN-Unterprogramme können unabhängig voneinander kompiliert werden, dem Compiler fehlte jedoch ein Linker. Vor der Einführung von Modulen in Fortran-90 war also die Typüberprüfung zwischen Unterprogrammen von FORTRAN ^{[NB 1]} unmöglich. ^[5]

Schließlich sollten sich Historiker des Konzepts an die einflussreiche Simula 67 erinnern Die erste objektorientierte Programmiersprache und ihre Klassen waren nahezu identisch mit dem modernen Konzept, wie es in Java, C ++ und C # verwendet wird. Das -Klassenkonzept von Simula war auch ein Vorläufer des -Pakets in Ada und des -Moduls von Modula-2. ^[6] Auch als ursprünglich 1965 entwickelt, Simula-Klassen könnten in Bibliotheksdateien aufgenommen und zur Kompilierzeit hinzugefügt werden. ^[7]

Linking [ edit ]

Bibliotheken sind wichtig im Programm oder . Bindungsprozess der die als bezeichneten Verweise oder Symbole auf Bibliotheksmodule auflöst. Der Verknüpfungsprozess wird normalerweise automatisch durch ein -Linker-Programm oder ausgeführt, das eine Reihe von Bibliotheken und anderen Modulen in einer bestimmten Reihenfolge durchsucht. Normalerweise wird es nicht als Fehler betrachtet, wenn ein Verknüpfungsziel in einer bestimmten Gruppe von Bibliotheken mehrmals gefunden werden kann. Das Verknüpfen kann erfolgen, wenn eine ausführbare Datei erstellt wird oder wenn das Programm zur Laufzeit verwendet wird.

Die aufgelösten Referenzen können Adressen für Sprünge und andere Routineaufrufe sein. Sie können sich im Hauptprogramm oder in einem Modul befinden, abhängig von einem anderen. Sie werden in feste oder verschiebbare Adressen (von einer gemeinsamen Basis) aufgelöst, indem Laufzeitspeicher für die Speichersegmente jedes referenzierten Moduls zugewiesen wird.

Einige Programmiersprachen verwenden möglicherweise eine Funktion namens Smart Linking bei der der Linker den Compiler kennt oder in diesen integriert ist, so dass der Linker weiß, wie externe Referenzen verwendet werden, und Code in einer Bibliothek, die niemals verwendet wird tatsächlich verwendet obwohl intern referenziert, kann aus der kompilierten Anwendung verworfen werden. Beispielsweise kann ein Programm, das nur Ganzzahlen für die Arithmetik verwendet oder überhaupt keine Rechenoperationen ausführt, Fließkommabibliotheksroutinen ausschließen. Diese intelligente Verknüpfungsfunktion kann zu kleineren Anwendungsdateigrößen und geringerem Speicherbedarf führen.

Verlagerung [ edit ]

Einige Verweise in einem Programm- oder Bibliotheksmodul werden in einer relativen oder symbolischen Form gespeichert, die nicht aufgelöst werden kann, bis allen Code und Bibliotheken endgültige statische Adressen zugewiesen sind. Relocation ist der Prozess zum Anpassen dieser Referenzen und wird entweder vom Linker oder vom Loader ausgeführt. Im Allgemeinen kann die Verlagerung nicht in einzelne Bibliotheken selbst vorgenommen werden, da die Adressen im Speicher je nach dem verwendeten Programm und den damit verbundenen Bibliotheken variieren können. Positionsunabhängiger Code vermeidet Verweise auf absolute Adressen und erfordert daher keine Verlagerung.

Statische Bibliotheken [ edit ]

Wenn eine Verknüpfung während der Erstellung einer ausführbaren Datei oder einer anderen Objektdatei ausgeführt wird, wird sie als statische Verknüpfung oder bezeichnet ] frühe Bindung . In diesem Fall erfolgt die Verknüpfung normalerweise über einen Linker, kann aber auch vom Compiler ausgeführt werden. Eine statische Bibliothek auch bekannt als Archiv soll statisch verlinkt werden. Ursprünglich existierten nur statische Bibliotheken. Statische Verknüpfungen müssen durchgeführt werden, wenn Module erneut kompiliert werden.

Alle von einem Programm benötigten Module werden manchmal statisch verknüpft und in die ausführbare Datei kopiert. Dieser Prozess und die resultierende eigenständige Datei werden als statische Erstellung des Programms bezeichnet. Ein statischer Build erfordert möglicherweise keine weitere Verschiebung, wenn virtueller Speicher verwendet wird und keine zufällige Anordnung des Adressraumlayouts gewünscht wird. ^[8]

Gemeinsam genutzte Bibliotheken [ edit ]

A gemeinsam genutzte Bibliothek oder gemeinsam genutztes Objekt ist eine Datei, die von ausführbaren Dateien und weiteren gemeinsam genutzten Objektdateien gemeinsam genutzt werden soll. Module, die von einem Programm verwendet werden, werden zur Ladezeit oder zur Laufzeit von einzelnen gemeinsam genutzten Objekten in den Speicher geladen, anstatt von einem Linker kopiert zu werden, wenn eine einzelne monolithisch ausführbare Datei für das Programm erstellt wird.

Freigegebene Bibliotheken können statisch verknüpft werden. Dies bedeutet, dass Verweise auf die Bibliotheksmodule aufgelöst werden und den Modulen Speicher zugewiesen wird, wenn die ausführbare Datei erstellt wird. Aber häufig wird das Verknüpfen von gemeinsam genutzten Bibliotheken verschoben, bis sie geladen werden. ^{[ dubious - Diskutieren ]}

Die meisten modernen Betriebssysteme ^{[NB 2]} können gemeinsam genutzte Bibliotheksdateien der das gleiche Format wie die ausführbaren Dateien. Dies bietet zwei Hauptvorteile: Erstens erfordert es, für beide nur einen Lader zu machen, anstatt für zwei (der einzige Lader ist seiner zusätzlichen Komplexität wert). Zweitens können die ausführbaren Dateien auch als gemeinsam genutzte Bibliotheken verwendet werden, wenn sie eine Symboltabelle haben. Typische kombinierte Formate für ausführbare und gemeinsam genutzte Bibliotheken sind ELF und Mach-O (beide in Unix) und PE (Windows).

In einigen älteren Umgebungen, z. B. 16-Bit-Windows oder MPE für den HP 3000, waren nur stapelbasierte Daten (lokal) im Code für gemeinsam genutzte Bibliotheken zulässig, oder es wurden andere wesentliche Einschränkungen für den Code für gemeinsam genutzte Bibliotheken auferlegt.

Gemeinsamer Speicher [ edit ]

Bibliothekscode kann von mehreren Prozessen sowie auf der Festplatte im Speicher gemeinsam genutzt werden. Wenn virtueller Speicher verwendet wird, führen Prozesse dieselbe physische RAM-Seite aus, die den verschiedenen Adressräumen der Prozesse zugeordnet ist. Das hat Vorteile. Auf dem OpenStep-System beispielsweise waren Anwendungen oft nur wenige hundert Kilobyte groß und wurden schnell geladen. Der Großteil ihres Codes befand sich in Bibliotheken, die bereits zu anderen Zwecken vom Betriebssystem geladen wurden. ^{[ Zitat benötigt ]}

Programme können RAM-Sharing durch Verwendung von position- Unabhängiger Code wie bei Unix, der zu einer komplexen, aber flexiblen Architektur führt, oder durch Verwendung gemeinsamer virtueller Adressen wie bei Windows und OS / 2. Diese Systeme stellen sicher, dass der Code durch verschiedene Tricks wie das Vorabbilden des Adressraums und das Reservieren von Slots für jede gemeinsam genutzte Bibliothek mit großer Wahrscheinlichkeit gemeinsam genutzt wird. Eine dritte Alternative ist der einstufige Speicher, wie er von IBM System / 38 und seinen Nachfolgern verwendet wird. Dies ermöglicht positionsabhängigen Code, unterliegt jedoch keinen wesentlichen Einschränkungen hinsichtlich der Platzierung und der gemeinsamen Nutzung von Code.

In einigen Fällen können unterschiedliche Versionen gemeinsam genutzter Bibliotheken Probleme verursachen, insbesondere wenn Bibliotheken unterschiedlicher Versionen den gleichen Dateinamen haben und für verschiedene auf einem System installierte Anwendungen jeweils eine bestimmte Version erforderlich ist. Ein solches Szenario ist als DLL Hell bekannt, benannt nach der Windows- und OS / 2-DLL-Datei. Die meisten modernen Betriebssysteme nach 2001 verfügen über Aufräummethoden, um solche Situationen zu beseitigen oder anwendungsspezifische "private" Bibliotheken zu verwenden. ^[9]

Dynamic Linking [ edit ]

Dynamic Linking oder Late Binding Diese Verknüpfung wird ausgeführt, während ein Programm geladen (Ladezeit) oder ausgeführt wird (Laufzeit), und nicht, wenn die ausführbare Datei erstellt wird. Eine dynamisch verknüpfte Bibliothek (Dynamic Link Library oder DLL unter Windows und OS / 2; Dynamic Shared Object oder DSO unter Unix-ähnlichen Systemen) ist eine Bibliothek, die für dynamisches Linking vorgesehen ist. Der Linker erledigt beim Erstellen der ausführbaren Datei nur wenig Arbeit. Es zeichnet nur auf, welche Bibliotheksroutinen das Programm benötigt, und die Indexnamen oder -nummern der Routinen in der Bibliothek. Der größte Teil der Verknüpfungsarbeit wird zu dem Zeitpunkt ausgeführt, zu dem die Anwendung geladen wird (Ladezeit), oder während der Ausführung (Laufzeit). Normalerweise ist das notwendige Verknüpfungsprogramm, "dynamischer Linker" oder "Verknüpfungslader" genannt, tatsächlich Teil des zugrunde liegenden Betriebssystems. (Es ist jedoch möglich und nicht äußerst schwierig, ein Programm zu schreiben, das dynamische Verknüpfung verwendet und seinen eigenen dynamischen Linker enthält, selbst für ein Betriebssystem, das selbst keine Unterstützung für die dynamische Verknüpfung bietet.)

Programmierer entwickelten ursprünglich dynamische Verknüpfungen im Betriebssystem Multics ab 1964 und dem MTS (Michigan Terminal System), das in den späten 1960er Jahren gebaut wurde. ^[10]

Optimizations [ edit edit ] 19659055] Da sich gemeinsame Bibliotheken auf den meisten Systemen nicht häufig ändern, können Systeme eine voraussichtliche Ladeadresse für jede gemeinsam genutzte Bibliothek im System berechnen, bevor sie benötigt wird, und diese Informationen in den Bibliotheken und ausführbaren Dateien speichern. Wenn jede geladene gemeinsam genutzte Bibliothek diesen Prozess durchlaufen hat, wird jede unter ihrer vorgegebenen Adresse geladen, was den Prozess der dynamischen Verknüpfung beschleunigt. Diese Optimierung wird als Vorbindung in macOS und als Vorverknüpfung in Linux bezeichnet. Nachteile dieser Technik sind die Zeit, die erforderlich ist, um diese Adressen bei jeder Änderung der gemeinsam genutzten Bibliotheken im Voraus zu berechnen, die Unmöglichkeit, die Randomisierung des Adressraum-Layouts zu verwenden, und die Notwendigkeit eines ausreichenden virtuellen Adressraums für die Verwendung (ein Problem, das durch die Übernahme von 64 verringert wird) -Bit-Architekturen (zumindest vorläufig).

Lokalisieren von Bibliotheken zur Laufzeit [ edit ]

Lader für gemeinsam genutzte Bibliotheken unterscheiden sich stark in der Funktionalität. Einige hängen davon ab, dass die ausführbare Datei explizite Pfade zu den Bibliotheken speichert. Jede Änderung der Bibliotheksbenennung oder des Layouts des Dateisystems führt zum Ausfall dieser Systeme. Normalerweise wird nur der Name der Bibliothek (und nicht der Pfad) in der ausführbaren Datei gespeichert, wobei das Betriebssystem basierend auf einem Algorithmus eine Methode zum Auffinden der Bibliothek auf der Festplatte bereitstellt.

Wenn eine gemeinsam genutzte Bibliothek, von der eine ausführbare Datei abhängig ist, gelöscht, verschoben oder umbenannt wird oder wenn eine inkompatible Version der Bibliothek an einen früheren Ort der Suche kopiert wird, könnte die ausführbare Datei nicht geladen werden. Dies wird als Abhängigkeitshöhle bezeichnet, die auf vielen Plattformen vorhanden ist. Die (infame) Windows-Variante wird allgemein als DLL Hell bezeichnet. Dieses Problem kann nicht auftreten, wenn jede Version jeder Bibliothek eindeutig identifiziert wird und jedes Programm Bibliotheken nur anhand ihrer vollständigen eindeutigen Bezeichner referenziert. Die "DLL-Hölle" -Probleme bei früheren Windows-Versionen waren darauf zurückzuführen, dass nur die Namen von Bibliotheken verwendet wurden, die nicht eindeutig eindeutig waren, um dynamische Links in Programmen aufzulösen. (Um "DLL-Hölle" zu vermeiden, sind spätere Versionen von Windows weitgehend auf Optionen für Programme angewiesen, um private DLLs zu installieren - im Wesentlichen ein teilweiser Rückzug aus der Verwendung gemeinsam genutzter Bibliotheken) sowie Mechanismen, um zu verhindern, dass gemeinsam genutzte System-DLLs durch frühere Versionen ersetzt werden. )

Microsoft Windows [ edit ]

Microsoft Windows überprüft die Registrierung, um den richtigen Ort zum Laden von DLLs zu ermitteln, die COM-Objekte implementieren. Bei anderen DLLs werden jedoch die Verzeichnisse in einem definierten Verzeichnis geprüft Auftrag. Zuerst überprüft Windows das Verzeichnis, in dem das Programm geladen wurde ( private DLL ^[9]); beliebige Verzeichnisse, die durch Aufrufen der Funktion SetDllDirectory () festgelegt werden; die Verzeichnisse System32, System und Windows; dann das aktuelle Arbeitsverzeichnis; und schließlich die durch die Umgebungsvariable PATH angegebenen Verzeichnisse. ^[11] Für .NET Framework Framework (seit 2002) geschriebene Anwendungen prüfen auch den globalen Assemblycache als primären Speicher für gemeinsam genutzte DLL-Dateien, um das Problem der DLL-Hölle zu beseitigen.

OpenStep [ edit ]

OpenStep verwendete ein flexibleres System und sammelte eine Liste von Bibliotheken aus einer Reihe bekannter Standorte (ähnlich dem PATH-Konzept), wenn das System zum ersten Mal gestartet wurde. Das Verschieben von Bibliotheken verursacht keinerlei Probleme, obwohl Benutzer beim erstmaligen Starten des Systems mit Zeitaufwand verbunden sind.

Unix-ähnliche Systeme [ edit ]

Die meisten Unix-ähnlichen Systeme verfügen über einen "Suchpfad", der Dateisystemverzeichnisse angibt, in denen nach dynamischen Bibliotheken gesucht werden soll. Einige Systeme geben den Standardpfad in einer Konfigurationsdatei an, andere kodieren ihn fest in den Dynamic Loader. Einige ausführbare Dateiformate können zusätzliche Verzeichnisse angeben, in denen nach Bibliotheken für ein bestimmtes Programm gesucht werden soll. Dies kann normalerweise mit einer Umgebungsvariablen überschrieben werden, obwohl es für die Programme setuid und setgid deaktiviert ist, sodass ein Benutzer nicht erzwingen kann, dass ein solches Programm beliebigen Code mit Root-Berechtigungen ausführt. Entwickler von Bibliotheken sollten ihre dynamischen Bibliotheken an Orten im Standardsuchpfad platzieren. Nachteilig kann dies die Installation neuer Bibliotheken problematisch machen, und diese "bekannten" Speicherorte werden schnell zu einer wachsenden Anzahl von Bibliotheksdateien, wodurch die Verwaltung komplexer wird.

Dynamisches Laden [ edit ]

Beim dynamischen Laden, einer Teilmenge dynamischer Verknüpfungen, wird das Laden und Entladen von dynamisch verknüpften Bibliotheken zur Laufzeit auf Anforderung verlangt. Eine solche Anforderung kann implizit zur Kompilierzeit oder explizit zur Laufzeit erfolgen. Implizite Anforderungen werden zur Kompilierzeit gestellt, wenn ein Linker Bibliotheksreferenzen hinzufügt, die Dateipfade oder einfach Dateinamen enthalten. Explizite Anforderungen werden gestellt, wenn Anwendungen zur Laufzeit direkt die API eines Betriebssystems aufrufen.

Die meisten Betriebssysteme, die dynamisch verknüpfte Bibliotheken unterstützen, unterstützen auch das dynamische Laden solcher Bibliotheken über eine Laufzeit-Linker-API. Beispielsweise verwendet Microsoft Windows die API-Funktionen LoadLibrary LoadLibraryEx FreeLibrary und GetProcAddress mit Microsoft Dynamic Link Libraries. POSIX-basierte Systeme, einschließlich der meisten UNIX- und UNIX-ähnlichen Systeme, verwenden dlopen dlclose und dlsym . Einige Entwicklungssysteme automatisieren diesen Prozess.

Objekt- und Klassenbibliotheken [ edit ]

Obwohl es in den 1960er Jahren erstmals Pionierarbeit geleistet hatte, erreichte das dynamische Linking erst in den späten 1980er Jahren Betriebssysteme, die von Verbrauchern verwendet wurden. In den meisten Betriebssystemen war es in den frühen 90er Jahren allgemein in irgendeiner Form verfügbar. In dieser Zeit wurde die objektorientierte Programmierung (OOP) zu einem bedeutenden Teil der Programmierungslandschaft. OOP mit Laufzeitbindung erfordert zusätzliche Informationen, die herkömmliche Bibliotheken nicht bereitstellen. Zusätzlich zu den Namen und Eintrittspunkten des Codes, die sich darin befinden, benötigen sie auch eine Liste der Objekte, von denen sie abhängig sind. Dies ist ein Nebeneffekt eines der Hauptvorteile von OOP, der Vererbung. Dies bedeutet, dass Teile der vollständigen Definition einer Methode an verschiedenen Stellen liegen können. Dies ist mehr als nur die Auflistung, dass eine Bibliothek die Dienste einer anderen benötigt: In einem echten OOP-System sind die Bibliotheken selbst möglicherweise zur Kompilierzeit nicht bekannt und variieren von System zu System.

Zur gleichen Zeit arbeiteten viele Entwickler an der Idee von Multi-Tier-Programmen, bei denen ein "Display", das auf einem Desktop-Computer ausgeführt wurde, die Dienste eines Mainframes oder eines Minicomputers zur Datenspeicherung oder -verarbeitung verwenden würde. Beispielsweise würde ein Programm auf einem GUI-basierten Computer Nachrichten an einen Minicomputer senden, um kleine Beispiele eines großen Datensatzes zur Anzeige zurückzugeben. Remote Procedure Calls (RPC) erledigten diese Aufgaben bereits, es gab jedoch kein Standard-RPC-System.

Bald initiierte die Mehrheit der Minicomputer- und Mainframe-Hersteller Projekte, um die beiden zu kombinieren, und produzierte ein OOP-Bibliotheksformat, das überall verwendet werden konnte. Solche Systeme waren als Objektbibliotheken oder verteilte Objekte bekannt, wenn sie den Fernzugriff unterstützten (nicht alle). Microsofts COM ist ein Beispiel für ein solches System zur lokalen Verwendung, DCOM eine modifizierte Version, die Fernzugriff unterstützt.

Objektbibliotheken hatten eine Zeitlang den Status der "nächsten großen Sache" in der Programmierwelt. Es gab eine Reihe von Bemühungen, Systeme zu schaffen, die plattformübergreifend laufen würden, und Unternehmen konkurrierten darum, Entwickler in ihr eigenes System zu locken. Beispiele sind das IBM System Object Model (SOM / DSOM), Sun Microsystems Distributed Objects Everywhere (DOE), die tragbaren verteilten Objekte (PDO) von NeXT, Digital ObjectBroker, das Component Object Model (COM / DCOM) von Microsoft und eine beliebige Anzahl von CORBA-basierten Systeme.

Nach der unvermeidlichen Abkühlung des Marketing-Hype werden Objektbibliotheken weiterhin sowohl in der objektorientierten Programmierung als auch in verteilten Informationssystemen verwendet. Klassenbibliotheken sind das grobe OOP-Äquivalent älterer Typen von Codebibliotheken. Sie enthalten Klassen, die Merkmale beschreiben und Aktionen (Methoden) definieren, die Objekte betreffen. Klassenbibliotheken werden zum Erstellen von Instanzen oder Objekten verwendet, deren Eigenschaften auf bestimmte Werte festgelegt sind. In einigen OOP-Sprachen wie Java ist der Unterschied klar: Die Klassen sind häufig in Bibliotheksdateien enthalten (wie das JAR-Dateiformat von Java) und die instanziierten Objekte befinden sich nur im Arbeitsspeicher (obwohl sie möglicherweise in separaten Dateien persistent gemacht werden können). In anderen, wie Smalltalk, sind die Klassenbibliotheken lediglich der Ausgangspunkt für ein Systemabbild, das den gesamten Status der Umgebung, Klassen und alle instanziierten Objekte enthält.

Fernbibliotheken [ edit ]

Eine andere Lösung für das Bibliotheksproblem besteht darin, vollständig separate ausführbare Dateien (oft in einer leichteren Form) und den Aufruf mit einem Remoteprozeduraufruf (RPC) zu verwenden. über ein Netzwerk zu einem anderen Computer. Dieser Ansatz maximiert die Wiederverwendung des Betriebssystems: Der zur Unterstützung der Bibliothek erforderliche Code ist derselbe Code, der für die Anwendungsunterstützung und Sicherheit für jedes andere Programm verwendet wird. Darüber hinaus erfordern solche Systeme nicht, dass die Bibliothek auf demselben Computer vorhanden ist, sondern sie können die Anforderungen über das Netzwerk weiterleiten.

Ein solcher Ansatz bedeutet jedoch, dass jeder Bibliotheksaufruf einen erheblichen Overhead erfordert. RPC-Aufrufe sind wesentlich teurer als das Aufrufen einer gemeinsam genutzten Bibliothek, die bereits auf demselben Computer geladen wurde. Dieser Ansatz wird im Allgemeinen in einer verteilten Architektur verwendet, die solche Remote-Aufrufe, insbesondere Client-Server-Systeme und Anwendungsserver wie Enterprise JavaBeans, intensiv nutzt.

Bibliotheken für die Codegenerierung [ edit ]

Bibliotheken für die Codegenerierung sind High-Level-APIs, die Bytecode für Java generieren oder transformieren können. Sie werden von der Aspekt-orientierten Programmierung, einigen Datenzugriffs-Frameworks und zum Testen zur Erzeugung dynamischer Proxy-Objekte verwendet. Sie werden auch verwendet, um den Feldzugriff abzufangen. ^[12]

Dateiname [ edit

Die meisten modernen Unix-ähnlichen Systeme [ edit

Das System speichert libfoo.a und libfoo.so Dateien in Verzeichnissen wie / lib / usr / lib oder . / usr / local / lib . Die Dateinamen beginnen immer mit lib und enden mit einem Suffix von .a (Archiv, statische Bibliothek) oder von .so (gemeinsames Objekt, dynamisch verknüpfte Bibliothek) ). Einige Systeme haben möglicherweise mehrere Namen für die dynamisch verknüpfte Bibliothek, wobei die meisten Namen Namen für symbolische Links zu dem verbleibenden Namen sind. Diese Namen können die Hauptversion der Bibliothek oder die vollständige Versionsnummer enthalten. Auf einigen Systemen wäre beispielsweise libfoo.so.2 der Dateiname für die zweite Hauptschnittstellenrevision der dynamisch verknüpften Bibliothek libfoo . Die Dateien .la die manchmal in den Bibliotheksverzeichnissen gefunden werden, sind libtool-Archive, die vom System als solches nicht verwendet werden können.

macOS [ edit ]

Das System erbt statische Bibliothekskonventionen von BSD, wobei die Bibliothek in einer Datei .a gespeichert ist und verwendet werden kann. .so -Stil dynamisch verknüpfte Bibliotheken (stattdessen mit dem Suffix .dylib ). Die meisten Bibliotheken in macOS bestehen jedoch aus "Frameworks", die sich in speziellen Verzeichnissen befinden, die als "Bundles" bezeichnet werden und die erforderlichen Dateien und Metadaten der Bibliothek umschließen. Ein Framework namens MyFramework würde beispielsweise in einem Bundle MyFramework.framework implementiert, wobei MyFramework.framework / MyFramework entweder die dynamisch verknüpfte Bibliotheksdatei oder ist ein Link zu der dynamisch verknüpften Bibliotheksdatei in MyFramework.framework / Versions / Current / MyFramework .

Microsoft Windows [ edit ]

Dynamische Link-Bibliotheken haben normalerweise das Suffix *. DLL ^[13] obwohl andere Dateinamenerweiterungen möglicherweise spezifisch sind. dynamisch verknüpfte Bibliotheken, z *. OCX für OLE-Bibliotheken. Die Schnittstellenrevisionen werden entweder in den Dateinamen codiert oder mithilfe von COM-Objektschnittstellen abstrahiert. Abhängig von ihrer Kompilierung können *. LIB -Dateien entweder statische Bibliotheken oder Repräsentationen von dynamisch verknüpfbaren Bibliotheken sein, die nur beim Kompilieren benötigt werden und als "Importbibliotheken" bezeichnet werden. Anders als in der UNIX-Welt, die unterschiedliche Dateierweiterungen verwendet, muss beim Verknüpfen mit der Datei .LIB in Windows zuerst bekannt sein, ob es sich um eine reguläre statische Bibliothek oder eine Importbibliothek handelt. Im letzteren Fall muss zur Laufzeit eine Datei .DLL vorhanden sein.

Siehe auch [ edit ]

1. ^ Es war früher zwischen z. B. Ada-Unterprogrammen möglich.
2. ^ Einige ältere Systeme, z. B. Burroughs MCP , Multics, haben auch nur ein einziges Format für ausführbare Dateien, unabhängig davon, ob sie gemeinsam genutzt werden. edit ]

1. ^ "Static Libraries" . TLDP. Nach dem Original am 3. Juli 2013 archiviert . 3. Oktober 2013 .
2. ^ Wexelblat, Richard (1981). Geschichte der Programmiersprachen . ACM-Monographenserie. New York, NY: Academic Press (eine Tochtergesellschaft von Harcourt Brace). p. 369. ISBN 0-12-745040-8.
3. ^ Wexelblat, op. cit. p. 274
4. ^ Wexelblat, op. cit. p. 258
5. ^ Wilson, Leslie B .; Clark, Robert G. (1988). Vergleichende Programmiersprachen . Wokingham, England: Addison-Wesley. p. 126. ISBN 0-201-18483-4.
6. ^ Wilson und Clark, op. cit. p. 52
7. ^ Wexelblat, op. cit. p. 716
8. ^ Christian Collberg, John H. Hartman, Sridivya Babu, Sharath K. Udupa (2003). Msgstr "SLINKY: Statische Verknüpfung wurde geladen". Abteilung für Informatik, Universität von Arizona. Nach dem Original am 23. März 2016 archiviert . Abgerufen 17. März 2016 . CS1-Wartung: Verwendet Autorenparameter (Link)
9. ^ ^{a b} Anderson, Rick (2000-01-11). "Das Ende von DLL Hell". microsoft.com. Archiviert aus dem Original am 2001-06-05 . Abgerufen 2012-01-15 . Private DLLs sind DLLs, die mit einer bestimmten Anwendung installiert und nur von dieser Anwendung verwendet werden.
10. ^ "A History of MTS". Information Technology Digest . 5 (5).
11. ^ "Dynamic-Link Library Search Order". Microsoft Developer Network Library . Microsoft. 6. März 2012. Nach dem Original vom 9. Mai 2012 . 20. Mai 2012 .
12. ^ "Code Generation Library". http://sourceforge.net/: Source Forge. Nach dem Original am 12. Januar 2010 archiviert . 3. März 2010 abgerufen. Die Bytecode-Generierungsbibliothek ist eine API auf hoher Ebene zum Generieren und Umwandeln von JAVA-Bytecode. Es wird von AOP-, Test- und Datenzugriffs-Frameworks verwendet, um dynamische Proxy-Objekte zu generieren und den Feldzugriff abzufangen.
13. ^ Bresnahan, Christine; Blum, Richard (27. April 2015). LPIC-1 Linux Professional Institute - Zertifizierungshandbuch: Prüfung 101-400 und Prüfung 102-400 . John Wiley & Sons (veröffentlicht 2015). p. 82. ISBN 9781119021186. Nach dem Original vom 24. September 2015 . 3. September 2015 abgerufen. Gemeinsam genutzte Linux-Bibliotheken ähneln den Dynamic Link Libraries (DLLs) von Windows. Windows-DLLs werden normalerweise durch .dll Dateinamenerweiterungen identifiziert.

Externe Links [ edit ]