diff --git a/de_DE.ISO8859-1/books/handbook/basics/chapter.xml b/de_DE.ISO8859-1/books/handbook/basics/chapter.xml index 470f8e73ab..07a1aee82d 100644 --- a/de_DE.ISO8859-1/books/handbook/basics/chapter.xml +++ b/de_DE.ISO8859-1/books/handbook/basics/chapter.xml @@ -5,7 +5,7 @@ $FreeBSD$ $FreeBSDde$ - basiert auf: r42014 + basiert auf: r42604 --> Grundlagen des UNIX Betriebssystems @@ -60,9 +60,6 @@ Geräte und Gerätedateien, - - Binärformate unter &os; und - wie Sie in den Manualpages nach weiteren Informationen suchen können. @@ -2441,180 +2438,6 @@ Swap: 256M Total, 38M Used, 217M Free, 15% Inuse zugegriffen. - - Binärformate - - Wenn ein Kommando an die Shell übergeben wird, dann wird die - Shell die ausführbare Datei in den Speicher laden und einen - neuen Prozess erstellen. Ausführbare Dateien sind entweder - Binärdateien (die meist vom Linker während der Übersetzung - eines Programms erzeugt werden), oder ein Shell-Skript (eine - Textdatei, welche von einer Binärdatei, wie &man.sh.1; oder - &man.perl.1; interpretiert wird). Das Kommando &man.file.1; - kann für gewöhnlich bestimmen, von welchem Typ eine Datei - ist. - - Binärdateien benötigen ein klar definiertes Format, damit - das System in der Lage ist, sie richtig zu verwenden. Ein Teil - der Datei enthält den ausführbaren Maschinencode (Anweisungen - die der CPU sagen, was zu tun ist), ein anderer Teil enthält - Daten mit vordefinierten Werten, ein weiterer wiederum Daten - ohne vordefinierte Werte. Im Laufe der Zeit wurden verschiedene - binäre Dateiformate entwickelt. - - Um zu verstehen, warum &os; das Format &man.elf.5; benutzt, - müssen zunächst die drei gegenwärtig dominanten - ausführbaren Formate für &unix; beschrieben werden: - - - - &man.a.out.5; - - Das älteste und klassische - Objektformat von &unix; Systemen. Es benutzt einen kurzen, - kompakten Header mit einer - &man.magic.5; number am - Anfang, die oft benutzt wird, um das Format zu - charakterisieren. Es enthält drei geladene Segmente: .text, - .data und .bss, sowie eine Symboltabelle und eine - Stringtabelle. - - - - COFF - - Das Objektformat von SVR3. Der Header - enthält eine Sectiontable, die mehr enthalten - kann als nur .text, .data und .bss Sektionen.. - - - - &man.elf.5; - - Der Nachfolger von COFF. - Kennzeichnend sind mehrere Sections und mögliche - 32-Bit- oder 64-Bit-Werte. Ein wesentlicher Nachteil ist, - dass ELF unter der Annahme entworfen - wurde, dass es nur eine ABI (Application Binary Interface) - pro Systemarchitektur geben wird. Tatsächlich ist diese - Annahme falsch, denn nicht einmal für die kommerzielle - SYSV-Welt (in der es mindestens drei ABIs gibt: SVR4, - Solaris, SCO) trifft sie zu. - - &os; versucht dieses Problem zu umgehen, indem - ein Werkzeug bereitgestellt wird, um ausführbare - Dateien im ELF-Format mit - Informationen über die ABI zu versehen, zu der - sie passen. Weitere Informationen finden Sie in - &man.brandelf.1;. - - - - &os; kommt aus dem klassischen Lager - und verwendete traditionell das Format &man.a.out.5;, eine - Technik, die bereits über viele BSD-Releases - hinweg eingesetzt und geprüft worden ist. Obwohl es - bereits seit einiger Zeit möglich war, auf einem - &os;-System auch Binaries (und Kernel) im - ELF-Format zu erstellen und - auszuführen, widersetzte &os; sich anfangs dem - Druck, auf ELF als - Standardformat umzusteigen. Warum? Nun, als - Linux die schmerzhafte Umstellung auf - ELF durchführte, weil der - unflexible, auf Sprungtabellen basierte Mechanismus - für Shared-Libraries der die Konstruktion von - Shared-Libraries für Hersteller und Entwickler kompliziert - machte. Da die verfügbaren ELF-Werkzeuge - eine Lösung für das Problem mit den Shared-Libraries - anboten und generell als ein Schritt - vorwärts angesehen wurden, wurde der Aufwand - für die Umstellung als notwendig akzeptiert und die - Umstellung wurde durchgeführt. Unter &os; ist der - Mechanismus von Shared-Libraries enger an den Stil des - Shared-Library-Mechanismus von &sunos; - angelehnt und einfacher zu verwenden. - - Ja, aber warum gibt es so viele unterschiedliche Formate? - Damals zu Zeiten der PDP-11, als simple Hardware ein einfaches, - kleines System unterstützte, war a.out - absolut passend für die Aufgabe, Binaries darzustellen. Als - &unix; portiert wurde, wurde auch das - a.out-Format beibehalten, weil es für die - frühen Portierungen auf Architekturen wie den Motorola 68k oder - die VAX ausreichte. - - Dann dachte sich ein schlauer Hardware-Ingenieur, - dass, wenn er Software zwingen könnte, einige - Tricks anzustellen, es ihm möglich wäre, ein - paar Gatter im Design zu sparen, und die CPU - schneller zu machen. a.out war für diese - neue Art von Hardware, bekannt als RISC, - schlecht geeignet. Viele neue Formate wurden entwickelt, um - eine bessere Leistung auf dieser Hardware zu erreichen, als mit - dem begrenzten, simplen a.out-Format. - COFF, ECOFF und - einige andere wurden erdacht und ihre Grenzen - untersucht, bevor man sich auf ELF - festgelegt hat. - - Hinzu kam, dass die Größe von - Programmen gewaltig wurde und Festplatten sowie - physikalischer Speicher immer noch relativ klein waren. - Also wurde das Konzept von Shared-Libraries geboren. Die - virtuelle Speicherverwaltung wurde auch immer fortgeschrittener. - Obwohl bei jedem dieser Fortschritte das - a.out-Format benutzt worden ist, - wurde sein Nutzen mit jedem neuen Merkmal mehr gedehnt. - Zusätzlich wollte man Dinge dynamisch zur - Ausführungszeit laden, oder Teile eines Programms - nach der Initialisierung wegwerfen, um Hauptspeicher - oder Swap-Speicher zu sparen. Programmiersprachen - wurden immer fortschrittlicher und man wollte, dass - Code automatisch vor der main-Funktion aufgerufen wird. - Das a.out-Format wurde oft - überarbeitet, um alle diese Dinge zu ermöglichen - und sie funktionierten auch für einige Zeit. - a.out konnte diese Probleme nicht - ohne ein ständiges Ansteigen eines Overheads im Code - und in der Komplexität handhaben. Obwohl - ELF viele dieser Probleme löste, - wäre es sehr aufwändig, ein System umzustellen, das - im Grunde genommen funktionierte. Also musste - ELF warten, bis es aufwändiger war, bei - a.out zu bleiben, als zu - ELF überzugehen. - - Im Laufe der Zeit haben sich die Erstellungswerkzeuge, - von denen &os; seine Erstellungswerkzeuge abgeleitet - hat, speziell der Assembler und der Loader, in zwei - parallele Zweige entwickelt. Im &os;-Zweig wurden - Shared-Libraries hinzugefügt und einige Fehler - behoben. Das GNU-Team, das diese Programme - ursprünglich geschrieben hat, hat sie umgeschrieben - und eine simplere Unterstützung zur Erstellung von - Cross-Compilern durch beliebiges Einschalten verschiedener - Formate hinzugefügt. Viele Leute wollten - Cross-Compiler für &os; erstellen, aber sie hatten - kein Glück, denn &os;'s ältere Sourcen für &man.as.1; und - &man.ld.1; waren hierzu nicht geeignet. Die neuen - GNU-Werkzeuge (binutils) unterstützen - Cross-Compilierung, ELF, Shared-Libraries und - C++-Erweiterungen. Weiterhin geben viele - Hersteller ELF-Binaries heraus und &os; - sollte in der Lage sein, diese ausführen. - - ELF ist ausdrucksfähiger als - a.out und gestattet eine bessere Erweiterbarkeit - des Basissystems. Die ELF-Werkzeuge werden - besser gewartet und bieten Unterstützung für Cross-Compilierung. - ELF mag etwas langsamer sein, als - a.out, aber zu versuchen, das zu messen, - könnte schwierig werden. Es gibt unzählige Details, in - denen sich die beiden Formate unterscheiden, wie sie Pages - abbilden, oder Initialisierungscode handhaben. - - Weitere Informationen