Exécutable portable - Portable Executable

À ne pas confondre avec Application portable .
Exécutable portable
Extension de nom de fichier
.acm, .ax, .cpl, .dll, .drv, .efi, .exe, .mui, .ocx, .scr, .sys,.tsp
Type de média Internet
application/vnd.microsoft.portable-executable
Développé par Actuellement : Microsoft
Type de format Binaire , exécutable , objet , bibliothèques partagées
Prolongé de DOS MZ exécutable
COFF

Le format Portable Executable (PE) est un format de fichier pour les exécutables , le code objet , les DLL et autres utilisés dans les versions 32 bits et 64 bits des systèmes d' exploitation Windows . Le format PE est une structure de données qui encapsule les informations nécessaires au chargeur du système d'exploitation Windows pour gérer le code exécutable encapsulé . Cela inclut les références de bibliothèque dynamique pour la liaison , les tables d'exportation et d'importation d' API , les données de gestion des ressources et les données de stockage local de thread (TLS). Sur les systèmes d'exploitation NT , le format PE est utilisé pour EXE , DLL , SYS ( pilote de périphérique ), MUI et autres types de fichiers. La spécification UEFI (Unified Extensible Firmware Interface) indique que PE est le format exécutable standard dans les environnements EFI.

Sur les systèmes d'exploitation Windows NT, PE prend actuellement en charge les architectures de jeu d'instructions x86-32 , x86-64 (AMD64/Intel 64), IA-64 , ARM et ARM64 (ISA). Avant Windows 2000 , Windows NT (et donc PE) prenait en charge les ISA MIPS , Alpha et PowerPC . Étant donné que PE est utilisé sur Windows CE , il continue de prendre en charge plusieurs variantes des ISA MIPS, ARM (y compris Thumb ) et SuperH .

Les formats analogues à PE sont ELF (utilisé sous Linux et la plupart des autres versions d' Unix ) et Mach-O (utilisé sous macOS et iOS ).

Histoire

Microsoft a migré vers le format PE à partir des formats NE 16 bits avec l'introduction du système d'exploitation Windows NT 3.1 . Toutes les versions ultérieures de Windows, y compris Windows 95/98/ME et l' ajout de Win32s à Windows 3.1x, prennent en charge la structure de fichiers. Le format a conservé une prise en charge héritée limitée pour combler le fossé entre les systèmes basés sur DOS et NT. Par exemple, les en-têtes PE/COFF incluent toujours un programme exécutable DOS , qui est par défaut un stub DOS qui affiche un message tel que "Ce programme ne peut pas être exécuté en mode DOS" (ou similaire), bien qu'il puisse s'agir d'un DOS à part entière version du programme (un cas notable ultérieur étant le programme d'installation de Windows 98 SE). Cela constitue une forme de gros binaire . PE continue également de servir la plate-forme Windows en évolution. Certaines extensions incluent le format .NET PE (voir ci-dessous), une version 64 bits appelée PE32+ (parfois PE+) et une spécification pour Windows CE.

Détails techniques

Disposition

Image
Structure d'un exécutable portable 32 bits

Un fichier PE se compose d'un certain nombre d'en-têtes et de sections qui indiquent à l' éditeur de liens dynamiques comment mapper le fichier en mémoire. Une image exécutable se compose de plusieurs régions différentes, chacune nécessitant une protection de mémoire différente ; le début de chaque section doit donc être aligné sur une limite de page. Par exemple, généralement la section .text (qui contient le code du programme) est mappée en exécution/lecture seule, et la section .data (contenant les variables globales) est mappée en tant que non-exécution/lecture. Cependant, pour éviter de gaspiller de l'espace, les différentes sections ne sont pas alignées sur le disque. Une partie du travail de l'éditeur de liens dynamique consiste à mapper chaque section à la mémoire individuellement et à attribuer les autorisations correctes aux régions résultantes, selon les instructions trouvées dans les en-têtes.

Tableau d'importation

Une section à noter est la table d'adresses d'importation (IAT), qui est utilisée comme table de recherche lorsque l'application appelle une fonction dans un module différent. Il peut être à la fois sous forme d' importation par ordinal et d'importation par nom . Parce qu'un programme compilé ne peut pas connaître l'emplacement mémoire des bibliothèques dont il dépend, un saut indirect est requis chaque fois qu'un appel API est effectué. Au fur et à mesure que l'éditeur de liens dynamique charge les modules et les relie, il écrit les adresses réelles dans les emplacements IAT, de sorte qu'elles pointent vers les emplacements mémoire des fonctions de bibliothèque correspondantes. Bien que cela ajoute un saut supplémentaire par rapport au coût d'un appel intra-module entraînant une pénalité de performance, cela offre un avantage clé : le nombre de pages de mémoire qui doivent être modifiées par copie sur écriture par le chargeur est minimisé, économisant ainsi de la mémoire et le temps d'E/S du disque. Si le compilateur sait à l'avance qu'un appel sera inter-module (via un attribut dllimport), il peut produire un code plus optimisé qui résulte simplement en un appel indirect opcode .

Déménagements

Les fichiers PE ne contiennent normalement pas de code indépendant de la position . Au lieu de cela, elles sont compilées vers une adresse de base préférée et toutes les adresses émises par le compilateur/éditeur de liens sont fixées à l'avance. Si un fichier PE ne peut pas être chargé à son adresse préférée (parce qu'il est déjà pris par autre chose), le système d'exploitation le rebasera . Cela implique de recalculer chaque adresse absolue et de modifier le code pour utiliser les nouvelles valeurs. Pour ce faire, le chargeur compare les adresses de chargement préférées et réelles et calcule une valeur delta . Celle-ci est ensuite ajoutée à l'adresse préférée pour obtenir la nouvelle adresse de l'emplacement mémoire. Les relocalisations de base sont stockées dans une liste et ajoutées, si nécessaire, à un emplacement mémoire existant. Le code résultant est désormais privé pour le processus et n'est plus partageable , de sorte que de nombreux avantages d'économie de mémoire des DLL sont perdus dans ce scénario. Cela ralentit également considérablement le chargement du module. Pour cette raison, le rebasage doit être évité dans la mesure du possible, et les DLL livrées par Microsoft ont des adresses de base pré-calculées afin de ne pas se chevaucher. Dans le cas sans rebase, PE a donc l'avantage d'un code très efficace, mais en présence d'un rebasage, l'utilisation de la mémoire peut être coûteuse. Cela contraste avec ELF qui utilise un code entièrement indépendant de la position et une table de décalage globale, qui compense le temps d'exécution en faveur d'une utilisation de mémoire plus faible.

.NET, métadonnées et format PE

Dans un exécutable .NET, la section de code PE contient un stub qui appelle l' entrée de démarrage de la machine virtuelle CLR , _CorExeMainou _CorDllMaindans mscoree.dll, un peu comme dans les exécutables Visual Basic . La machine virtuelle utilise alors les métadonnées .NET présentes, dont la racine IMAGE_COR20_HEADER(appelée aussi « en-tête CLR ») est pointée par IMAGE_DIRECTORY_ENTRY_COMHEADERentrée dans le répertoire de données de l'en-tête PE. IMAGE_COR20_HEADERressemble fortement à l'en-tête facultatif de PE, jouant essentiellement son rôle pour le chargeur CLR.

Les données liées au CLR, y compris la structure racine elle-même, sont généralement contenues dans la section de code commun, .text. Il est composé de quelques répertoires : métadonnées, ressources embarquées, noms forts et quelques-uns pour l'interopérabilité du code natif. Le répertoire de métadonnées est un ensemble de tables qui répertorient toutes les entités .NET distinctes de l'assembly, y compris les types, les méthodes, les champs, les constantes, les événements, ainsi que les références entre elles et vers d'autres assemblys.

Utilisation sur d'autres systèmes d'exploitation

Le format PE est également utilisé par ReactOS , car ReactOS est destiné à être compatible binaire avec Windows. Il a également été historiquement utilisé par un certain nombre d'autres systèmes d'exploitation, notamment SkyOS et BeOS R3. Cependant, SkyOS et BeOS sont finalement passés à ELF .

Comme la plate-forme de développement Mono se veut binaire compatible avec Microsoft .NET Framework , elle utilise le même format PE que l'implémentation Microsoft. Il en va de même pour le propre .NET Core multiplateforme de Microsoft .

Sur les systèmes d'exploitation de type Unix x86 (-64) , les binaires Windows (au format PE) peuvent être exécutés avec Wine . Le HX DOS Extender utilise également le format PE pour les binaires DOS 32 bits natifs, et il peut, dans une certaine mesure, exécuter les binaires Windows existants sous DOS, agissant ainsi comme un équivalent de Wine pour DOS.

Sur Linux IA-32 et x86-64, on peut également exécuter les DLL de Windows sous loadlibrary.

Mac OS X 10.5 a la capacité de charger et d'analyser des fichiers PE, mais n'est pas compatible binaire avec Windows.

Les micrologiciels UEFI et EFI utilisent des fichiers exécutables portables ainsi que la convention d'appel Windows ABI x64 pour les applications .

Voir également

Les références

Liens externes