| Executabil portabil | |
|---|---|
| Extensie | .exe, .dll, .ocx, .sys, .scr, .drv, .cpl, .efi, .acm, .ax, .muisau.tsp |
| tip MIME | application/vnd.microsoft.portable-executable [1] și application/efi [2] |
| Tip de format | binar , executabil , obiect , bibliotecă dinamică |
| Fișiere media la Wikimedia Commons | |
Portable Executable ( PE , „executabil portabil”) este un format de fișiere executabile , cod obiect și biblioteci dinamice (DLL) utilizate în versiunile pe 32 și 64 de biți ale sistemului de operare Microsoft Windows . Formatul PE este o structură de date care conține toate informațiile de care un încărcător PE are nevoie pentru a mapa un fișier în memorie. Codul executabil include legături pentru conectarea bibliotecilor încărcate dinamic, tabele de export și import API , date de gestionare a resurselor și date de stocare locală ( TLS ). În sistemele de operare din familia Windows NT , formatul PE este utilizat pentru EXE , DLL , SYS (drivere de dispozitiv) și alte tipuri de fișiere executabile.
PE este o versiune modificată a formatului de fișier COFF pentru Unix . PE/COFF este un termen alternativ în dezvoltarea Windows.
Pe sistemele de operare din familia Windows NT, formatul PE acceptă în prezent următoarele arhitecturi de seturi de instrucțiuni : IA-32 , IA-64 și x86-64 (AMD64/Intel64). Înainte de Windows 2000 , Windows NT (și, prin urmare, PE) suporta MIPS , Alpha și PowerPC . Deoarece PE este utilizat pe Windows CE , acesta continuă să accepte mai multe variante de MIPS , ARM (inclusiv Thumb ) și SuperH .
Principalii concurenți ai PE sunt ELF (utilizat pe Linux și majoritatea celorlalte versiuni de Unix ) și Mach-O (utilizat pe Mac OS X ).
Odată cu apariția sistemului de operare Windows NT 3.1 , Microsoft a trecut la formatul PE. Toate versiunile ulterioare de Windows, inclusiv Windows 95/98/ME, acceptă acest format. Formatul a păstrat suport limitat pentru cel existent ( MZ ) pentru a reduce decalajul dintre sistemele bazate pe DOS și sistemele NT. De exemplu, anteturile PE/COFF încă includ programul executabil MS-DOS, care este implicit un stub care afișează un mesaj simplu "This program cannot be run in DOS mode" - „Acest program nu poate fi executat în modul DOS” (sau similar). PE continuă să servească platforma Windows în schimbare. Unele extensii includ formatul PE.NET (vezi mai jos), o versiune pe 64 de biți numită PE32+ (uneori PE+) și o specificație pentru Windows CE.
Primii 2 octeți ai fișierului PE conțin semnătura 0x4D 0x5A - „MZ” (ca succesor al formatului MZ ). Apoi, cuvântul dublu de la offset 0x3C conține adresa antetului PE. Acesta din urmă începe cu semnătura 0x50 0x45 - „PE”.
Un fișier PE este format din mai multe anteturi și secțiuni care îi spun linkerului dinamic cum să mapați fișierul în memorie. Imaginea executabilă constă din mai multe zone (secțiuni), fiecare dintre acestea necesită drepturi de acces la memorie diferite; astfel, începutul fiecărei secțiuni trebuie să fie aliniat la limita paginii. De exemplu, de obicei, secțiunea .text, care conține codul programului, este afișată ca executabil/numai citire, iar secțiunea .data, care conține variabile globale, este afișată ca non-executable/citire-scriere. Cu toate acestea, pentru a nu pierde spațiu pe hard disk, diferitele secțiuni de pe acesta nu sunt aliniate la limita paginii. O parte a sarcinii linkerului dinamic este de a mapa fiecare secțiune în memorie separat și de a atribui permisiunile corecte zonelor rezultate, conform indicațiilor din antete.
O secțiune binecunoscută este Import Address Table (IAT), care este folosit ca tabel de căutare atunci când o aplicație apelează o funcție dintr-un alt modul. Acest lucru se poate face atât sub formă de import prin funcție ordinal (ordinal) cât și sub formă de import după numele funcției. Deoarece programul compilat nu cunoaște locația bibliotecilor de care depinde, trebuie să sară indirect ori de câte ori este efectuat un apel API. Când linkerul dinamic încarcă module și le combină, scrie adresele reale în zona IAT, astfel încât acestea să indice locațiile de memorie ale funcțiilor de bibliotecă corespunzătoare. În timp ce acest lucru adaugă un pas suplimentar în cadrul modulului, rezultând o penalizare de performanță, oferă un beneficiu esențial: numărul de pagini de memorie care trebuie copiat de către încărcător la scriere este minimizat, rezultând economii de memorie și de timp I/O pe disc. . Dacă compilatorul știe dinainte că apelul va fi inter-module (prin atributul dllimport), atunci poate produce un cod mai optimizat care duce pur și simplu la opcode apel indirect .
Tabelul de adrese de export (EAT - Export Address Table) este necesar pentru ca un modul (de obicei o bibliotecă încărcată dinamic ) să poată spune altor module ce funcții pot importa din el și la ce adrese se află acestea din urmă.
Fișierele PE nu conțin cod independent de poziție . În schimb, acestea sunt compilate la o adresă de bază preferată și toate adresele generate de compilator/linker sunt fixate în avans. Dacă fișierul PE nu poate fi încărcat la adresa preferată (pentru că este deja preluat de altceva), sistemul de operare îl va rebaza . Aceasta include recalcularea fiecărei adrese absolute și schimbarea codului pentru a utiliza noile valori. Descărcătorul face acest lucru comparând adresele de descărcare preferate și reale și calculând diferența . Apoi, pentru a obține o nouă adresă de celulă de memorie, această diferență se adaugă la adresa preferată. Adresele de relocare de bază sunt stocate într-o listă și adăugate la o locație de memorie existentă, după cum este necesar. Codul rezultat este acum separat de proces și nu mai este partajat, astfel încât multe dintre beneficiile de economisire a memoriei ale bibliotecilor încărcate dinamic se pierd în acest fel. Această metodă încetinește semnificativ încărcarea modulelor. Din acest motiv, rebazările ar trebui evitate ori de câte ori este posibil; de exemplu, bibliotecile furnizate de Microsoft au adrese de bază precalculate care nu se suprapun. În absența unei rebaze, fișierele PE au avantajul unui cod foarte eficient, dar în prezența unei rebaze, suprasarcina în utilizarea memoriei poate fi semnificativă. Acest lucru distinge formatul PE de ELF , care utilizează cod complet independent de poziție și un tabel global de compensare care sacrifică timpul de execuție în favoarea risipei de memorie.
Platforma Microsoft .NET a extins formatul PE cu funcții care acceptă Common Language Runtime (CLR). Adăugările includ un antet CLR și o secțiune de date CLR. După ce binarul este încărcat, încărcătorul OS face ca CLR să fie executat printr-o legătură în tabelul de import PE/COFF. CLR încarcă apoi antetul CLR și secțiunile de date.
Secțiunea de date CLR conține două segmente importante: segmentul de metadate și segmentul de cod al limbajului intermediar (IL):
Formatul PE este folosit și de ReactOS , deoarece ReactOS este proiectat să fie compatibil binar cu Windows la nivel de cod. În plus, a fost folosit în trecut de multe alte sisteme de operare, inclusiv SkyOS și BeOS R3. Cu toate acestea, atât SkyOS, cât și BeOS au trecut în cele din urmă la formatul ELF.
Deoarece platforma de dezvoltare Mono intenționează să fie compatibilă binar cu Microsoft .NET , folosește același format PE ca și implementarea Microsoft.
Pe platforma x86 pe sisteme de operare asemănătoare Unix, unele binare Windows (în format PE) pot fi executate folosind Wine . HX DOS Extender utilizează, de asemenea, formatul PE pentru binarele DOS native pe 32 de biți și poate rula binare Windows existente pe DOS într-o oarecare măsură, acționând astfel ca Wine pentru DOS.
Mac OS X 10.5 are capacitatea de a încărca și interpreta fișiere PE, totuși acestea nu sunt compatibile binar cu Windows.
| Formate de fișiere executabile ( comparație ) | |
|---|---|
| Unix | |
| Windows , DOS și OS/2 | |
| Alte | |
| Componente și API-uri OS/2 | |
|---|---|
| Principal | |
| Servicii de management | |
| Jocuri |
|
| Nucleul OS | |
| Sisteme de fișiere | |
| Subsistemul grafic |
|
| Model obiect | SOM
|
| Compatibilitate |
|