Executable Portable

Infotaula de format de fitxerExecutable Portable
Tipusformat de fitxer executable associat a l'extensió .exe Modifica el valor a Wikidata
Extensióexe, dll, sys, scr, drv, efi, acm, ax, mui i tsp Modifica el valor a Wikidata
MIMEapplication/vnd.microsoft.portable-executable i application/efi Modifica el valor a Wikidata
Magic number4D5A i 4D5A*50450000 Modifica el valor a Wikidata
Més informació
Stack ExchangeEtiqueta i Etiqueta Modifica el valor a Wikidata
Wiki del format de fitxerPortable_Executable Modifica el valor a Wikidata
PRONOMx-fmt/411 Modifica el valor a Wikidata

El format Portable Executable (PE) és un format de fitxer per executables, codi d’objecte, DLL i altres que s’utilitzen en versions de 32 i 64 bits dels sistemes operatius Windows. El format PE és una estructura de dades que encapsula la informació necessària perquè el carregador del sistema operatiu Windows gestioni el codi executable ajustat. Això inclou referències de biblioteca dinàmica per a enllaços, taules d’exportació i importació d’API, dades de gestió de recursos i dades d’emmagatzematge local de fils (TLS). Als sistemes operatius NT, el format PE s'utilitza per a EXE, DLL, SYS (controlador de dispositiu), MUI i altres tipus de fitxers. L' especificació de la Unified Extensible Firmware Interface (UEFI) indica que PE és el format executable estàndard en entorns EFI.[1]

Als sistemes operatius Windows NT, PE actualment admet les arquitectures de conjunts d’ instruccions (ISA) x86-32, x86-64 (AMD64 / Intel 64), IA-64, ARM i ARM64. Abans del Windows 2000, Windows NT (i, per tant, PE) suportava els ISA MIPS, Alpha i PowerPC. Com que el PE s'utilitza a Windows CE, continua admetent diverses variants dels ISA MIPS, ARM (inclòs Thumb) i SuperH.[2]

Els formats anàlegs a PE són ELF (utilitzat a Linux i la majoria de versions d'altres Unix) i Mach-O (utilitzat a macOS i iOS).

Història

[modifica]

Microsoft va migrar al format PE des dels formats NE de 16 bits amb la introducció del sistema operatiu Windows NT 3.1. Totes les versions posteriors de Windows, inclòs el Windows 95/98 / ME i l’ addició Win32s al Windows 3.1x, admeten l'estructura de fitxers. El format ha mantingut un suport heretat limitat per salvar la bretxa entre els sistemes basats en DOS i els sistemes NT. Per exemple, les capçaleres PE / COFF encara inclouen un programa executable de DOS, que per defecte és un registre DOS que mostra un missatge com "Aquest programa no es pot executar en mode DOS" (o similar), tot i que pot ser un DOS complet. versió del programa (un cas notable posterior és l’instal·lador de Windows 98 SE).[3] Això constitueix una forma de greix binari. PE també continua servint la canviant plataforma de Windows. Algunes extensions inclouen el fitxer. Format NET PE (vegeu més avall), una versió de 64 bits anomenada PE32 + (de vegades PE +) i una especificació per a Windows CE.

Detalls tècnics

[modifica]

Disseny

[modifica]
Estructura d’un executable portàtil de 32 bits

Un fitxer PE consta d'una sèrie de capçaleres i seccions que indiquen a l'enllaçador dinàmic com assignar el fitxer a la memòria. Una imatge executable consta de diverses regions diferents, cadascuna de les quals requereix una protecció de memòria diferent; de manera que l’inici de cada secció ha d’estar alineat amb un límit de pàgina.[4] Per exemple, normalment la secció .text (que conté el codi del programa) s’assigna com execute / readonly, i la secció .data (que conté variables globals) s’assigna com no-execute / readwrite. Tot i això, per evitar malgastar espai, les diferents seccions no estan alineades a la pàgina del disc. Una part del treball de l'enllaçador dinàmic consisteix a assignar cada secció a la memòria individualment i assignar els permisos correctes a les regions resultants, segons les instruccions que es troben a les capçaleres.[5]

Taula d'importació

[modifica]

Una secció destacable és la taula d’adreces d’importació (IAT), que s’utilitza com a taula de cerca quan l’aplicació crida a una funció en un mòdul diferent. Pot ser tant en forma d’ importació per ordinal com d’importació per nom. Com que un programa compilat no pot conèixer la ubicació de memòria de les biblioteques de què depèn, es requereix un salt indirecte cada vegada que es fa una crida a l'API. A mesura que l'enllaçador dinàmic carrega mòduls i els uneix, escriu adreces reals a les ranures IAT, de manera que assenyalin les ubicacions de memòria de les funcions de biblioteca corresponents. Tot i que això afegeix un salt addicional sobre el cost d'una crida intra-mòdul que comporta una penalització de rendiment, proporciona un avantatge clau: es minimitza el nombre de pàgines de memòria que el carregador ha de canviar de còpia en escriptura, estalviant memòria. i el temps d'E / S del disc. Si el compilador sap amb antelació que una crida serà intermòdula (mitjançant un atribut dllimport), pot produir un codi més optimitzat que simplement doni lloc a un codi de crida indirecte.[5]

Reubicacions

[modifica]

Els fitxers PE normalment no contenen codi independent de la posició. En lloc d'això, es compilen a una adreça base preferida i totes les adreces emeses pel compilador / enllaçador es fixen amb antelació. Si no es pot carregar un fitxer PE a la seva adreça preferida (perquè ja ho ha pres una altra cosa), el sistema operatiu el tornarà a canviar. Això implica recalcular totes les adreces absolutes i modificar el codi per utilitzar els nous valors. El carregador ho fa comparant les adreces de càrrega reals i preferides i calculant un valor delta. A continuació, s’afegeix a l’adreça preferida per obtenir la nova adreça de la ubicació de memòria. Les reubicacions bàsiques s’emmagatzemen en una llista i s’afegeixen, segons sigui necessari, a una ubicació de memòria existent. El codi resultant ara és privat per al procés i ja no es pot compartir, de manera que molts dels avantatges d'estalvi de memòria de les DLL es perden en aquest escenari. També alenteix la càrrega del mòdul de manera significativa. Per aquest motiu, s'ha d'evitar el redimensionament sempre que sigui possible i les DLL enviades per Microsoft tenen adreces base pre-calculades per no superposar-se. Per tant, en el cas de no rebase, el PE té l'avantatge d'un codi molt eficient, però en cas de rebasing, l'èxit de la memòria pot resultar car. Això contrasta amb ELF, que utilitza un codi totalment independent de la posició i una taula global de compensació, que canvia el temps d’execució en favor d’un menor ús de memòria..

. NET, metadades i format PE

[modifica]

En un. NET, la secció de codi PE conté un capçal que invoca l'entrada d’inici de la màquina virtual CLR _CorExeMain o _CorDllMain a mscoree.dll, de la mateixa manera que es feia als executables de Visual Basic. La màquina virtual fa ús de. Hi ha metadades NET presents, l’arrel de les quals és IMAGE_COR20_HEADER (també anomenada "capçalera CLR") amb l'entrada IMAGE_DIRECTORY_ENTRY_COMHEADER [6] al directori de dades de la capçalera PE. IMAGE_COR20_HEADER s’assembla molt a la capçalera opcional de PE, essencialment jugant el seu paper per al carregador CLR.[2]

Les dades relacionades amb CLR, inclosa la pròpia estructura arrel, normalment es contenen a la secció de codi comú, .text. Està compost per uns quants directoris: metadades, recursos incrustats, noms forts i alguns per a la interoperabilitat del codi natiu. El directori de metadades és un conjunt de taules que enumeren tots els diferents. Entitats NET de l'assamblatge, inclosos tipus, mètodes, camps, constants, esdeveniments, així com referències entre elles i a altres assamblatges.

Ús en altres sistemes operatius

[modifica]

ReactOS també utilitza el format PE, ja que ReactOS està pensat per ser compatible amb Windows amb binaris. Històricament també ha estat utilitzat per altres sistemes operatius, inclosos SkyOS i BeOS R3. Tanmateix, tant SkyOS com BeOS finalment es van traslladar a ELF .

Com que la plataforma de desenvolupament Mono té la intenció de ser binària compatible amb Microsoft . NET Framework, utilitza el mateix format PE que la implementació de Microsoft. El mateix passa amb la plataforma multiplataforma de Microsoft. NET Core .

En sistemes operatius x86 (-64) semblants a Unix, els binaris de Windows (en format PE) es poden executar amb Wine. L' extensor HX DOS també utilitza el format PE per a binaris natius de 32 bits DOS, a més pot, fins a cert punt, executar binaris Windows existents en DOS, actuant així com un equivalent de Wine per DOS.

A Linux IA-32 i x86-64 també es poden executar DLL de Windows a la biblioteca de càrrega.[7]

Mac OS X 10.5 té la capacitat de carregar i analitzar fitxers PE, però no és compatible amb Windows.[8]

El microprogramari UEFI i EFI utilitzen fitxers executables portàtils, així com la convenció de crides de Windows ABI x64 per a aplicacions.

Referències

[modifica]
  1. ↑ «UEFI Specification, version 2.8B»., a note on p.15, states that "this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode."
  2. ↑ 2,0 2,1 «PE Format (Windows)». [Consulta: 21 octubre 2017].
  3. ↑ E.g.
  4. ↑ «The Portable Executable File From Top to Bottom». Arxivat de l'original el 2017-10-20. [Consulta: 21 octubre 2017].
  5. ↑ 5,0 5,1 «Peering Inside the PE: A Tour of the Win32 Portable Executable File». [Consulta: 21 octubre 2017].
  6. ↑ The entry was previously used for COM+ metadata in COM+ applications, hence the name
  7. ↑ «GitHub - taviso/Loadlibrary: Porting Windows Dynamic Link Libraries to Linux».
  8. ↑ Chartier, David. «Uncovered: Evidence that Mac OS X could run Windows apps soon». Ars Technica, 30-11-2007. [Consulta: 3 desembre 2007].

Bibliografia

[modifica]

Enllaços externs

[modifica]