Das Format von Portable Executable (PE) ist ein Dateiformat für executables, Gegenstand-Code und DLLs, der in 32-bit- und 64-Bit-Versionen von Windows Betriebssysteme verwendet ist. Der Begriff "tragbarer" bezieht sich auf die Vielseitigkeit des Formats in zahlreichen Umgebungen der Betriebssystemsoftwarearchitektur. Das PE-Format ist eine Datenstruktur, die die Information kurz zusammenfasst, die für Windows OS Lader notwendig ist, um den gewickelten rechtskräftigen Code zu führen. Das schließt dynamische Bibliotheksverweisungen für Verbindung, API-Export und Importtische, Quellenverwaltungsdaten und Daten der mit dem Faden lokalen Lagerung (TLS) ein. Auf NT Betriebssysteme wird das PE-Format für EXE, DLL, SYS (Gerät-Fahrer), und andere Dateitypen verwendet. Die Spezifizierung von Extensible Firmware Interface (EFI) stellt fest, dass PE das rechtskräftige Standardformat in EFI Umgebungen ist.

PE ist eine modifizierte Version des Unix COFF Dateiformat. PE/COFF ist ein alternativer Begriff in der Windows-Entwicklung.

Auf Windows NT Betriebssysteme unterstützt PE zurzeit den IA-32, IA-64 und x86-64 (AMD64/Intel64) Befehlssatz-Architekturen (ISAs). Vor Windows 2000 hat Windows NT (und so PE) den MIPS, das Alpha und PowerPC ISAs unterstützt. Weil PE auf dem Windows CE verwendet wird, setzt er fort, mehrere Varianten des MIPS, ARM (einschließlich des Daumens), und SuperH ISAs zu unterstützen.

Die Hauptmitbewerber zu PE sind ELF (verwendet in Linux und den meisten anderen Versionen von Unix) und Betont männlich (verwendet in Mac OS X).

Kurze Geschichte

Microsoft ist zum PE-Format mit der Einführung von Windows NT 3.1 Betriebssystem abgewandert. Alle späteren Versionen von Windows, einschließlich Windows 95/98/me, unterstützen die Dateistruktur. Das Format hat beschränkte Vermächtnis-Unterstützung behalten, um die Lücke zwischen DOS-BASIERTEN und NT Systemen zu überbrücken. Zum Beispiel schließen Kopfbälle von PE/COFF noch ein MS-DOS rechtskräftiges Programm ein, das standardmäßig ein Stummel ist, der die einfache Nachricht "Dieses Programm zeigt, kann in der DOS-Weise" (oder ähnlich) nicht geführt werden. PE setzt auch fort, der sich ändernden Windows-Plattform zu dienen. Einige Erweiterungen schließen den.NET PE Format (sieh unten), eine 64-Bit-Version genannt PE32 + (manchmal PE +), und eine Spezifizierung für das Windows CE ein.

Technische Details

Lay-Out

Eine PE Datei besteht aus mehreren Kopfbällen und Abteilungen, die den dynamischen linker erzählen, wie man die Datei ins Gedächtnis kartografisch darstellt. Ein rechtskräftiges Image besteht aus mehreren verschiedenen Gebieten, von denen jedes verschiedenen Speicherschutz verlangen; so muss der Anfang jeder Abteilung zu einer Seitengrenze ausgerichtet werden. Zum Beispiel normalerweise wird die.text Abteilung (der Programm-Code hält) kartografisch dargestellt, wie/read-only-durchführen, und die.data Abteilung (globale Variablen haltend), als no-execute/readwrite kartografisch dargestellt wird. Jedoch, um zu vermeiden, Raum zu vergeuden, sind die verschiedenen Abteilungen nicht auf der Platte ausgerichtete Seite. Ein Teil des Jobs des dynamischen linker ist, jede Abteilung zum Gedächtnis individuell kartografisch darzustellen und die richtige Erlaubnis den resultierenden Gebieten gemäß den in den Kopfbällen gefundenen Instruktionen zuzuteilen.

Importtisch

Eine Abteilung des Zeichens ist das Importadressbuch (IAT), das als eine Nachschlagetabelle verwendet wird, wenn die Anwendung eine Funktion in einem verschiedenen Modul nennt. Es kann in der Form sowohl des Imports durch den Ordnungs-sein als auch namentlich importieren. Weil ein kompiliertes Programm die Speicherposition der Bibliotheken nicht wissen kann, von denen es abhängt, ist ein indirekter Sprung erforderlich, wann auch immer ein API-Anruf gemacht wird. Da der dynamische linker Module lädt und sich ihnen zusammen anschließt, schreibt er wirkliche Adressen in die IAT Ablagefächer, so dass sie zu den Speicherpositionen der entsprechenden Bibliotheksfunktionen hinweisen. Obwohl das einen Extrasprung über die Kosten eines Intramodul-Anrufs hinzufügt, der auf eine Leistungsstrafe hinausläuft, stellen sie einen Schlüsselvorteil zur Verfügung: Die Zahl von Speicherseiten, die durch den Lader geänderter copy-write sein müssen, wird minimiert, Gedächtnis und Platteneingabe/Ausgabe-Zeit sparend. Wenn der Bearbeiter vorzeitig weiß, dass ein Anruf Zwischenmodul sein wird (über ein Dllimport-Attribut), kann es mehr optimierten Code erzeugen, der einfach auf einen indirekten Anruf opcode hinausläuft.

Wiederpositionen

PE Dateien enthalten mit der Position unabhängigen Code nicht. Stattdessen werden sie zu einer bevorzugten Grundadresse kompiliert, und alle durch den compiler/linker ausgestrahlten Adressen werden vorzeitig befestigt. Wenn eine PE Datei an seiner bevorzugten Adresse nicht geladen werden kann (weil sie bereits von etwas anderem genommen wird), wird das Betriebssystem sie wiederstützen. Das schließt das Wiederrechnen jeder absoluten Adresse und Ändern des Codes ein, um die neuen Werte zu verwenden. Der Lader tut das durch das Vergleichen der bevorzugten und wirklichen Lastadressen und das Rechnen eines Delta-Werts. Das wird dann zur bevorzugten Adresse hinzugefügt, um die neue Adresse der Speicherposition zu präsentieren. Basisadressverschiebungen werden in einer Liste versorgt und, wie erforderlich, zu einer vorhandenen Speicherposition hinzugefügt. Der resultierende Code ist jetzt zum Prozess und nicht mehr shareable privat, so viele der Speichersparen-Vorteile von DLLs werden in diesem Drehbuch verloren. Es verlangsamt auch das Laden des Moduls bedeutsam. Aus diesem Grund das Wiedergründen, soll wo auch immer möglich, vermieden werden, und die von Microsoft verladenen DLLs haben vorgeschätzte Grundadressen, um nicht zu überlappen. In keinem Wiedergrundfall ist PE deshalb im Vorteil des sehr effizienten Codes, aber in Gegenwart vom Wiedergründen des Speichergebrauch-Erfolgs kann teuer sein. Das hebt sich vom ELFEN ab, der völlig Position unabhängiger Code und eine globale Ausgleich-Tabelle verwendet, die von der Ausführungszeit gegen den Speichergebrauch für den letzten handelt

.NET, metadata, und das PE-Format

Das.NET Fachwerk des Microsofts hat das PE-Format mit Eigenschaften erweitert, die Common Language Runtime (CLR) unterstützen. Unter den Hinzufügungen sind ein CLR Kopfball und CLR Datenabteilung. Nach dem Laden einer Dualzahl gibt der OS Lader Ausführung zum CLR über eine Verweisung im IMPORT-Tisch von PE/COFF nach. Der CLR lädt dann den CLR Kopfball und die Datenabteilungen.

Die CLR Datenabteilung enthält zwei wichtige Segmente: Metadata und Code von Intermediate Language (IL):

• Metadata enthält Information, die für den Zusammenbau einschließlich des Zusammenbau-Manifests wichtig ist. Ein Manifest beschreibt den Zusammenbau im Detail einschließlich der einzigartigen Identifizierung (über ein Kuddelmuddel, Versionsnummer, usw.), Daten auf exportierten Bestandteilen, umfassende Typ-Information (unterstützt von Common Type System (CTS)), externe Verweise und eine Liste von Dateien innerhalb des Zusammenbaues. Die CLR Umgebung macht umfassenden Gebrauch von metadata.
• Code von Intermediate Language (IL), wird Sprache unabhängiger Code abstrahiert, der die Voraussetzung von Common Intermediate Language (CIL) des.NET CLR befriedigt. Der Begriff "Zwischenglied" bezieht sich auf die Natur des IL-Codes, der Quer-Sprache und vereinbare Quer-Plattform ist. Diese Zwischensprache, die nach Java bytecode ähnlich ist, erlaubt Plattformen und Sprachen, den allgemeinen.NET CLR zu unterstützen. IL unterstützt objektorientierte Programmierung (polymorphism, Erbe, abstrakte Typen, usw.), Ausnahmen, Ereignisse und verschiedene Datenstrukturen.

Verwenden Sie auf anderen Betriebssystemen

Das PE-Format wird auch von ReactOS verwendet, weil ReactOS beabsichtigt ist, um mit Windows binär-vereinbar zu sein. Es ist auch durch mehrere andere Betriebssysteme, einschließlich SkyOS und BeOS R3 historisch verwendet worden. Jedoch haben sich sowohl SkyOS als auch BeOS schließlich dem ELFEN bewegt.

Da die Modoentwicklungsplattform vorhat, vereinbar mit Microsoft.NET zu sein binär, verwendet es dasselbe PE-Format wie die Durchführung von Microsoft.

Auf x86, Unix ähnlichen Betriebssystemen, können einige Windows-Dualzahlen (im PE-Format) mit Wein durchgeführt werden. Das HX DOS-Ex-Anerbieten verwendet auch das PE-Format für heimische DOS-32-Bit-Dualzahlen, plus es kann zu einem gewissen Grad vorhandene Windows-Dualzahlen in DOS durchführen, so wie ein Wein für DOS handelnd.

Mac OS X 10.5 ist in der Lage, PE Dateien zu laden und grammatisch zu analysieren, aber ist vereinbar mit Windows nicht binär.

Siehe auch

• EXE
• Rechtskräftig und Linkable-Format
• Betont männlicher
• a.out
• Der Vergleich der rechtskräftigen Datei formatiert
• Rechtskräftige Kompression
• Anwendungsvirtualisierung

Links

• PeStudio ein netter GUI, um PE Images zu analysieren
• Tragbare Rechtskräftige PE/PE32 + Poster in A1 formatieren
• Microsoft Portable Executable und Allgemeine Gegenstand-Dateiformat-Spezifizierung (letzte Ausgabe, OOXML Format)
• Microsoft Portable Executable und Allgemeine Gegenstand-Dateiformat-Spezifizierung (1999-Ausgabe.doc Format)
• Der ursprüngliche Artikel Portable Executable von Matt Pietrek (MSDN Zeitschrift, März 1994)
• Erster Teil. Ein Eingehender Blick ins Win32 Tragbare Rechtskräftige Dateiformat durch Matt Pietrek (MSDN Zeitschrift, Februar 2002)
• Zweiter Teil. Ein Eingehender Blick ins Win32 Tragbare Rechtskräftige Dateiformat durch Matt Pietrek (MSDN Zeitschrift, März 2002)
• Das.NET Dateiformat durch Daniel Pistelli
• Das Schaffen der kleinstmöglichen PE rechtskräftigen (97 Bytes)
• Das Detaillieren des PE formatiert durch Johannes Plachy
• Windows Authenticode tragbares rechtskräftiges Unterschrift-Format
• Die Beschreibung von LUEVELSMEYER über die PE Datei formatiert Spiegel
• Finden Sie Win32 Kopfbälle von PE/COFF in EXE/DLL/OCX Dateien unter linux/unix.
• Online-Werkzeug, um Win32/Win64 PE Dualzahlen zu analysieren
• PE Dokumentation mit dem Beweis der Konzepte und den Graphen