| Hordozható futtatható | |
|---|---|
| Kiterjesztés | .exe, .dll, .ocx, .sys, .scr, .drv, .cpl, .efi, .acm, vagy .ax_.mui.tsp |
| MIME típusú | application/vnd.microsoft.portable-executable [1] és application/efi [2] |
| Formátum típusa | bináris , végrehajtható , objektum , dinamikus könyvtár |
| Médiafájlok a Wikimedia Commons oldalon | |
A Portable Executable ( PE , "hordozható futtatható") a Microsoft Windows operációs rendszer 32 és 64 bites verzióiban használt végrehajtható fájlok , objektumkód és dinamikus könyvtárak (DLL) formátuma . A PE formátum egy adatstruktúra, amely tartalmazza az összes információt, amelyre a PE betöltőnek szüksége van egy fájl memóriába való leképezéséhez. A végrehajtható kód hivatkozásokat tartalmaz a dinamikusan betöltött könyvtárak, API -exportálási és -importálási táblák , erőforrás-kezelési adatok, valamint a szálak helyi tárolási ( TLS ) adatainak összekapcsolásához . A Windows NT család operációs rendszereiben a PE formátumot használják az EXE , DLL , SYS (eszköz-illesztőprogramok) és más típusú futtatható fájlokhoz.
A PE a Unix COFF fájlformátumának módosított változata . A PE/COFF egy alternatív kifejezés a Windows fejlesztésben.
A Windows NT család operációs rendszerein a PE formátum jelenleg a következő utasításkészlet architektúrákat támogatja : IA-32 , IA-64 és x86-64 (AMD64/Intel64). A Windows 2000 előtt a Windows NT (és így a PE) támogatta a MIPS -t , az Alpha -t és a PowerPC -t . Mivel a PE-t a Windows CE -n használják , továbbra is támogatja a MIPS , az ARM (beleértve a Thumb ) és a SuperH számos változatát .
A PE fő versenytársai az ELF ( Linuxon és a Unix legtöbb más verzióján ) és a Mach-O ( Mac OS X -en használatos ).
A Windows NT 3.1 operációs rendszer megjelenésével a Microsoft áttért a PE formátumra. A Windows összes későbbi verziója, beleértve a Windows 95/98/ME-t is, támogatja ezt a formátumot. A formátum korlátozott mértékben támogatta a meglévőt ( MZ ), hogy áthidalja a szakadékot a DOS-alapú rendszerek és az NT rendszerek között. Például a PE/COFF fejlécek továbbra is tartalmazzák az MS-DOS végrehajtható programot, amely alapértelmezés szerint egy csonk , amely egy egyszerű üzenetet jelenít meg "This program cannot be run in DOS mode" - "Ez a program nem futtatható DOS módban" (vagy hasonló). A PE továbbra is a változó Windows platformot szolgálja ki. Egyes kiterjesztések közé tartozik a PE.NET formátum (lásd alább), a PE32+ nevű 64 bites verzió (néha PE+), valamint a Windows CE specifikációja.
A PE fájl első 2 bájtja tartalmazza a 0x4D 0x5A - "MZ" aláírást (az MZ formátum utódjaként). Ezután a 0x3C eltolásnál lévő dupla szó tartalmazza a PE fejléc címét. Ez utóbbi a 0x50 0x45 - "PE" aláírással kezdődik.
A PE-fájl több fejlécből és szakaszból áll, amelyek megmondják a dinamikus linkelőnek, hogyan kell leképezni a fájlt a memóriába. A végrehajtható kép több különböző területből (szakaszból) áll, amelyek mindegyikéhez különböző memória-hozzáférési jogok szükségesek; így minden szakasz elejét az oldalhatárhoz kell igazítani. Például jellemzően a programkódot tartalmazó .text szakasz futtatható/csak olvasható, a globális változókat tartalmazó .data rész pedig nem végrehajtható/írható-olvashatóként jelenik meg. Azonban annak érdekében, hogy ne pazaroljon helyet a merevlemezen, a különböző szakaszok nincsenek az oldalhatárhoz igazítva. A dinamikus linker feladatának része, hogy minden szakaszt külön-külön leképez a memóriába, és a megfelelő jogosultságokat rendelje hozzá a kapott területekhez a fejlécek utasításai szerint.
Az egyik jól ismert szakasz az Import Address Table (IAT), amelyet keresőtáblaként használnak, amikor egy alkalmazás meghív egy függvényt egy másik modulból. Ez megtehető a függvény sorszám szerinti importálása (sorrendi) és a függvénynév szerinti importálás formájában is. Mivel a lefordított program nem ismeri azon könyvtárak helyét, amelyektől függ, közvetett módon kell ugrania, amikor API-hívás történik. Amikor a dinamikus linker betölti a modulokat és kombinálja azokat, az aktuális címeket az IAT területre írja, hogy azok a megfelelő könyvtári függvények memóriahelyére mutassanak. Noha ez további lépést ad a modulon belül, ami teljesítménybüntetést eredményez, de kulcsfontosságú előnyt jelent: a betöltő által íráskor másolandó memóriaoldalak száma minimálisra csökken, ami memóriát és lemez I/O-időt takarít meg. . Ha a fordító előre tudja, hogy a hívás modulok közötti lesz (a dllimport attribútumon keresztül), akkor optimalizáltabb kódot tud előállítani, amely egyszerűen a közvetett hívási műveleti kódot eredményezi .
Az export címtáblázatra (EAT - Export Address Table) azért van szükség, hogy az egyik modul (általában dinamikusan betöltött könyvtár ) meg tudja mondani a többi modulnak, hogy milyen funkciókat importálhatnak belőle, és ez utóbbiak milyen címeken találhatók.
A PE fájlok nem tartalmaznak pozíciófüggetlen kódot . Ehelyett egy preferált alapcímre fordítják le őket, és a fordító/linker által generált összes címet előre rögzítik. Ha a PE-fájlt nem lehet betölteni a kívánt címre (mert azt már elfoglalta valami más), az operációs rendszer újra alapozza azt. Ez magában foglalja az egyes abszolút címek újraszámítását és a kód módosítását az új értékek használatához. A letöltő ezt úgy teszi meg, hogy összehasonlítja a preferált és a tényleges letöltési címeket, és kiszámítja a különbséget . Ezután egy új memóriacella cím megszerzéséhez ezt a különbséget hozzáadjuk a preferált címhez. Az alap áthelyezési címeket a rendszer egy listában tárolja, és szükség szerint hozzáadja egy meglévő memóriahelyhez. Az eredményül kapott kód immár elkülönül a folyamattól, és már nincs megosztva, így a dinamikusan betöltött könyvtárak memóriatakarékossági előnyei közül sok elveszik ilyen módon. Ez a módszer jelentősen lelassítja a modulok betöltését is. Emiatt lehetőség szerint kerülni kell az átbízásokat; például a Microsoft által biztosított könyvtárak előre kiszámított, nem átfedő alapcímekkel rendelkeznek. Rebase hiányában a PE fájlok előnye a nagyon hatékony kód, de rebase jelenlétében a memóriahasználat többletköltsége jelentős lehet. Ez különbözteti meg a PE formátumot az ELF -től , amely teljesen pozíciófüggetlen kódot és egy globális eltolási táblát használ, amely feláldozza a futási időt a memória pazarlása érdekében.
A Microsoft .NET platformja olyan funkciókkal bővítette a PE formátumot, amelyek támogatják a Common Language Runtime (CLR) rendszert. A kiegészítések közé tartozik egy CLR fejléc és egy CLR adatszakasz. A bináris betöltése után az operációs rendszer betöltője a CLR-t a PE/COFF importtáblázatban található hivatkozáson keresztül hajtja végre. A CLR ezután betölti a CLR fejlécet és adatszakaszokat.
A CLR adatrész két fontos szegmenst tartalmaz: a metaadat szegmenst és az intermediate language (IL) kódszegmenst:
A PE formátumot a ReactOS is használja , mivel a ReactOS kódszinten binárisan kompatibilis a Windows rendszerrel. Ezenkívül a történelem során számos más operációs rendszer is használta, köztük a SkyOS és a BeOS R3. Végül azonban mind a SkyOS, mind a BeOS átváltott az ELF formátumra.
Mivel a Mono fejlesztői platform binárisan kompatibilis a Microsoft .NET -tel, ugyanazt a PE formátumot használja, mint a Microsoft implementációja.
Az x86 platformon Unix-szerű operációs rendszereken néhány Windows bináris (PE formátumban) végrehajtható a Wine segítségével . A HX DOS Extender a PE formátumot is használja a natív 32 bites DOS binárisokhoz, és bizonyos mértékig képes futtatni a meglévő Windows binárisokat DOS-on, így úgy működik, mint a Wine for DOS.
A Mac OS X 10.5 képes PE fájlok betöltésére és értelmezésére, azonban ezek nem binárisan kompatibilisek a Windows rendszerrel.
| Futtatható fájlformátumok ( összehasonlítás ) | |
|---|---|
| Unix | |
| Windows , DOS és OS/2 | |
| Egyéb | |
| OS/2 összetevők és API -k | |
|---|---|
| Fő | |
Menedzsment szolgáltatások | |
| Játékok |
|
| OS kernel | |
| Fájlrendszerek | |
| Grafikai alrendszer |
|
| Objektummodell | SOM
|
| Kompatibilitás |
|