Misplaced Pages

#809190

23-755: 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

46-423: A PE32+ file. A PE file consists of a number of headers and sections that inform a dynamic linker about 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

69-440: A call will be inter-module (via a dllimport attribute) it can produce more optimized code that simply results in an indirect call opcode . PE files normally do not contain position-independent code . Instead they are compiled to a preferred base address , and all addresses emitted by the compiler/linker are fixed ahead of time. If a PE file cannot be loaded at its preferred address (because it's already taken by something else),

92-418: A segment in protected mode , and the translation of segmented addresses to 32-bit linear addresses. The designers took the opportunity to make other improvements as well. Some of the most significant changes (relative to the 16-bit 286 instruction set) are: Rebasing In computing, rebasing is the process of modifying data based on one reference to another. It can be one of the following: Rebasing

115-777: Is also used by ReactOS , as ReactOS is intended to be binary-compatible with Windows. It has also historically been used by a number of other operating systems, including SkyOS and BeOS R3. However, both SkyOS and BeOS eventually moved to ELF . As the Mono development platform intends to be binary compatible with the Microsoft .NET Framework , it uses the same PE format as the Microsoft implementation. The same goes for Microsoft's own cross-platform .NET Core . On x86 (-64) Unix-like operating systems, Windows binaries (in PE format) can be executed with Wine . The HX DOS Extender also uses

138-513: 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). Microsoft's linker has a /STUB switch to attach one. This constitutes a form of fat binary . PE also continues to serve the changing Windows platform. Some extensions include

161-470: Is now private to the process and no longer shareable , so many of the memory saving benefits of DLLs are lost in this scenario. It also slows down loading of the module significantly. For this reason rebasing is to be avoided wherever possible, and the DLLs shipped by Microsoft have base addresses pre-computed so as not to overlap. In the no rebase case PE therefore has the advantage of very efficient code, but in

184-553: Is still sometimes referred to as the "i386" architecture. In some other contexts, certain iterations of the IA-32 ISA are sometimes labelled i486 , i586 and i686 , referring to the instruction supersets offered by the 80486 , the P5 and the P6 microarchitectures respectively. These updates offered numerous additions alongside the base IA-32 set including floating-point capabilities and

207-400: Is the 32-bit version of the x86 instruction set architecture , designed by Intel and first implemented in the 80386 microprocessor in 1985. IA-32 is the first incarnation of x86 that supports 32-bit computing; as a result, the "IA-32" term may be used as a metonym to refer to all x86 versions that support 32-bit computing. Within various programming language directives, IA-32

230-434: Is the process of creating a shared library image in such a way that it is guaranteed to use virtual memory without conflicting with any other shared libraries loadable in the system. IBM VM/370 discontinuous saved segments (DCSS) were an early example of this technique, though not called rebasing . The technique is used extensively on Win32 platforms to avoid the overhead of address relocation of system DLLs by

253-407: 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

SECTION 10

#1732787230810

276-431: 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

299-526: The Debian Linux distribution. In spite of IA-32's name (and causing some potential confusion), the 64-bit evolution of x86 that originated out of AMD would not be known as "IA-64", that name instead belonging to Intel's Itanium architecture . The primary defining characteristic of IA-32 is the availability of 32-bit general-purpose processor registers (for example, EAX and EBX), 32-bit integer arithmetic and logical operations, 32-bit offsets within

322-512: The MMX extensions . Intel was historically the largest manufacturer of IA-32 processors, with the second biggest supplier having been AMD . During the 1990s, VIA , Transmeta and other chip manufacturers also produced IA-32 compatible processors (e.g. WinChip ). In the modern era, Intel still produced IA-32 processors under the Intel Quark microcontroller platform until 2019; however, since

345-663: The .NET PE format, a version with 64-bit address space support called PE32+, and a specification for Windows CE. Whether the executable code is 32- or 64-bit can be found by checking the Machine field in the IMAGE_FILE_HEADER. Whether addresses in the executable are 32- or 64-bit can be found by checking the Magic field in the IMAGE_OPTIONAL_HEADER. 10B 16 indicates a PE32 file, whereas 20B 16 indicates

368-512: The 2000s, the majority of manufacturers (Intel included) moved almost exclusively to implementing CPUs based on the 64-bit variant of x86, x86-64 . x86-64, by specification, offers legacy operating modes that operate on the IA-32 ISA for backwards compatibility. Even given the contemporary prevalence of x86-64, as of today, IA-32 protected mode versions of many modern operating systems are still maintained, e.g. Microsoft Windows (until Windows 10 ), Windows Server (until Windows Server 2008 ) and

391-536: The CLR loader. The CLR-related data, including the root structure itself, is typically contained in the common code section, .text . It is composed of a few directories: metadata, embedded resources, strong names and a few for native-code interoperability. Metadata directory is a set of tables that list all the distinct .NET entities in the assembly, including types, methods, fields, constants, events, as well as references between them and to other assemblies. The PE format

414-448: 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

437-557: The PE format for native DOS 32-bit binaries, plus it can, to some degree, execute existing Windows binaries in DOS, thus acting like an equivalent of Wine for DOS. 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 . IA-32 IA-32 (short for " Intel Architecture, 32-bit ", commonly called i386 )

460-523: 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

483-459: The operating system will rebase it. This involves recalculating every absolute address and modifying the code to use the new values. The loader does this by comparing the preferred and actual load addresses, and calculating a delta value. This is then added to the preferred address to come up with the new address of the memory location. Base relocations are stored in a list and added, as needed, to an existing memory location. The resulting code

SECTION 20

#1732787230810

506-467: The presence of rebasing the memory usage hit can be expensive. This contrasts with ELF where fully position-independent code is usually preferred to load-time relocation, thus trading off execution time in favor of lower memory usage. In a .NET executable, the PE code section contains a stub that invokes the CLR virtual machine startup entry, _CorExeMain or _CorDllMain in mscoree.dll , much like it

529-553: Was in Visual Basic executables. The virtual machine then makes use of .NET metadata present, the root of which, IMAGE_COR20_HEADER (also called "CLR header") is pointed to by IMAGE_DIRECTORY_ENTRY_COMHEADER (the entry was previously used for COM+ metadata in COM+ applications, hence the name) entry in the PE header's data directory. IMAGE_COR20_HEADER strongly resembles PE's optional header, essentially playing its role for

#809190