Жұмыс атқарылатын файлдың PE форматы

File format

The Portable Executable (PE) format is a file format for executables, object code, DLLs and others used in 32 bit and 64 bit versions of Windows operating systems, and in UEFI environments. The PE format is a data structure that encapsulates the information necessary for the Windows OS loader to manage the wrapped executable code. This includes dynamic library references for linking, API export and import tables, resource management data and thread local storage (TLS) data. On NT operating systems, the PE format is used for EXE, DLL, SYS (device driver), MUI and other file types. The Unified Extensible Firmware Interface (UEFI) specification states that PE is the standard executable format in EFI environments. On Windows NT operating systems, PE currently supports the IA 32, x86 64 (AMD64/Intel 64), IA 64, ARM and ARM64 instruction set architectures (ISAs). Prior to Windows 2000, Windows NT (and thus PE) supported the MIPS, Alpha, and PowerPC ISAs. Because PE is used on Windows CE, it continues to support several variants of the MIPS, ARM (including Thumb), and SuperH ISAs. Analogous formats to PE are ELF (used in Linux and most other versions of Unix) and Mach O (used in macOS and iOS).

Microsoft migrated to the PE format from the 16 bit NE formats with the introduction of the Windows NT 3.1 operating system. All later versions of Windows, including Windows 95/98/ME and the Win32s addition to Windows 3.1x, support the file structure. The format has retained limited legacy support to bridge the gap between DOS based and NT systems. For example, PE/COFF headers still include a DOS executable program, which is by default a DOS stub that displays a message like "This program cannot be run in DOS mode" (or similar), though it can be a full fledged DOS version of the program (a later notable case being the Windows 98 SE installer). This constitutes a form of fat binary. PE also continues to serve the changing Windows platform. Some extensions include the NET PE format (see below), a version with 64 bit address space support called PE32+, and a specification for Windows CE.

A PE file consists of a number of headers and sections that tell the dynamic linker how to map the file into memory. An executable image consists of several different regions, each of which requires different memory protection; so the start of each section must be aligned to a page boundary. For instance, typically the text section (which holds program code) is mapped as execute/read only, and the data section (holding global variables) is mapped as no execute/read write. However, to avoid wasting space, the different sections are not page aligned on disk. Part of the job of the dynamic linker is to map each section to memory individually and assign the correct permissions to the resulting regions, according to the instructions found in the headers.

One section of note is the import address table (IAT), which is used as a lookup table when the application is calling a function in a different module. It can be in the form of both import by ordinal and import by name. Because a compiled program cannot know the memory location of the libraries it depends upon, an indirect jump is required whenever an API call is made. As the dynamic linker loads modules and joins them together, it writes actual addresses into the IAT slots, so that they point to the memory locations of the corresponding library functions. Though this adds an extra jump over the cost of an intra module call resulting in a performance penalty, it provides a key benefit: The number of memory pages that need to be copy on write changed by the loader is minimized, saving memory and disk I/O time. If the compiler knows ahead of time that a call will be inter module (via a dllimport attribute) it can produce more optimized code that simply results in an indirect call opcode. entry in the PE header's data directory. IMAGE COR20 HEADER strongly resembles PE's optional header, essentially playing its role for the CLR loader. Mac OS X 10.5 has the ability to load and parse PE files, but is not binary compatible with Windows. UEFI and EFI firmware use Portable Executable files as well as the Windows ABI x64 calling convention for applications.