| Bærbar eksekverbar | |
|---|---|
| Udvidelse | .exe, .dll, .ocx, .sys, .scr, .drv, .cpl, .efi, .acm, eller .ax_.mui.tsp |
| MIME -type | application/vnd.microsoft.portable-eksekverbar [1] og application/efi [2] |
| Formattype | binær , eksekverbar , objekt , dynamisk bibliotek |
| Mediefiler på Wikimedia Commons | |
Portable Executable ( PE , "bærbar eksekverbar") er et format af eksekverbare filer , objektkode og dynamiske biblioteker (DLL), der bruges i 32- og 64-bit versioner af Microsoft Windows -operativsystemet . PE-formatet er en datastruktur, der indeholder al den information, en PE-indlæser har brug for for at kortlægge en fil til hukommelsen. Den eksekverbare kode inkluderer links til sammenkædning af dynamisk indlæste biblioteker, API -eksport- og importtabeller , ressourcestyringsdata og TLS -data (Thread Local Storage). I operativsystemer i Windows NT -familien bruges PE-formatet til EXE , DLL , SYS (enhedsdrivere) og andre typer eksekverbare filer.
PE er en modificeret version af COFF -filformatet til Unix . PE/COFF er et alternativt udtryk i Windows-udvikling.
På operativsystemer i Windows NT-familien understøtter PE-formatet i øjeblikket følgende instruktionssætarkitekturer : IA-32 , IA-64 og x86-64 (AMD64/Intel64). Før Windows 2000 understøttede Windows NT (og dermed PE) MIPS , Alpha og PowerPC . Fordi PE bruges på Windows CE , fortsætter det med at understøtte flere varianter af MIPS , ARM (inklusive Thumb ) og SuperH .
PE's hovedkonkurrenter er ELF (bruges på Linux og de fleste andre versioner af Unix ) og Mach-O (bruges på Mac OS X ).
Med fremkomsten af Windows NT 3.1 -operativsystemet skiftede Microsoft til PE-formatet. Alle senere versioner af Windows, inklusive Windows 95/98/ME, understøtter dette format. Formatet bibeholdt begrænset understøttelse af det eksisterende ( MZ ) for at bygge bro mellem DOS-baserede systemer og NT-systemer. For eksempel inkluderer PE/COFF-headers stadig det eksekverbare MS-DOS-program, som som standard er en stub , der viser en simpel besked "This program cannot be run in DOS mode" - "Dette program kan ikke køres i DOS-tilstand" (eller lignende). PE fortsætter med at betjene den skiftende Windows-platform. Nogle udvidelser inkluderer PE.NET-formatet (se nedenfor), en 64-bit version kaldet PE32+ (nogle gange PE+) og en specifikation for Windows CE.
De første 2 bytes af PE-filen indeholder signaturen 0x4D 0x5A - "MZ" (som efterfølgeren til MZ -formatet). Dernæst indeholder dobbeltordet ved offset 0x3C adressen på PE-headeren. Sidstnævnte starter med signaturen 0x50 0x45 - "PE".
En PE-fil består af adskillige overskrifter og sektioner, der fortæller den dynamiske linker, hvordan filen skal kortlægges i hukommelsen. Det eksekverbare billede består af flere forskellige områder (sektioner), som hver især kræver forskellige hukommelsesadgangsrettigheder; derfor skal begyndelsen af hvert afsnit justeres til sidegrænsen. Eksempelvis vises typisk .text-sektionen, som indeholder programkoden, som eksekverbar/skrivebeskyttet, og .data-sektionen, som indeholder globale variabler, vises som ikke-eksekverbar/read-write. Men for ikke at spilde plads på harddisken, er de forskellige sektioner på den ikke justeret til sidegrænsen. En del af den dynamiske linkers opgave er at kortlægge hver sektion til hukommelsen separat og tildele de korrekte tilladelser til de resulterende områder som anvist af overskrifterne.
En velkendt sektion er Import Address Table (IAT), som bruges som opslagstabel, når en applikation kalder en funktion fra et andet modul. Dette kan gøres både i form af import efter funktion ordinal (ordinal) og import efter funktionsnavn. Da det kompilerede program ikke kender placeringen af de biblioteker, det afhænger af, skal det springe indirekte, når der foretages et API-kald. Når den dynamiske linker indlæser moduler og kombinerer dem, skriver den de faktiske adresser ind i IAT-området, så de peger på hukommelsesplaceringerne for de tilsvarende biblioteksfunktioner. Selvom dette tilføjer et ekstra trin i modulet, hvilket resulterer i en ydeevnestraf, giver det en vigtig fordel: antallet af hukommelsessider, der skal kopieres af indlæseren ved skrivning, er minimeret, hvilket resulterer i besparelser i hukommelse og disk I/O-tid . Hvis compileren ved på forhånd, at opkaldet vil være inter-modul (via dllimport-attributten), så kan den producere mere optimeret kode, der blot resulterer i den indirekte opkaldsopkode .
Eksportadressetabellen (EAT - Export Address Table) er nødvendig for at ét modul (normalt et dynamisk indlæst bibliotek ) kan fortælle andre moduler, hvilke funktioner de kan importere fra det, og på hvilke adresser sidstnævnte er placeret.
PE-filer indeholder ikke positionsuafhængig kode . I stedet kompileres de til en foretrukken baseadresse , og alle adresser genereret af compileren/linkeren er faste på forhånd. Hvis PE-filen ikke kan indlæses på dens foretrukne adresse (fordi den allerede er taget af noget andet), vil operativsystemet genbase den. Dette inkluderer genberegning af hver absolut adresse og ændring af koden for at bruge de nye værdier. Downloaderen gør dette ved at sammenligne de foretrukne og faktiske downloadadresser og beregne forskellen . Derefter, for at opnå en ny hukommelsescelleadresse, føjes denne forskel til den foretrukne adresse. Baseflytningsadresserne gemmes på en liste og tilføjes til en eksisterende hukommelsesplacering efter behov. Den resulterende kode er nu adskilt fra processen og deles ikke længere, så mange af de hukommelsesbesparende fordele ved dynamisk indlæste biblioteker går tabt på denne måde. Denne metode sænker også modulbelastningen betydeligt. Af denne grund bør rebaser undgås, hvor det er muligt; for eksempel har biblioteker leveret af Microsoft forudberegnet ikke-overlappende basisadresser. I mangel af en rebase har PE-filer fordelen af meget effektiv kode, men i nærvær af en rebase kan overheaden i hukommelsesbrug være betydelig. Dette adskiller PE-formatet fra ELF , som bruger fuldstændig positionsuafhængig kode og en global offset-tabel, der ofrer runtime til fordel for spild af hukommelse.
Microsofts .NET-platform har udvidet PE-formatet med funktioner, der understøtter Common Language Runtime (CLR). Tilføjelser inkluderer en CLR-header og en CLR-datasektion. Efter at binæren er indlæst, får OS-indlæseren CLR til at blive udført via et link i PE/COFF-importtabellen. CLR'en indlæser derefter CLR-headeren og datasektionerne.
CLR-datasektionen indeholder to vigtige segmenter: metadatasegmentet og IL-kodesegmentet (mellemsprog):
PE-formatet bruges også af ReactOS , da ReactOS er designet til at være binært kompatibelt med Windows på kodeniveau. Derudover har det historisk været brugt af mange andre operativsystemer, inklusive SkyOS og BeOS R3. Både SkyOS og BeOS skiftede dog til sidst til ELF-formatet.
Fordi Mono-udviklingsplatformen har til hensigt at være binærkompatibel med Microsoft .NET , bruger den samme PE-format som Microsoft-implementeringen.
På x86 -platformen på Unix-lignende operativsystemer kan nogle Windows-binære filer (i PE-format) udføres ved hjælp af Wine . HX DOS Extender bruger også PE-formatet til native 32-bit DOS-binære filer, og kan køre eksisterende Windows-binære filer på DOS til en vis grad og dermed fungere som Wine for DOS.
Mac OS X 10.5 har evnen til at indlæse og fortolke PE-filer, men de er ikke binært kompatible med Windows.
| Eksekverbare filformater ( sammenligning ) | |
|---|---|
| Unix | |
| Windows , DOS og OS/2 | |
| Andet | |
| OS/2 - komponenter og API'er | |
|---|---|
| Hoved | |
Management Services | |
| Spil |
|
| OS kerne | |
| Filsystemer | |
| Grafik undersystem |
|
| Objektmodel | SOM
|
| Kompatibilitet |
|