Bibliothek (Computer) - Library (computing)

Illustration einer Anwendung, die libvorbisfile verwendet, um eine Ogg Vorbis- Datei abzuspielen

In der Informatik ist eine Bibliothek eine Sammlung nichtflüchtiger Ressourcen, die von Computerprogrammen verwendet werden , oft für die Softwareentwicklung . Dies können Konfigurationsdaten, Dokumentation, Hilfedaten, Nachrichtenvorlagen, vorgefertigter Code und Unterprogramme , Klassen , Werte oder Typspezifikationen sein. In IBMs OS/360 und seinen Nachfolgern werden sie als partitionierte Datensätze bezeichnet .

Eine Bibliothek ist auch eine Sammlung von Verhaltensimplementierungen, geschrieben in Form einer Sprache, die eine wohldefinierte Schnittstelle hat, durch die das Verhalten aufgerufen wird. Zum Beispiel können Leute, 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 von der Bibliothek bereitgestellte Verhalten über einen Mechanismus der Sprache auf. In einer einfachen imperativen Sprache wie C wird das Verhalten in einer Bibliothek beispielsweise mithilfe des normalen Funktionsaufrufs von C aufgerufen. Was den Aufruf einer Bibliotheksfunktion von einer anderen Funktion im selben Programm unterscheidet, ist die Art und Weise, wie der Code im System organisiert ist.

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 wird. Diese Unterscheidung kann einen hierarchischen Begriff erhalten, wenn ein Programm groß wird, wie z. B. ein Programm mit mehreren Millionen Zeilen. In diesem Fall kann es interne Bibliotheken geben, die von unabhängigen Unterteilen des großen Programms wiederverwendet werden. Das Unterscheidungsmerkmal besteht darin, dass eine Bibliothek so organisiert ist, dass sie von unabhängigen Programmen oder Unterprogrammen wiederverwendet werden kann und der Benutzer nur die Schnittstelle und nicht die internen Details der Bibliothek kennen muss.

Der Wert einer Bibliothek liegt in der Wiederverwendung standardisierter Programmelemente. 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 der Erstellung des aufrufenden Programms auf den Code der Bibliothek zugegriffen wird, wird die Bibliothek als statische Bibliothek bezeichnet . 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 Startvorgangs der Ausführung oder mitten in der Ausführung. In diesem Fall wird die Bibliothek als dynamische Bibliothek bezeichnet (zur Laufzeit geladen ). Eine dynamische Bibliothek kann beim Vorbereiten eines Programms zur Ausführung durch den Linker geladen und gelinkt werden . Alternativ kann eine Anwendung mitten in der Ausführung explizit anfordern, dass ein Modul geladen wird .

Die meisten kompilierten Sprachen verfügen über eine Standardbibliothek , obwohl Programmierer auch ihre eigenen benutzerdefinierten Bibliotheken erstellen können. Die meisten modernen Softwaresysteme stellen Bibliotheken bereit, die den Großteil der Systemdienste implementieren. Solche Bibliotheken haben die Dienste organisiert, die eine moderne Anwendung erfordert. Daher wird der meiste Code, der von modernen Anwendungen verwendet wird, in diesen Systembibliotheken bereitgestellt.

Geschichte

Eine Frau, die neben einem Aktenschrank mit der Subroutinenbibliothek auf Lochstreifen für den EDSAC-Computer arbeitet.

Im Jahr 1947 spekulierten Goldstine und von Neumann , dass es nützlich wäre, eine "Bibliothek" von Subroutinen für ihre Arbeit an der IAS-Maschine zu erstellen , einem frühen Computer, der zu dieser Zeit noch nicht betriebsbereit war. Sie stellten sich eine physische Bibliothek von Magnetdrahtaufzeichnungen vor , wobei jeder Draht wiederverwendbaren Computercode speichert.

Inspiriert von von Neumann konstruierten Wilkes und sein Team EDSAC . Ein Aktenschrank mit Lochstreifen enthielt die Subroutinenbibliothek für diesen Computer. Programme für EDSAC bestanden aus einem Hauptprogramm und einer Folge von Unterprogrammen, die aus der Unterprogrammbibliothek kopiert wurden. 1951 veröffentlichte das Team das erste Lehrbuch zur Programmierung, The Preparation of Programs for an Electronic Digital Computer , das die Entstehung und den Zweck der Bibliothek detailliert beschreibt.

COBOL enthielt 1959 "primitive Fähigkeiten für ein Bibliothekssystem", aber Jean Sammet beschrieb sie rückblickend als "unzureichende Bibliothekseinrichtungen".

JOVIAL hatte einen Communication Pool (COMPOOL), grob eine Bibliothek von Header-Dateien.

Einen weiteren wesentlichen Beitrag zum modernen Bibliothekskonzept leistete die Unterprogramminnovation 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 eine Typüberprüfung zwischen FORTRAN-Unterprogrammen unmöglich.

Mitte der 1960er Jahre waren Kopier- und Makrobibliotheken für Assembler weit verbreitet. Beginnend mit der Popularität des IBM System/360 wurden auch Bibliotheken üblich, die andere Arten von Textelementen, zB Systemparameter, enthielten.

Simula war die erste objektorientierte Programmiersprache , und ihre Klassen waren fast 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 . Selbst bei der ursprünglichen Entwicklung im Jahr 1965 konnten Simula-Klassen in Bibliotheksdateien aufgenommen und zur Kompilierzeit hinzugefügt werden.

Verknüpfung

Bibliotheken sind wichtig beim Verknüpfen oder Binden von Programmen , die als Verknüpfungen oder Symbole bekannte Verweise auf Bibliotheksmodule auflösen. Der Linking-Prozess wird normalerweise automatisch von einem Linker- oder Binder- Programm durchgeführt, das eine Reihe von Bibliotheken und anderen Modulen in einer bestimmten Reihenfolge durchsucht. Normalerweise wird es nicht als Fehler angesehen, wenn ein Linkziel in einem bestimmten Satz von Bibliotheken mehrmals gefunden wird. Das Verknüpfen kann erfolgen, wenn eine ausführbare Datei erstellt wird oder wenn das Programm zur Laufzeit verwendet wird .

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

Einige Programmiersprachen verwenden eine Funktion namens Smart Linking, bei der der Linker den Compiler kennt oder in ihn integriert, sodass der Linker weiß, wie externe Referenzen verwendet werden, und Code in einer Bibliothek, der nie tatsächlich verwendet wird , obwohl intern referenziert wird, aus der kompilierten Anwendung verworfen. Beispielsweise kann ein Programm, das nur ganze Zahlen für die Arithmetik verwendet oder überhaupt keine arithmetischen Operationen durchführt, Gleitkommabibliotheksroutinen ausschließen. Diese Smart-Linking-Funktion kann zu kleineren Anwendungsdateigrößen und reduzierter Speichernutzung führen.

Verlegung

Einige Verweise in einem Programm oder Bibliotheksmodul werden in einer relativen oder symbolischen Form gespeichert, die nicht aufgelöst werden kann, bis allen Codes und Bibliotheken endgültige statische Adressen zugewiesen wurden. Die Verlagerung ist der Prozess der Anpassung dieser Referenzen und wird entweder vom Linker oder vom Loader durchgeführt . Im Allgemeinen kann die Verlagerung nicht in einzelne Bibliotheken selbst durchgeführt werden, da die Adressen im Speicher je nach dem sie verwendenden Programm und anderen Bibliotheken, mit denen sie kombiniert werden, variieren können. Positionsunabhängiger Code vermeidet Referenzen auf absolute Adressen und erfordert daher keine Verlagerung.

Statische Bibliotheken

Wenn das Verknüpfen während der Erstellung einer ausführbaren Datei oder einer anderen Objektdatei durchgeführt wird, wird dies als statisches Verknüpfen oder frühes Binden bezeichnet . In diesem Fall erfolgt die Verlinkung normalerweise durch einen Linker , kann aber auch durch den Compiler erfolgen . Eine statische Bibliothek , auch als Archiv bekannt , soll statisch verlinkt werden. Ursprünglich gab es nur statische Bibliotheken. Beim Neukompilieren von Modulen muss eine statische Verknüpfung durchgeführt werden.

Alle von einem Programm benötigten Module werden manchmal statisch gelinkt und in die ausführbare Datei kopiert. Dieser Vorgang und die resultierende eigenständige Datei werden als statischer Build des Programms bezeichnet. Ein statischer Build erfordert möglicherweise keine weitere Verlagerung, wenn virtueller Speicher verwendet wird und keine Randomisierung des Adressraum-Layouts erwünscht ist.

Gemeinsam genutzte Bibliotheken

Eine gemeinsam genutzte Bibliothek oder ein 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 er eine einzelne monolithische ausführbare Datei für das Programm erstellt.

Gemeinsam genutzte Bibliotheken können während der Kompilierzeit statisch gelinkt werden, was bedeutet, dass Verweise auf die Bibliotheksmodule aufgelöst werden und den Modulen Speicher zugewiesen wird, wenn die ausführbare Datei erstellt wird. Aber oft wird das Verlinken von Shared Libraries verschoben, bis sie geladen sind.

Die meisten modernen Betriebssysteme können gemeinsam genutzte Bibliotheksdateien des gleichen Formats wie die ausführbaren Dateien haben. Dies bietet zwei Hauptvorteile: Erstens ist es erforderlich, nur einen Lader für beide statt zwei herzustellen (der einzelne Lader ist die zusätzliche Komplexität wert). Zweitens können die ausführbaren Dateien auch als Shared Libraries verwendet werden, wenn sie über eine Symboltabelle verfügen . Typische kombinierte ausführbare und gemeinsam genutzte Bibliotheksformate sind ELF und Mach-O (beide in Unix) und PE (Windows).

In einigen älteren Umgebungen wie 16-Bit-Windows oder MPE für den HP 3000 waren nur stapelbasierte Daten (lokal) im Code der gemeinsam genutzten Bibliothek zulässig, oder es wurden andere erhebliche Einschränkungen für den Code der gemeinsam genutzten Bibliothek auferlegt.

Speicherfreigabe

Bibliothekscode kann im Speicher von mehreren Prozessen sowie auf der Festplatte gemeinsam genutzt werden. Wenn virtueller Speicher verwendet wird, würden Prozesse dieselbe physikalische RAM-Seite ausführen, die in die unterschiedlichen Adressräume der Prozesse abgebildet wird. Dies hat Vorteile. Auf dem OpenStep- System waren Anwendungen beispielsweise oft nur wenige hundert Kilobyte groß und wurden schnell geladen; der Großteil ihres Codes befand sich in Bibliotheken, die das Betriebssystem bereits für andere Zwecke geladen hatte.

Programme können RAM-Sharing erreichen, indem sie positionsunabhängigen Code verwenden , wie in Unix , was zu einer komplexen, aber flexiblen Architektur führt, oder indem sie gemeinsame virtuelle Adressen verwenden, wie in Windows und OS/2 . Diese Systeme stellen durch verschiedene Tricks wie das Vorabzuordnen des Adressraums und das Reservieren von Slots für jede gemeinsam genutzte Bibliothek sicher, dass der Code mit großer Wahrscheinlichkeit geteilt wird. Eine dritte Alternative ist der einstufige Speicher , wie er vom IBM System/38 und seinen Nachfolgern verwendet wird. Dies ermöglicht positionsabhängigen Code, schränkt jedoch nicht wesentlich ein, wo Code platziert oder geteilt werden kann.

In einigen Fällen können verschiedene Versionen von gemeinsam genutzten Bibliotheken Probleme verursachen, insbesondere wenn Bibliotheken verschiedener Versionen denselben Dateinamen haben und verschiedene auf einem System installierte Anwendungen jeweils eine bestimmte Version erfordern. Ein solches Szenario wird als DLL-Hölle bezeichnet , benannt nach der Windows- und OS/2- DLL-Datei . Die meisten modernen Betriebssysteme nach 2001 verfügen über Bereinigungsmethoden, um solche Situationen zu beseitigen, oder verwenden anwendungsspezifische "private" Bibliotheken.

Dynamische Verknüpfung

Dynamisches Binden oder spätes Binden wird durchgeführt, während ein Programm geladen ( Ladezeit ) oder ausgeführt wird ( Laufzeit ) und nicht, wenn die ausführbare Datei erstellt wird. Eine dynamisch gelinkte Bibliothek ( Dynamic Link Library oder DLL unter Windows und OS/2 ; Shareable Image unter OpenVMS ; Dynamic Shared Object oder DSO unter Unix-ähnlichen Systemen) ist eine Bibliothek, die für dynamisches Linken gedacht ist. Beim Erstellen der ausführbaren Datei wird vom Linker nur ein minimaler Arbeitsaufwand ausgeführt ; es zeichnet nur auf, welche Bibliotheksroutinen das Programm benötigt und die Indexnamen oder -nummern der Routinen in der Bibliothek. Der Großteil der Verknüpfungsarbeit wird zum Zeitpunkt des Ladens der Anwendung (Ladezeit) oder während der Ausführung (Laufzeit) erledigt. Normalerweise ist das notwendige Linking-Programm, das als "Dynamic Linker" oder "Linking Loader" bezeichnet wird, tatsächlich Teil des zugrunde liegenden Betriebssystems . (Es ist jedoch möglich und nicht sonderlich schwierig, ein Programm zu schreiben, das dynamisches Linken verwendet und seinen eigenen dynamischen Linker enthält, selbst für ein Betriebssystem, das selbst keine Unterstützung für dynamisches Linken bietet.)

Programmierer entwickelten die dynamische Verknüpfung ursprünglich im Multics- Betriebssystem ab 1964 und im MTS ( Michigan Terminal System ), das Ende der 1960er Jahre gebaut wurde.

Optimierungen

Da sich gemeinsam genutzte Bibliotheken auf den meisten Systemen nicht oft ändern, können Systeme eine wahrscheinliche Ladeadresse für jede gemeinsam genutzte Bibliothek auf dem 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 an ihrer vorbestimmten Adresse geladen, was den Prozess des dynamischen Bindens beschleunigt. Diese Optimierung ist bekannt als Prebinding in macOS und prelinking in Linux. Nachteile dieser Technik sind die Zeit, die erforderlich ist, um diese Adressen bei jeder Änderung der gemeinsam genutzten Bibliotheken vorzuberechnen, die Unfähigkeit, die Randomisierung des Adressraum-Layouts zu verwenden , und das Erfordernis eines ausreichenden virtuellen Adressraums für die Verwendung (ein Problem, das durch die Einführung von 64 . gemildert wird). -Bit- Architekturen, zumindest vorerst).

Suchen von Bibliotheken zur Laufzeit

Loader für Shared Libraries unterscheiden sich in ihrer Funktionalität stark. 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. Häufiger wird nur der Name der Bibliothek (und nicht der Pfad) in der ausführbaren Datei gespeichert, wobei das Betriebssystem eine Methode zum Auffinden der Bibliothek auf der Festplatte basierend auf einem Algorithmus bereitstellt.

Wenn eine gemeinsam genutzte Bibliothek, von der eine ausführbare Datei abhängt, gelöscht, verschoben oder umbenannt wird oder wenn eine inkompatible Version der Bibliothek an eine Stelle kopiert wird, die sich früher in der Suche befindet, kann die ausführbare Datei nicht geladen werden. Dies wird als Dependency Hell bezeichnet und existiert auf vielen Plattformen. Die (berüchtigte) Windows-Variante wird allgemein als DLL-Hölle bezeichnet . Dieses Problem kann nicht auftreten, wenn jede Version jeder Bibliothek eindeutig identifiziert wird und jedes Programm auf Bibliotheken nur durch ihre vollständigen eindeutigen Bezeichner verweist. Die "DLL-Hölle"-Probleme mit früheren Windows-Versionen ergaben sich daraus, dass nur die Namen von Bibliotheken verwendet wurden, deren Eindeutigkeit nicht garantiert war, um dynamische Links in Programmen aufzulösen. (Um die „DLL-Hölle“ zu vermeiden, verlassen sich spätere Windows-Versionen weitgehend auf Optionen für Programme zur Installation privater DLLs – im Wesentlichen ein teilweiser Rückzug von der Verwendung gemeinsamer Bibliotheken – zusammen mit Mechanismen, die den Austausch gemeinsamer System-DLLs durch frühere Versionen verhindern. )

Microsoft Windows

Microsoft Windows überprüft die Registrierung , um den richtigen Ort zum Laden von DLLs zu bestimmen, die COM-Objekte implementieren , aber für andere DLLs überprüft es die Verzeichnisse in einer definierten Reihenfolge. Zuerst überprüft Windows das Verzeichnis, in das es das Programm geladen hat ( private DLL ); alle Verzeichnisse, die durch Aufrufen der SetDllDirectory()Funktion festgelegt wurden; die Verzeichnisse System32, System und Windows; dann das aktuelle Arbeitsverzeichnis; und schließlich die durch die Umgebungsvariable PATH angegebenen Verzeichnisse . Anwendungen, die für das .NET Framework (seit 2002) geschrieben wurden, überprüfen auch den Global Assembly Cache als primären Speicher für freigegebene DLL-Dateien, um das Problem von DLL hell zu beseitigen .

OpenStep

OpenStep verwendete ein flexibleres System und sammelte beim ersten Start des Systems eine Liste von Bibliotheken von einer Reihe bekannter Speicherorte (ähnlich dem PATH-Konzept). Das Verschieben von Bibliotheken verursacht überhaupt keine Probleme, obwohl Benutzer beim ersten Start des Systems einen Zeitaufwand verursachen.

Unix-ähnliche Systeme

Die meisten Unix-ähnliche Systeme haben einen „Suchpfad“ Dateisystem - Verzeichnisse , in denen für dynamische Bibliotheken zu suchen. Einige Systeme geben den Standardpfad in einer Konfigurationsdatei an , andere kodieren ihn fest in den dynamischen 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 setuid- und setgid-Programme deaktiviert ist , sodass ein Benutzer ein solches Programm nicht zwingen kann, beliebigen Code mit Root-Rechten auszuführen. Entwicklern von Bibliotheken wird empfohlen, ihre dynamischen Bibliotheken an Stellen im Standardsuchpfad zu platzieren. Auf der anderen Seite kann dies die Installation neuer Bibliotheken problematisch machen, und diese "bekannten" Speicherorte werden schnell zu einer zunehmenden Anzahl von Bibliotheksdateien, was die Verwaltung komplexer macht.

Dynamisches Laden

Dynamisches Laden, eine Untermenge des dynamischen Linkens, beinhaltet das Laden und Entladen einer dynamisch verknüpften Bibliothek zur Laufzeit auf Anfrage. Eine solche Anfrage kann implizit oder explizit erfolgen. Implizite Anforderungen werden gestellt, wenn ein Compiler oder statischer Linker Bibliotheksverweise hinzufügt, die Dateipfade oder einfach Dateinamen enthalten. Explizite Anforderungen werden gestellt, wenn Anwendungen direkte Aufrufe an die API eines Betriebssystems durchführen.

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, FreeLibraryund GetProcAddressmit Microsoft Dynamic Link Libraries ; POSIX- basierte Systeme, einschließlich der meisten UNIX- und UNIX-ähnlichen Systeme, verwenden dlopen, dlcloseund dlsym. Einige Entwicklungssysteme automatisieren diesen Prozess.

Objektbibliotheken

Obwohl die dynamische Verknüpfung ursprünglich in den 1960er Jahren eingeführt wurde, erreichte sie erst Ende der 1980er Jahre Betriebssysteme, die von Verbrauchern verwendet wurden. Es war in den meisten Betriebssystemen in den frühen 1990er Jahren in irgendeiner Form allgemein verfügbar. Im gleichen Zeitraum entwickelte sich die objektorientierte Programmierung (OOP) zu einem bedeutenden Bestandteil der Programmierlandschaft. OOP mit Laufzeitbindung erfordert zusätzliche Informationen, die herkömmliche Bibliotheken nicht bereitstellen. Zusätzlich zu den Namen und Einstiegspunkten des darin enthaltenen Codes benötigen sie auch eine Liste der Objekte, von denen sie abhängen. Dies ist ein Nebeneffekt eines der Hauptvorteile von OOP, der Vererbung, was bedeutet, dass sich Teile der vollständigen Definition jeder Methode an verschiedenen Stellen befinden können. Dies ist mehr als nur eine Auflistung, dass eine Bibliothek die Dienste einer anderen benötigt: In einem echten OOP-System sind die Bibliotheken selbst zur Kompilierzeit möglicherweise nicht bekannt und variieren von System zu System.

Gleichzeitig arbeiteten viele Entwickler an der Idee von Multi-Tier-Programmen, bei denen ein auf einem Desktop-Rechner laufendes "Display" die Dienste eines Großrechners oder Minicomputers zur Datenspeicherung oder -verarbeitung nutzt . Zum Beispiel würde ein Programm auf einem GUI-basierten Computer Nachrichten an einen Minicomputer senden, um kleine Samples eines riesigen Datensatzes zur Anzeige zurückzugeben. Remote Procedure Calls (RPC) erledigten diese Aufgaben bereits, aber es gab kein Standard-RPC-System.

Bald startete die Mehrheit der Minicomputer- und Mainframe-Hersteller Projekte, um die beiden zu kombinieren und ein OOP-Bibliotheksformat zu entwickeln, das überall verwendet werden konnte. Solche Systeme wurden als Objektbibliotheken oder verteilte Objekte bezeichnet , wenn sie Fernzugriff unterstützten (nicht alle taten dies). COM von Microsoft ist ein Beispiel für ein solches System für den lokalen Gebrauch. DCOM, eine modifizierte Version von COM, unterstützt den Remotezugriff.

Objektbibliotheken hielten lange Zeit den Status des "nächsten großen Dings" in der Programmierwelt. Es gab eine Reihe von Bemühungen, plattformübergreifende Systeme zu entwickeln, und Unternehmen wetteiferten darum, Entwickler an ihr eigenes System zu binden. Beispiele hierfür sind IBM 's - System Object Model (SOM / DSOM), Sun Microsystems ' Distributed Objects Überall (DOE), NeXT 's Tragbare verteilte Objekte (PDO), Digitale ' s Object , Microsoft Component Object Model (COM / DCOM) und beliebig viele CORBA -basierte Systeme.

Klassenbibliotheken

Klassenbibliotheken sind das grobe OOP-Äquivalent älterer Arten von Codebibliotheken. Sie enthalten Klassen , die Eigenschaften beschreiben und Aktionen ( Methoden ) definieren, die Objekte betreffen. Klassenbibliotheken werden verwendet, um Instanzen oder Objekte zu erstellen , deren Eigenschaften auf bestimmte Werte festgelegt sind. In einigen OOP-Sprachen wie Java ist der Unterschied klar, da die Klassen oft in Bibliotheksdateien enthalten sind (wie das JAR-Dateiformat von Java ) und die instanziierten Objekte nur im Speicher gespeichert sind (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 Zustand der Umgebung, Klassen und alle instanziierten Objekte enthält.

Heutzutage werden die meisten Klassenbibliotheken in einem Paket-Repository (wie Maven Central für Java) gespeichert . Client-Code deklariert explizit die Abhängigkeiten zu externen Bibliotheken in Build- Konfigurationsdateien (wie einem Maven Pom in Java).

Remote-Bibliotheken

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

Ein solcher Ansatz bedeutet jedoch, dass jeder Bibliotheksaufruf einen erheblichen Overhead erfordert. RPC-Aufrufe sind viel teurer als der Aufruf einer gemeinsam genutzten Bibliothek, die bereits auf demselben Computer geladen wurde. Dieser Ansatz wird häufig in einer verteilten Architektur verwendet , die solche Remote-Aufrufe stark nutzt, insbesondere Client-Server-Systeme und Anwendungsserver wie Enterprise JavaBeans .

Bibliotheken zur Codegenerierung

Codegenerierungsbibliotheken sind APIs auf hoher Ebene , die Bytecode für Java generieren oder umwandeln können . Sie werden von der Aspektorientierten Programmierung , einigen Datenzugriffs-Frameworks und zum Testen verwendet, um dynamische Proxy-Objekte zu generieren. Sie werden auch verwendet, um den Feldzugriff abzufangen.

Dateibenennung

Modernste Unix-ähnliche Systeme

Das System speichert libfoo.aund libfoo.soDateien in Verzeichnissen wie /lib, /usr/liboder /usr/local/lib. Die Dateinamen beginnen immer mit libund enden mit einem Suffix von .a( Archiv , statische Bibliothek) oder von .so(Shared Object, dynamisch verknüpfte Bibliothek). Einige Systeme haben möglicherweise mehrere Namen für eine dynamisch verknüpfte Bibliothek. Diese Namen haben normalerweise dasselbe Präfix und unterschiedliche Suffixe, die die Versionsnummer angeben. Die meisten Namen sind Namen für symbolische Links zur neuesten Version. Auf einigen Systemen libfoo.so.2wäre beispielsweise der Dateiname für die zweite Hauptschnittstellenrevision der dynamisch verknüpften Bibliothek libfoo. Die .laDateien, die manchmal in den Bibliotheksverzeichnissen gefunden werden, sind libtool- Archive, die vom System als solche nicht verwendet werden können.

Mac OS

Das System erbt statische Bibliothekskonventionen von BSD , wobei die Bibliothek in einer .aDatei gespeichert ist , und kann .sodynamisch verknüpfte Bibliotheken im -Stil verwenden ( .dylibstattdessen mit dem Suffix). Die meisten Bibliotheken in macOS bestehen jedoch aus "Frameworks", die in speziellen Verzeichnissen namens " Bundles " platziert sind, die die erforderlichen Dateien und Metadaten der Bibliothek einschließen. Zum Beispiel MyFrameworkwürde ein Framework namens in einem Bundle namens implementiert MyFramework.framework, wobei MyFramework.framework/MyFrameworkes sich entweder um die dynamisch verknüpfte Bibliotheksdatei oder um einen symbolischen Link zur dynamisch verknüpften Bibliotheksdatei in MyFramework.framework/Versions/Current/MyFramework.

Microsoft Windows

Dynamic-Link-Bibliotheken haben normalerweise das Suffix *.DLL, obwohl andere Dateinamenerweiterungen dynamisch gelinkte Bibliotheken *.OCXfür spezielle Zwecke identifizieren können, zB für OLE- Bibliotheken. Die Schnittstellenrevisionen sind entweder in den Dateinamen kodiert oder über COM-Objektschnittstellen abstrahiert . Je nachdem, wie sie kompiliert werden, können *.LIBDateien entweder statische Bibliotheken oder Repräsentationen von dynamisch verknüpfbaren Bibliotheken sein, die nur während der Kompilierung benötigt werden, bekannt als " Importbibliotheken ". Anders als in der UNIX- Welt, die unterschiedliche Dateierweiterungen verwendet, muss man beim Linken gegen .LIBDatei in Windows zunächst wissen, ob es sich um eine reguläre statische Bibliothek oder eine Importbibliothek handelt. Im letzteren Fall .DLLmuss zur Laufzeit eine Datei vorhanden sein.

Siehe auch

Anmerkungen

Verweise

Weiterlesen