Přenosný spustitelný soubor | |
---|---|
Rozšíření | .exe, .dll, .ocx, .sys, .scr, .drv, .cpl, .efi, .acm, nebo .ax_.mui.tsp |
MIME typ | application/vnd.microsoft.portable-executable [1] a application/efi [2] |
Typ formátu | binární , spustitelný , objekt , dynamická knihovna |
Mediální soubory na Wikimedia Commons |
Portable Executable ( PE , „portable executable“) je formát spustitelných souborů , objektového kódu a dynamických knihoven (DLL) používaný v 32- a 64bitových verzích operačního systému Microsoft Windows . Formát PE je datová struktura obsahující všechny informace, které zavaděč PE potřebuje k mapování souboru do paměti. Spustitelný kód obsahuje odkazy pro propojení dynamicky načítaných knihoven, tabulky exportu a importu rozhraní API , data správy prostředků a data místního úložiště vláken ( TLS ). Na operačních systémech rodiny Windows NTformát PE se používá pro EXE , DLL , SYS (ovladače zařízení) a další typy spustitelných souborů.
PE je upravená verze formátu souboru COFF pro Unix . PE/COFF je alternativní termín ve vývoji Windows.
V operačních systémech řady Windows NT formát PE aktuálně podporuje následující architektury instrukční sady : IA-32 , IA-64 a x86-64 (AMD64/Intel64). Před Windows 2000 podporovaly Windows NT (a tedy PE) MIPS , Alpha a PowerPC . Protože PE se používá ve Windows CE , nadále podporuje několik variant MIPS , ARM (včetně Thumb ) a SuperH .
Hlavními konkurenty PE jsou ELF (používaný na Linuxu a většině ostatních verzí Unixu ) a Mach-O (používaný na Mac OS X ).
S příchodem operačního systému Windows NT 3.1 Microsoft přešel na formát PE. Všechny novější verze Windows, včetně Windows 95/98/ME, podporují tento formát. Formát si zachoval omezenou podporu pro existující ( MZ ), aby překlenul mezeru mezi systémy založenými na DOSu a systémy NT. Například hlavičky PE/COFF stále obsahují spustitelný program MS-DOS, což je ve výchozím nastavení útržek , který zobrazuje jednoduchou zprávu "This program cannot be run in DOS mode" – „Tento program nelze spustit v režimu DOS“ (nebo podobně). PE nadále slouží měnící se platformě Windows. Některá rozšíření zahrnují formát PE.NET (viz níže), 64bitovou verzi s názvem PE32+ (někdy PE+) a specifikaci pro Windows CE.
První 2 byty PE souboru obsahují signaturu 0x4D 0x5A - "MZ" (jako nástupce formátu MZ ). Dále dvojité slovo na offsetu 0x3C obsahuje adresu PE hlavičky. Ten začíná podpisem 0x50 0x45 - "PE".
Soubor PE se skládá z několika záhlaví a sekcí, které říkají dynamickému linkeru, jak namapovat soubor do paměti. Spustitelný obraz se skládá z několika různých oblastí (sekcí), z nichž každá vyžaduje jiná přístupová práva do paměti; proto musí být začátek každého oddílu zarovnán k okraji stránky. Například obvykle se sekce .text, která obsahuje kód programu, zobrazí jako spustitelný/pouze pro čtení a sekce .data, která obsahuje globální proměnné, se zobrazí jako nespustitelná/pro čtení/zápis. Aby však nedocházelo k plýtvání místem na pevném disku, nejsou různé sekce na něm zarovnány s okrajem stránky. Součástí úlohy dynamického linkeru je mapování každé sekce do paměti zvlášť a přiřazení správných oprávnění k výsledným oblastem podle pokynů záhlaví.
Jedna dobře známá sekce je Import Address Table (IAT), která se používá jako vyhledávací tabulka, když aplikace volá funkci z jiného modulu. To lze provést jak ve formě importu podle funkce ordinální (ordinální), tak importu podle názvu funkce. Vzhledem k tomu, že zkompilovaný program nezná umístění knihoven, na kterých závisí, potřebuje nepřímo přeskakovat při každém volání API. Když dynamický linker načte moduly a zkombinuje je, zapíše skutečné adresy do oblasti IAT tak, aby ukazovaly na paměťová místa odpovídajících funkcí knihovny. I když to přidává další krok v modulu, což má za následek snížení výkonu, poskytuje to klíčovou výhodu: počet stránek paměti, které musí zavaděč při zápisu zkopírovat, je minimalizován, což vede k úspoře paměti a času vstupu/výstupu na disku. . Pokud kompilátor předem ví, že volání bude mezimodulové (prostřednictvím atributu dllimport), může vytvořit optimalizovanější kód, který jednoduše vyústí v nepřímé volání opcode .
Exportní tabulka adres (EAT - Export Address Table) je potřebná k tomu, aby jeden modul (obvykle dynamicky načítaná knihovna ) mohl ostatním modulům sdělit, které funkce z ní mohou importovat a na jakých adresách se tyto moduly nacházejí.
Soubory PE neobsahují kód nezávislý na pozici . Místo toho jsou kompilovány na preferovanou základní adresu a všechny adresy generované kompilátorem/linkerem jsou předem pevně dané. Pokud soubor PE nelze načíst na preferovanou adresu (protože je již obsazen něčím jiným), operační systém jej znovu založí . To zahrnuje přepočítání každé absolutní adresy a změnu kódu tak, aby používal nové hodnoty. Stahovací program to provede porovnáním preferované a skutečné adresy pro stahování a výpočtem rozdílu . Poté, aby se získala nová adresa paměťové buňky, je tento rozdíl přidán k preferované adrese. Adresy přemístění základny jsou uloženy v seznamu a podle potřeby přidány k existujícímu umístění v paměti. Výsledný kód je nyní oddělený od procesu a již není sdílen, takže mnoho výhod úspory paměti dynamicky načítaných knihoven je tímto způsobem ztraceno. Tato metoda také výrazně zpomaluje načítání modulů. Z tohoto důvodu je třeba se vyvarovat rebase všude tam, kde je to možné; například knihovny dodané společností Microsoft mají předem vypočítané nepřekrývající se základní adresy. Při absenci rebase mají PE soubory výhodu velmi efektivního kódu, ale v přítomnosti rebase může být režie ve využití paměti značná. To odlišuje formát PE od ELF , který používá kód zcela nezávislý na pozici a globální tabulku offsetů, která obětuje dobu běhu ve prospěch plýtvání pamětí.
Platforma .NET společnosti Microsoft rozšířila formát PE o funkce, které podporují Common Language Runtime (CLR). Mezi doplňky patří hlavička CLR a datová sekce CLR. Po načtení binárního souboru způsobí zavaděč OS spuštění CLR prostřednictvím odkazu v importní tabulce PE/COFF. CLR pak načte hlavičku CLR a datové sekce.
Sekce dat CLR obsahuje dva důležité segmenty: segment metadat a segment kódu středního jazyka (IL):
Formát PE používá také ReactOS , protože ReactOS je navržen tak, aby byl binárně kompatibilní s Windows na úrovni kódu. Kromě toho jej historicky používalo mnoho dalších operačních systémů, včetně SkyOS a BeOS R3. SkyOS i BeOS však nakonec přešly na formát ELF.
Protože vývojová platforma Mono zamýšlí být binárně kompatibilní s Microsoft .NET , používá stejný formát PE jako implementace Microsoftu.
Na platformě x86 na operačních systémech podobných Unixu lze některé binární soubory Windows (ve formátu PE) spustit pomocí Wine . HX DOS Extender také používá formát PE pro nativní 32bitové binární soubory DOS a může do určité míry spouštět existující binární soubory Windows na DOS, takže funguje jako Wine pro DOS.
Mac OS X 10.5 má schopnost načítat a interpretovat soubory PE, nejsou však binárně kompatibilní s Windows.
spustitelných souborů ( srovnání ) | Formáty|
---|---|
Unix | |
Windows , DOS a OS/2 | |
jiný |
API | Komponenty OS/2 a|
---|---|
Hlavní | |
Manažerské služby | |
Hry |
|
jádro OS | |
Souborové systémy | |
Grafický subsystém |
|
Objektový model | SOM
|
Kompatibilita |
|