This document specifies the structure of executable (image) files and object files under Microsoft Windows NT®. These files are referred to as Portable Executable (PE) and Common Object File Format (COFF) files respectively. The name "Portable Executable" refers to the fact that the format is not architecture-specific.
Certain concepts appear repeatedly throughout the specification and are described in the following table:
| Name | Description |
| Image file | Executable file: either a .EXE file or a DLL. An image file can be thought of as a "memory image." The term "image file" is usually used instead of "executable file," because the latter sometimes is taken to mean only a .EXE file. |
| Object file | A file given as input to the linker. The linker produces an image file, which in turn is used as input by the loader. The term "object file" does not necessarily imply any connection to object-oriented programming. |
| RVA | Relative Virtual Address. In an image file, an RVA is always the address of an item once loaded into memory, with the base address of the image file subtracted from it. The RVA of an item will almost always differ from its position within the file on disk (File Pointer). In an object file, an RVA is less meaningful because memory locations are not assigned. In this case, an RVA would be an address within a section (see below), to which a relocation is later applied during linking. For simplicity, compilers should just set the first RVA in each section to zero. |
| Virtual Address (VA) | Same as RVA (see above), except that the base address of the image file is not subtracted. The address is called a "Virtual Address" because Windows NT creates a distinct virtual address space for each process, independent of physical memory. For almost all purposes, a virtual address should be considered just an address. A virtual address is not as predictable as an RVA, because the loader might not load the image at its preferred location. |
| File pointer | Location of an item within the file itself, before being processed by the linker (in the case of object files) or the loader (in the case of image files). In other words, this is a position within the file as stored on disk. |
| Date/Time Stamp | Date/time stamps are used in a number of places in a PE/COFF file, and for different purposes. The format of each such stamp, however, is always the same: that used by the time functions in the C run-time library. |
| Section | A section is the basic unit of code or data within a PE/COFF file. In an object file, for example, all code can be combined within a single section, or (depending on compiler behavior) each function can occupy its own section. With more sections, there is more file overhead, but the linker is able to link in code more selectively. A section is vaguely similar to a segment in Intel® 8086 architecture. All the raw data in a section must be loaded contiguously. In addition, an image file can contain a number of sections, such as .tls or .reloc, that have special purposes. |
| Attribute Certificate | Attribute certificates are used to associate verifiable statements with an image. There are a number of different verifiable statements that can be associated with a file, but one of the most useful ones, and one that is easy to describe, is a statement by a software manufacturer indicating what the message digest of the image is expected to be. A message digest is similar to a checksum except that it is extremely difficult to forge, and, therefore it is very difficult to modify a file in such a way as to have the same message digest as the original file. The statement may be verified as being made by the manufacturer by use of public/private key cryptography schemes. This document does not go into details of attribute certificates other than to allow for their insertion into image files. |