Přenosný spustitelný soubor

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 ).

Stručná historie

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.

Technické detaily

Podpis

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".

Struktura

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í.

Import tabulky

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 .

Export tabulky

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í.

Tabulka pohybu

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í.

.NET, metadata a formát PE

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):

Použití na jiných operačních systémech

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.

Viz také

Poznámky

  1. https://www.iana.org/assignments/media-types/application/vnd.microsoft.portable-executable
  2. https://www.iana.org/assignments/media-types/application/efi

Odkazy