Portable Executable (PE) is a file format for native executable code on 32-bit and 64-bit Windows operating systems, as well as in UEFI environments. It is used for native executables (, ), dynamic link libraries (, ), system drivers (, ) and many other types of files. The PE format supports storing the data required to load and start an operating system process including references to dynamic link libraries, tables for importing and exporting application programming interface (API) functions, resource management data and thread-local storage (TLS) information.

According to the Unified Extensible Firmware Interface (UEFI) specification, the PE format is also the accepted standard for executables in EFI environments. On Windows NT systems, it currently supports a range of instruction sets, including IA-32, x86-64 (AMD64/Intel 64), IA-64, ARM and ARM64. Before the advent of Windows 2000, Windows NT (and by extension the PE format) also supported MIPS, Alpha, and PowerPC architectures. Moreover, thanks to its use in Windows CE, PE has maintained compatibility with several MIPS, ARM (including Thumb), and SuperH variants.

Functionally, the PE format is similar to other platform-specific executable formats, such as the ELF format used in Linux and most Unix-like systems, and the Mach-O format found in macOS and iOS.

History

Microsoft first introduced the PE format with Windows NT 3.1, replacing the older 16-bit New Executable (NE) format. Soon after, Windows 95, 98, ME, and the Win32s extension for Windows 3.1x, all adopted the PE structure. Each PE file includes a DOS executable header, which generally displays the message "This program cannot be run in DOS mode". However, this DOS section can be replaced by a fully functional DOS program, as demonstrated in the Windows 98 SE installer. Developers can add such a program using the <code>/STUB</code> switch with Microsoft's linker, effectively creating a fat binary.

Over time, the PE format has grown with the Windows platform. Notable extensions include the .NET PE format for managed code, PE32+ for 64-bit address space support, and a specialized version for Windows CE.

To determine whether a PE file is intended for 32-bit or 64-bit architectures, one can examine the Machine field in the IMAGE_FILE_HEADER. Common machine values are <code>0x014c</code> for 32-bit Intel processors and <code>0x8664</code> for x64 processors. Additionally, the Magic field in the <code>IMAGE_OPTIONAL_HEADER</code> reveals whether addresses are 32-bit or 64-bit. A value of <code>0x10B</code> indicates a 32-bit (PE32) file, while <code>0x20B</code> indicates a 64-bit (PE32+) file.

Technical details

Layout

thumb|Structure of a Portable Executable 32 bit

A PE file consists of several headers and sections that instruct the dynamic linker on how to map the file into memory. An executable image consists of several different regions, each requiring different memory protection attributes. To ensure proper alignment, the start of each section must align to a page boundary. For instance, the .text section, which contains program code, is typically mapped as an execute/read-only. Conversely, the .data section, which holds global variables, is mapped as no-execute/read write. However, to conserve space, sections are not aligned on disk in this manner. The dynamic linker maps each section to memory individually and assigns the correct permissions based on the information in the headers.

Import table

The import address table (IAT) is used as a lookup table when the application calls a function in a different module. The imports can be specified by ordinal or by name. Because a compiled program cannot know the memory locations of its dependent libraries beforehand, an indirect jump is necessary for API calls. As the dynamic linker holds modules and resolves dependencies, it populates the IAT slots with actual addresses of the corresponding library functions. Although this adds an extra jump, incurring a performance penalty compared to intermodular calls, it minimizes the number of memory pages that require copy-on-write changes, thus conserving memory and disk I/O. If a call is known to be intermodular beforehand (if indicated by a dllimport attribute), the compiler can generate optimized code with a simple indirect call opcode.

UEFI and UEFI firmware use PE files, as well as the platform related ABI and calling convention (x64 ABI for typical PC devices) for applications.

See also

References

  • PE Format (latest online document, changes in time)
  • Microsoft Portable Executable and Common Object File Format Specification. Revision 11.0, Jan 2017; Revision 10.0, Jun 2016; Revision 8.3, Feb 2013; Revision 8.2, Sep 2010; Revision 8.1, Feb 2008; Revision 8.0, May 2006; Revision 6.0, Feb 1999; Revision 5.0, Oct 1997; Revision 4.1, Aug 1994; Revision 4.0, Sep 1993
  • Tool Interface Standard (TIS) Formats Specifications for Windows Version 1.0 (Intel Order Number 241597, TIS Committee, Feb 1993)
  • Portable Executable Format (Micheal J. O'Leary, Microsoft Developer Support)
  • Peering Inside the PE: A Tour of the Win32 Portable Executable File Format. Matt Pietrek, Microsoft Systems Journal, March 1994
  • An In-Depth Look into the Win32 Portable Executable File Format. Matt Pietrek, MSDN Magazine. Part I, February 2002; Part II, March 2002
  • The .NET File Format by Daniel Pistelli
  • Ero Carrera's blog describing the PE header and how to walk through
  • PE Internals provides an easy way to learn the Portable Executable File Format
  • PE Explorer