-\r
- PORTABLE EXECUTABLE FORMAT\r
-\r
- Author: Micheal J. O'Leary\r
-\r
-\r
- Preface\r
- \r
- This document was edited and released by Microsoft Developer\r
- Support. It describes the binary portable executable format for NT.\r
- The information is provided at this point because we feel it will\r
- make the work of application development easier. Unfortunately, the\r
- information in this document may change before the final release of\r
- Windows NT. Microsoft is NOT committing to stay with these formats\r
- by releasing this document. Questions or follow-ups for any of the\r
- information presented here should be posted to CompuServe MSWIN32\r
- forum, section 6.\r
- --Steve Firebaugh\r
- Microsoft Developer Support\r
- \r
- \r
-\r
-Contents\r
-\r
- 1. Overview\r
-\r
- 2. PE Header\r
-\r
- 3. Object Table\r
-\r
- 4. Image Pages\r
-\r
- 5. Exports\r
- 5.1 Export Directory Table\r
- 5.2 Export Address Table\r
- 5.3 Export Name Table Pointers\r
- 5.4 Export Ordinal Table\r
- 5.5 Export Name Table\r
-\r
- 6. Imports\r
- 6.1 Import Directory Table\r
- 6.2 Import Lookup Table\r
- 6.3 Hint-Name Table\r
- 6.4 Import Address Table\r
-\r
- 7. Thread Local Storage\r
- 7.1 Thread Local Storage Directory Table\r
- 7.2 Thread Local Storage CallBack Table\r
-\r
- 8. Resources\r
- 8.1 Resource Directory Table\r
- 8.2 Resource Example\r
-\r
- 9. Fixup Table\r
- 9.1 Fixup Block\r
-\r
- 10. Debug Information\r
- 10.1 Debug Directory\r
-\r
-\r
-\r
-1. Overview\r
-\r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ <ÄÄ¿ <ÄÄÄÄÄ Base of Image Header\r
- ³ DOS 2 Compatible ³ ³\r
- ³ EXE Header ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³\r
- ³ unused ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³\r
- ³ OEM Identifier ³ ³\r
- ³ OEM Info ³ ³\r
- ³ ³ ³ DOS 2.0 Section\r
- ³ Offset to ³ ³ (for DOS compatibility only)\r
- ³ PE Header ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³\r
- ³ DOS 2.0 Stub ³ ³\r
- ³ Program & ³ ³\r
- ³ Reloc. Table ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ <ÄÄÙ\r
- ³ unused ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ <ÄÄÄÄÄÄÄÄÄ Aligned on 8 byte boundary\r
- ³ PE Header ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ Object Table ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ Image Pages ³\r
- ³ import info ³\r
- ³ export info ³\r
- ³ fixup info ³\r
- ³ resource info³\r
- ³ debug info ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 1. A typical 32-bit Portable EXE File Layout\r
-\r
-\r
-\r
-2. PE Header\r
-\r
- \r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ SIGNATURE BYTES ³ CPU TYPE ³ # OBJECTS ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ TIME/DATE STAMP ³ RESERVED ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ RESERVED ³ NT HDR SIZE³ FLAGS ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÂÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ RESERVED ³LMAJOR³LMINOR³ RESERVED ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÁÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ RESERVED ³ RESERVED ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ ENTRYPOINT RVA ³ RESERVED ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ RESERVED ³ IMAGE BASE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ OBJECT ALIGN ³ FILE ALIGN ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ OS MAJOR ³ OS MINOR ³USER MAJOR ³USER MINOR ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ SUBSYS MAJOR³ SUBSYS MINOR³ RESERVED ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ IMAGE SIZE ³ HEADER SIZE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ FILE CHECKSUM ³ SUBSYSTEM ³ DLL FLAGS ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ STACK RESERVE SIZE ³ STACK COMMIT SIZE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ HEAP RESERVE SIZE ³ HEAP COMMIT SIZE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ RESERVED ³ # INTERESTING RVA/SIZES ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ EXPORT TABLE RVA ³ TOTAL EXPORT DATA SIZE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ IMPORT TABLE RVA ³ TOTAL IMPORT DATA SIZE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ RESOURCE TABLE RVA ³ TOTAL RESOURCE DATA SIZE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ EXCEPTION TABLE RVA ³ TOTAL EXCEPTION DATA SIZE³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ SECURITY TABLE RVA ³ TOTAL SECURITY DATA SIZE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ FIXUP TABLE RVA ³ TOTAL FIXUP DATA SIZE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ DEBUG TABLE RVA ³ TOTAL DEBUG DIRECTORIES ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ IMAGE DESCRIPTION RVA ³ TOTAL DESCRIPTION SIZE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ MACHINE SPECIFIC RVA ³ MACHINE SPECIFIC SIZE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ THREAD LOCAL STORAGE RVA ³ TOTAL TLS SIZE ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 2. PE Header\r
-\r
-Notes:\r
-\r
- o A VA is a virtual address that is already biased by the Image\r
- Base found in the PE Header. A RVA is a virtual address that is\r
- relative to the Image Base.\r
- \r
- o An RVA in the PE Header which has a value of zero indicates the\r
- field isn't used.\r
- \r
- o Image pages are aligned and zero padded to a File Align\r
- boundary. The bases of all other tables and structures must be\r
- aligned on DWORD (4 byte) boundary. Thus, all VA's and RVA's\r
- must be on a 32 bit boundary. All table and structure fields\r
- must be aligned on their "natural" boundaries, with the possible\r
- exception of the Debug Info.\r
- \r
-SIGNATURE BYTES = DB * 4.\r
-Current value is "PE/0/0". Thats PE followed by two zeros (nulls).\r
-\r
-CPU TYPE = DW CPU Type.\r
-This field specifies the type of CPU compatibility required by this\r
-image to run. The values are:\r
-\r
- o 0000h __unknown\r
- \r
- o 014Ch __80386\r
- \r
- o 014Dh __80486\r
- \r
- o 014Eh __80586\r
- \r
- o 0162h __MIPS Mark I (R2000, R3000)\r
- \r
- o 0163h __MIPS Mark II (R6000)\r
- \r
- o 0166h __MIPS Mark III (R4000)\r
- \r
-# OBJECTS = DW Number of object entries.\r
-This field specifies the number of entries in the Object Table.\r
-\r
-TIME/DATE STAMP = DD Used to store the time and date the file was\r
-created or modified by the linker.\r
-\r
-NT HDR SIZE = DW This is the number of remaining bytes in the NT\r
-header that follow the FLAGS field.\r
-\r
-FLAGS = DW Flag bits for the image.\r
-The flag bits have the following definitons:\r
-\r
- o 0000h __Program image.\r
- \r
- o 0002h __Image is executable.\r
- If this bit isn't set, then it indicates that either errors\r
- where detected at link time or that the image is being\r
- incrementally linked and therefore can't be loaded.\r
- \r
- o 0200h __Fixed.\r
- Indicates that if the image can't be loaded at the Image Base,\r
- then don't load it.\r
- \r
- o 2000h __Library image.\r
- \r
-LMAJOR/LMINOR = DB Linker major/minor version number.\r
-\r
-ENTRYPOINT RVA = DD Entrypoint relative virtual address.\r
-The address is relative to the Image Base. The address is the\r
-starting address for program images and the library initialization\r
-and library termination address for library images.\r
-\r
-IMAGE BASE = DD The virtual base of the image.\r
-This will be the virtual address of the first byte of the file (Dos\r
-Header). This must be a multiple of 64K.\r
-\r
-OBJECT ALIGN = DD The alignment of the objects. This must be a power\r
-of 2 between 512 and 256M inclusive. The default is 64K.\r
-\r
-FILE ALIGN = DD Alignment factor used to align image pages. The\r
-alignment factor (in bytes) used to align the base of the image pages\r
-and to determine the granularity of per-object trailing zero pad.\r
-Larger alignment factors will cost more file space; smaller alignment\r
-factors will impact demand load performance, perhaps significantly.\r
-Of the two, wasting file space is preferable. This value should be a\r
-power of 2 between 512 and 64K inclusive.\r
-\r
-OS MAJOR/MINOR = DW OS version number required to run this image.\r
-\r
-USER MAJOR/MINOR # = DW User major/minor version number.\r
-This is useful for differentiating between revisions of\r
-images/dynamic linked libraries. The values are specified at link\r
-time by the user.\r
-\r
-SUBSYS MAJOR/MINOR # = DW Subsystem major/minor version number.\r
-\r
-IMAGE SIZE = DD The virtual size (in bytes) of the image.\r
-This includes all headers. The total image size must be a multiple\r
-of Object Align.\r
-\r
-HEADER SIZE = DD Total header size.\r
-The combined size of the Dos Header, PE Header and Object Table.\r
-\r
-FILE CHECKSUM = DD Checksum for entire file. Set to 0 by the linker.\r
-\r
-SUBSYSTEM = DW NT Subsystem required to run this image.\r
-The values are:\r
-\r
- o 0000h __Unknown\r
- \r
- o 0001h __Native\r
- \r
- o 0002h __Windows GUI\r
- \r
- o 0003h __Windows Character\r
- \r
- o 0005h __OS/2 Character\r
- \r
- o 0007h __Posix Character\r
- \r
-DLL FLAGS = DW Indicates special loader requirements.\r
-This flag has the following bit values:\r
-\r
- o 0001h __Per-Process Library Initialization.\r
- \r
- o 0002h __Per-Process Library Termination.\r
- \r
- o 0004h __Per-Thread Library Initialization.\r
- \r
- o 0008h __Per-Thread Library Termination.\r
- \r
-All other bits are reserved for future use and should be set to zero.\r
-\r
-STACK RESERVE SIZE = DD Stack size needed for image.\r
-The memory is reserved, but only the STACK COMMIT SIZE is committed.\r
-The next page of the stack is a 'guarded page'. When the application\r
-hits the guarded page, the guarded page becomes valid, and the next\r
-page becomes the guarded page. This continues until the RESERVE SIZE\r
-is reached.\r
-\r
-STACK COMMIT SIZE = DD Stack commit size.\r
-\r
-HEAP RESERVE SIZE = DD Size of local heap to reserve.\r
-\r
-HEAP COMMIT SIZE = DD Amount to commit in local heap.\r
-\r
-# INTERESTING VA/SIZES = DD Indicates the size of the VA/SIZE array\r
-that follows.\r
-\r
-EXPORT TABLE RVA = DD Relative Virtual Address of the Export Table.\r
-This address is relative to the Image Base.\r
-\r
-IMPORT TABLE RVA = DD Relative Virtual Address of the Import Table.\r
-This address is relative to the Image Base.\r
-\r
-RESOURCE TABLE RVA = DD Relative Virtual Address of the Resource\r
-Table. This address is relative to the Image Base.\r
-\r
-EXCEPTION TABLE RVA = DD Relative Virtual Address of the Exception\r
-Table. This address is relative to the Image Base.\r
-\r
-SECURITY TABLE RVA = DD Relative Virtual Address of the Security\r
-Table. This address is relative to the Image Base.\r
-\r
-FIXUP TABLE RVA = DD Relative Virtual Address of the Fixup Table.\r
-This address is relative to the Image Base.\r
-\r
-DEBUG TABLE RVA = DD Relative Virtual Address of the Debug Table.\r
-This address is relative to the Image Base.\r
-\r
-IMAGE DESCRIPTION RVA = DD Relative Virtual Address of the\r
-description string specified in the module definiton file.\r
-\r
-MACHINE SPECIFIC RVA = DD Relative Virtual Address of a machine\r
-specific value. This address is relative to the Image Base.\r
-\r
-TOTAL EXPORT DATA SIZE = DD Total size of the export data.\r
-\r
-TOTAL IMPORT DATA SIZE = DD Total size of the import data.\r
-\r
-TOTAL RESOURCE DATA SIZE = DD Total size of the resource data.\r
-\r
-TOTAL EXCEPTION DATA SIZE = DD Total size of the exception data.\r
-\r
-TOTAL SECURITY DATA SIZE = DD Total size of the security data.\r
-\r
-TOTAL FIXUP DATA SIZE = DD Total size of the fixup data.\r
-\r
-TOTAL DEBUG DIRECTORIES = DD Total number of debug directories.\r
-\r
-TOTAL DESCRIPTION SIZE = DD Total size of the description data.\r
-\r
-MACHINE SPECIFIC SIZE = DD A machine specific value.\r
-\r
-\r
-\r
-3. Object Table\r
-\r
-The number of entries in the Object Table is given by the # Objects\r
-field in the PE Header. Entries in the Object Table are numbered\r
-starting from one. The object table immediately follows the PE\r
-Header. The code and data memory object entries are in the order\r
-chosen by the linker. The virtual addresses for objects must be\r
-assigned by the linker such that they are in ascending order and\r
-adjacent, and must be a multiple of Object Align in the PE header.\r
-\r
-Each Object Table entry has the following format:\r
-\r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ OBJECT NAME ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ VIRTUAL SIZE ³ RVA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ PHYSICAL SIZE ³ PHYSICAL OFFSET ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ RESERVED ³ RESERVED ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ RESERVED ³ OBJECT FLAGS ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 3. Object Table\r
-\r
-OBJECT NAME = DB * 8 Object name. This is an eight-byte null-padded\r
-ASCII string representing the object name.\r
-\r
-VIRTUAL SIZE = DD Virtual memory size. The size of the object that\r
-will be allocated when the object is loaded. Any difference between\r
-PHYSICAL SIZE and VIRTUAL SIZE is zero filled.\r
-\r
-RVA = DD Relative Virtual Address. The virtual address the object is\r
-currently relocated to, relative to the Image Base. Each Object's\r
-virtual address space consumes a multiple of Object Align (power of 2\r
-between 512 and 256M inclusive. Default is 64K), and immediately\r
-follows the previous Object in the virtual address space (the virtual\r
-address space for a image must be dense).\r
-\r
-PHYSICAL SIZE = DD Physical file size of initialized data. The size\r
-of the initialized data in the file for the object. The physical\r
-size must be a multiple of the File Align field in the PE Header, and\r
-must be less than or equal to the Virtual Size.\r
-\r
-PHYSICAL OFFSET = DD Physical offset for object's first page. This\r
-offset is relative to beginning of the EXE file, and is aligned on a\r
-multiple of the File Align field in the PE Header. The offset is\r
-used as a seek value.\r
-\r
-OBJECT FLAGS = DD Flag bits for the object. The object flag bits\r
-have the following definitions:\r
-\r
- o 000000020h __Code object.\r
- \r
- o 000000040h __Initialized data object.\r
- \r
- o 000000080h __Uninitialized data object.\r
- \r
- o 040000000h __Object must not be cached.\r
- \r
- o 080000000h __Object is not pageable.\r
- \r
- o 100000000h __Object is shared.\r
- \r
- o 200000000h __Executable object.\r
- \r
- o 400000000h __Readable object.\r
- \r
- o 800000000h __Writeable object.\r
- \r
-All other bits are reserved for future use and should be set to zero.\r
-\r
-4. Image Pages\r
-\r
-The Image Pages section contains all initialized data for all\r
-objects. The seek offset for the first page in each object is\r
-specified in the object table and is aligned on a File Align\r
-boundary. The objects are ordered by the RVA. Every object begins\r
-on a multiple of Object Align.\r
-\r
-\r
-\r
-5. Exports\r
-\r
-A typical file layout for the export information follows:\r
-\r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ DIRECTORY TABLE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ ADDRESS TABLE ³\r
- ³ ³\r
- ³ ³\r
- ³ ³\r
- ³ ³\r
- ³ ³\r
- ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ NAME PTR TABLE ³\r
- ³ ³\r
- ³ ³\r
- ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ ORDINAL TABLE ³\r
- ³ ³\r
- ³ ³\r
- ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ NAME STRINGS ³\r
- ³ ³\r
- ³ ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 4. Export File Layout\r
-\r
-5.1 Export Directory Table\r
-\r
-The export information begins with the Export Directory Table which\r
-describes the remainder of the export information. The Export\r
-Directory Table contains address information that is used to resolve\r
-fixup references to the entry points within this image.\r
-\r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ EXPORT FLAGS ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ TIME/DATE STAMP ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ MAJOR VERSION ³ MINOR VERSION ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ NAME RVA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ ORDINAL BASE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ # EAT ENTRIES ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ # NAME PTRS ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ ADDRESS TABLE RVA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ NAME PTR TABLE RVA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ ORDINAL TABLE RVA ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 5. Export Directory Table Entry\r
-\r
-EXPORT FLAGS = DD Currently set to zero.\r
-\r
-TIME/DATE STAMP = DD Time/Date the export data was created.\r
-\r
-MAJOR/MINOR VERSION = DW A user settable major/minor version number.\r
-\r
-NAME RVA = DD Relative Virtual Address of the Dll asciiz Name.\r
-This is the address relative to the Image Base.\r
-\r
-ORDINAL BASE = DD First valid exported ordinal.\r
-This field specifies the starting ordinal number for the export\r
-address table for this image. Normally set to 1.\r
-\r
-# EAT ENTRIES = DD Indicates number of entries in the Export Address\r
-Table.\r
-\r
-# NAME PTRS = DD This indicates the number of entries in the Name Ptr\r
-Table (and parallel Ordinal Table).\r
-\r
-ADDRESS TABLE RVA = DD Relative Virtual Address of the Export Address\r
-Table.\r
-This address is relative to the Image Base.\r
-\r
-NAME TABLE RVA = DD Relative Virtual Address of the Export Name Table\r
-Pointers.\r
-This address is relative to the beginning of the Image Base. This\r
-table is an array of RVA's with # NAMES entries.\r
-\r
-ORDINAL TABLE RVA = DD Relative Virtual Address of Export Ordinals\r
-Table Entry.\r
-This address is relative to the beginning of the Image Base.\r
-\r
-5.2 Export Address Table\r
-\r
-The Export Address Table contains the address of exported entrypoints\r
-and exported data and absolutes. An ordinal number is used to index\r
-the Export Address Table. The ORDINAL BASE must be subracted from the\r
-ordinal number before indexing into this table.\r
-\r
-Export Address Table entry formats are described below:\r
-\r
- ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿\r
- ³ EXPORTED RVA ³\r
- ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 6. Export Address Table Entry\r
-\r
-EXPORTED RVA = DD Export address.\r
-This field contains the relative virtual address of the exported\r
-entry (relative to the Image Base).\r
-\r
-5.3 Export Name Table Pointers\r
-\r
-The export name table pointers array contains address into the Export\r
-Name Table. The pointers are 32-bits each, and are relative to the\r
-Image Base. The pointers are ordered lexically to allow binary\r
-searches.\r
-\r
-5.4 Export Ordinal Table\r
-\r
-The Export Name Table Pointers and the Export Ordinal Table form two\r
-parallel arrays, separated to allow natural field alignment. The\r
-export ordinal table array contains the Export Address Table ordinal\r
-numbers associated with the named export referenced by corresponding\r
-Export Name Table Pointers.\r
-\r
-The ordinals are 16-bits each, and already include the Ordinal Base\r
-stored in the Export Directory Table.\r
-\r
-5.5 Export Name Table\r
-\r
-The export name table contains optional ASCII names for exported\r
-entries in the image. These tables are used with the array of Export\r
-Name Table Pointers and the array of Export Ordinals to translate a\r
-procedure name string into an ordinal number by searching for a\r
-matching name string. The ordinal number is used to locate the entry\r
-point information in the export address table.\r
-\r
-Import references by name require the Export Name Table Pointers\r
-table to be binary searched to find the matching name, then the\r
-corresponding Export Ordinal Table is known to contain the entry\r
-point ordinal number. Import references by ordinal number provide\r
-the fastest lookup since searching the name table is not required.\r
-\r
-Each name table entry has the following format:\r
-\r
- ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿\r
- ³ ASCII STRING ::: :::::::: '\0' ³\r
- ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 7. Export Name Table Entry\r
-\r
-ASCII STRING = DB ASCII String.\r
-The string is case sensitive and is terminated by a null byte.\r
-\r
-\r
-\r
-6. Imports\r
-\r
-A typical file layout for the import information follows:\r
-\r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ DIRECTORY TABLE ³\r
- ³ ³\r
- ³ ³\r
- ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ NULL DIR ENTRY ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ DLL1 LOOKUP TABLE ³\r
- ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ NULL ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ DLL2 LOOKUP TABLE ³\r
- ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ NULL ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ Dll3 LOOKUP TABLE ³\r
- ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ NULL ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ HINT-NAME TABLE ³\r
- ³ ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ DLL1 ADDRESS TABLE ³\r
- ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ NULL ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ DLL2 ADDRESS TABLE ³\r
- ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ NULL ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ DLL3 ADDRESS TABLE ³\r
- ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ NULL ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 8. Import File Layout\r
-\r
-6.1 Import Directory Table\r
-\r
-The import information begins with the Import Directory Table which\r
-describes the remainder of the import information. The Import\r
-Directory Table contains address information that is used to resolve\r
-fixup references to the entry points within a DLL image. The import\r
-directory table consists of an array of Import Directory Entries, one\r
-entry for each DLL this image references. The last directory entry is\r
-empty (NULL) which indicates the end of the directory table.\r
-\r
-An Import Directory Entry has the following format:\r
-\r
- ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿\r
- ³ IMPORT FLAGS ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ TIME/DATE STAMP ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ MAJOR VERSION ³ MINOR VERSION ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ NAME RVA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ IMPORT LOOKUP TABLE RVA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ IMPORT ADDRESS TABLE RVA ³\r
- ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 9. Import Directory Entry\r
-\r
-IMPORT FLAGS = DD Currently set to zero.\r
-\r
-TIME/DATE STAMP = DD Time/Date the import data was pre-snapped or\r
-zero if not pre-snapped.\r
-\r
-MAJOR/MINOR VERSION = DW The major/minor version number of the dll\r
-being referenced.\r
-\r
-NAME RVA = DD Relative Virtual Address of the Dll asciiz Name.\r
-This is the address relative to the Image Base.\r
-\r
-IMPORT LOOKUP TABLE RVA = DD This field contains the address of the\r
-start of the import lookup table for this image. The address is\r
-relative to the beginning of the Image Base.\r
-\r
-IMPORT ADDRESS TABLE RVA = DD This field contains the address of the\r
-start of the import addresses for this image. The address is\r
-relative to the beginning of the Image Base.\r
-\r
-6.2 Import Lookup Table\r
-\r
-The Import Lookup Table is an array of ordinal or hint/name RVA's for\r
-each DLL. The last entry is empty (NULL) which indicates the end of\r
-the table.\r
-\r
-The last element is empty.\r
-\r
- 3 0\r
- 1\r
- ÚÄÒÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿\r
- ³0º ORDINAL#/HINT-NAME TABLE RVA ³\r
- ÀÄÐÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 10. Import Address Table Format\r
-\r
-ORDINAL/HINT-NAME TABLE RVA = 31-bits (mask = 7fffffffh) Ordinal\r
-Number or Name Table RVA.\r
-If the import is by ordinal, this field contains a 31 bit ordinal\r
-number. If the import is by name, this field contains a 31 bit\r
-address relative to the Image Base to the Hint-Name Table.\r
-\r
-O = 1-bit (mask = 80000000h) Import by ordinal flag.\r
-\r
- o 00000000h __Import by name.\r
- \r
- o 80000000h __Import by ordinal.\r
- \r
-6.3 Hint-Name Table\r
-\r
-The Hint-Name Table format follows:\r
-\r
- ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿\r
- ³ HINT ³ ASCII STRING |||³\r
- ÃÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄ´\r
- ³|||||||||||||||||³ '\0' PAD ³\r
- ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ\r
- \r
- \r
- The PAD field is optional.\r
- \r
-Figure 11. Import Hint-Name Table\r
-\r
-HINT = DW Hint into Export Name Table Pointers.\r
-The hint value is used to index the Export Name Table Pointers array,\r
-allowing faster by-name imports. If the hint is incorrect, then a\r
-binary search is performed on the Export Name Ptr Table.\r
-\r
-ASCII STRING = DB ASCII String.\r
-The string is case sensitive and is terminated by a null byte.\r
-\r
-PAD = DB Zero pad byte.\r
-A trailing zero pad byte appears after the trailing null byte if\r
-necessary to align the next entry on an even boundary.\r
-\r
-The loader overwrites the import address table when loading the image\r
-with the 32-bit address of the import.\r
-\r
-\r
-\r
-6.4 Import Address Table\r
-\r
-The Import Address Table is an array of addresses of the imported\r
-routines for each DLL. The last entry is empty (NULL) which indicates\r
-the end of the table.\r
-\r
-7. Thread Local Storage\r
-\r
-Thread local storage is a special contiguous block of data. Each\r
-thread will gets its own block upon creation of the thread.\r
-\r
-The file layout for thread local storage follows:\r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ DIRECTORY TABLE ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ TLS DATA ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ INDEX VARIABLE ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ CALLBACK ADDRESSES ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
-\r
-Figure 12. Thread Local Storage Layout\r
-\r
-7.1 Thread Local Storage Directory Table\r
-\r
-The Thread Local Storage Directory Table contains address information\r
-that is used to describe the rest of TLS.\r
-\r
-The Thread Local Storage Directory Table has the following format:\r
-\r
- ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿\r
- ³ START DATA BLOCK VA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ END DATA BLOCK VA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ INDEX VA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ CALLBACK TABLE VA ³\r
- ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 13. Thread Local Storage Directory Table\r
-\r
-START DATA BLOCK VA = DD Virtual Address of the start of the thread\r
-local storage data block.\r
-\r
-END DATA BLOCK VA = DD Virtual Address of the end of the thread local\r
-storage data block.\r
-\r
-INDEX VA = DD Virtual Address of the index variable used to access\r
-the thread local storage data block.\r
-\r
-CALLBACK TABLE VA = DD Virtual Address of the callback table.\r
-\r
-7.2 Thread Local Storage CallBack Table\r
-\r
-The Thread Local Storage Callbacks is an array of Virtual Address of\r
-functions to be called by the loader after thread creation and thread\r
-termination. The last entry is empty (NULL) which indicates the end\r
-of the table.\r
-\r
-The Thread Local Storage CallBack Table has the following format:\r
-\r
- ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿\r
- ³ FUNCTION1 VA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ FUNCTION2 VA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ NULL ³\r
- ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 14. Thread Local Storage CallBack Table\r
-\r
-8. Resources\r
-\r
-Resources are indexed by a multiple level binary-sorted tree\r
-structure. The overall design can incorporate 2**31 levels, however,\r
-NT uses only three: the highest is TYPE, then NAME, then LANGUAGE.\r
-\r
-A typical file layout for the resource information follows:\r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ RESOURCE DIRECTORY ³\r
- ³ ³\r
- ³ ³\r
- ³ ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ RESOURCE DATA ³\r
- ³ ³\r
- ³ ³\r
- ³ ³\r
- ³ ³\r
- ³ ³\r
- ³ ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 15. Resource File Layout\r
-\r
-\r
-The Resource directory is made up of the following tables:\r
-\r
-\r
-\r
-8.1 Resource Directory Table\r
-ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿\r
-³ RESOURCE FLAGS ³\r
-ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
-³ TIME/DATE STAMP ³\r
-ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
-³ MAJOR VERSION ³ MINOR VERSION ³\r
-ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
-³ # NAME ENTRY ³ # ID ENTRY ³\r
-ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
-³ RESOURCE DIR ENTRIES ³\r
-ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ\r
-\r
-Figure 16. Resource Table Entry\r
-\r
-\r
-RESOURCE FLAGS = DD Currently set to zero.\r
-\r
-TIME/DATE STAMP = DD Time/Date the resource data was created by the\r
-resource compiler.\r
-\r
-MAJOR/MINOR VERSION = DW A user settable major/minor version number.\r
-\r
-# NAME ENTRY = DW The number of name entries.\r
-This field contains the number of entries at the beginning of the\r
-array of directory entries which have actual string names associated\r
-with them.\r
-\r
-# ID ENTRY = DW The number of ID integer entries.\r
-This field contains the number of 32-bit integer IDs as their names\r
-in the array of directory entries.\r
-\r
-The resource directory is followed by a variable length array of\r
-directory entries. # NAME ENTRY is the number of entries at the\r
-beginning of the array that have actual names associated with each\r
-entry. The entires are in ascending order, case insensitive strings.\r
-# ID ENTRY identifies the number of entries that have 32-bit integer\r
-IDs as their name. These entries are also sorted in ascending order.\r
-\r
-This structure allows fast lookup by either name or number, but for\r
-any given resource entry only one form of lookup is supported, not\r
-both. This is consistent with the syntax of the .RC file and the .RES\r
-file.\r
-\r
-\r
-\r
-The array of directory entries have the following format:\r
- 3 0\r
- 1\r
-ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿\r
-³ NAME RVA/INTEGER ID ³\r
-ÃÄÒÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
-³Eº DATA ENTRY RVA/SUBDIR RVA ³\r
-ÀÄÐÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ\r
-\r
-Figure 17. Resource Directory Entry\r
-\r
-\r
-INTERGER ID = DD ID.\r
-This field contains a integer ID field to identify a resource.\r
-\r
-NAME RVA = DD Name RVA address.\r
-This field contains a 31-bit address relative to the beginning of the\r
-Image Base to a Resource Directory String Entry.\r
-\r
-E = 1-bit (mask 80000000h) Unescape bit.\r
-This bit is zero for unescaped Resource Data Entries.\r
-\r
-DATA RVA = 31-bits (mask 7fffffffh) Data entry address.\r
-This field contains a 31-bit address relative to the beginning of the\r
-Image Base to a Resource Data Entry.\r
-\r
-E = 1-bit (mask 80000000h) Escape bit.\r
-This bit is 1 for escaped Subdirectory Entry.\r
-\r
-DATA RVA = 31-bits (mask 7fffffffh) Directory entries.\r
-This field contains a 31-bit address relative to the beginning of the\r
-Image Base to Subdirectory Entry.\r
-\r
-\r
-\r
-Each resource directory string entry has the following format:\r
-ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿\r
-³ LENGTH ³ UNICODE STRING ³\r
-ÃÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄ´\r
-³ ³\r
-ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ\r
-\r
-Figure 18. Resource Directory String Entry\r
-\r
-\r
-LENGTH = DW Length of string.\r
-\r
-UNICODE STRING = DW UNICODE String.\r
-\r
-All of these string objects are stored together after the last\r
-resource directory entry and before the first resource data object.\r
-This minimizes the impact of these variable length objects on the\r
-alignment of the fixed size directory entry objects. The length needs\r
-to be word aligned.\r
-\r
-\r
-\r
-Each Resource Data Entry has the following format:\r
-\r
- ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿\r
- ³ DATA RVA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ SIZE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ CODEPAGE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ RESERVED ³\r
- ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 19. Resource Data Entry\r
-\r
-\r
-\r
-DATA RVA = DD Address of Resource Data.\r
-This field contains 32-bit virtaul address of the resource data\r
-(relative to the Image Base).\r
-\r
-SIZE = DD Size of Resource Data.\r
-This field contains the size of the resource data for this resource.\r
-\r
-CODEPAGE = DD Codepage.\r
-\r
-RESERVED = DD Reserved - must be zero.\r
-\r
-Each resource data entry describes a leaf node in the resource\r
-directory tree. It contains an address which is relative to the\r
-beginning of Image Base, a size field that gives the number of bytes\r
-of data at that address, a CodePage that should be used when decoding\r
-code point values within the resource data. Typically for new\r
-applications the code page would be the unicode code page.\r
-\r
-\r
-\r
-8.2 Resource Example\r
-\r
-The following is an example for an app. which wants to use the following data\r
-as resources:\r
-\r
- TypeId# NameId# Language ID Resource Data\r
- 00000001 00000001 0 00010001\r
- 00000001 00000001 1 10010001\r
- 00000001 00000002 0 00010002\r
- 00000001 00000003 0 00010003\r
- 00000002 00000001 0 00020001\r
- 00000002 00000002 0 00020002\r
- 00000002 00000003 0 00020003\r
- 00000002 00000004 0 00020004\r
- 00000009 00000001 0 00090001\r
- 00000009 00000009 0 00090009\r
- 00000009 00000009 1 10090009\r
- 00000009 00000009 2 20090009\r
-\r
-Then the Resource Directory in the Portable format looks like:\r
-Offset Data\r
-0000: 00000000 00000000 00000000 00030000 (3 entries in this directory)\r
-0010: 00000001 80000028 (TypeId #1, Subdirectory at offset 0x28)\r
-0018: 00000002 80000050 (TypeId #2, Subdirectory at offset 0x50)\r
-0020: 00000009 80000080 (TypeId #9, Subdirectory at offset 0x80)\r
-0028: 00000000 00000000 00000000 00030000 (3 entries in this directory)\r
-0038: 00000001 800000A0 (NameId #1, Subdirectory at offset 0xA0)\r
-0040: 00000002 00000108 (NameId #2, data desc at offset 0x108)\r
-0048: 00000003 00000118 (NameId #3, data desc at offset 0x118)\r
-0050: 00000000 00000000 00000000 00040000 (4 entries in this directory)\r
-0060: 00000001 00000128 (NameId #1, data desc at offset 0x128)\r
-0068: 00000002 00000138 (NameId #2, data desc at offset 0x138)\r
-0070: 00000003 00000148 (NameId #3, data desc at offset 0x148)\r
-0078: 00000004 00000158 (NameId #4, data desc at offset 0x158)\r
-0080: 00000000 00000000 00000000 00020000 (2 entries in this directory)\r
-0090: 00000001 00000168 (NameId #1, data desc at offset 0x168)\r
-0098: 00000009 800000C0 (NameId #9, Subdirectory at offset 0xC0)\r
-00A0: 00000000 00000000 00000000 00020000 (2 entries in this directory)\r
-00B0: 00000000 000000E8 (Language ID 0, data desc at offset 0xE8\r
-00B8: 00000001 000000F8 (Language ID 1, data desc at offset 0xF8\r
-00C0: 00000000 00000000 00000000 00030000 (3 entries in this directory)\r
-00D0: 00000001 00000178 (Language ID 0, data desc at offset 0x178\r
-00D8: 00000001 00000188 (Language ID 1, data desc at offset 0x188\r
-00E0: 00000001 00000198 (Language ID 2, data desc at offset 0x198\r
-\r
-00E8: 000001A8 (At offset 0x1A8, for TypeId #1, NameId #1, Language id #0\r
- 00000004 (4 bytes of data)\r
- 00000000 (codepage)\r
- 00000000 (reserved)\r
-00F8: 000001AC (At offset 0x1AC, for TypeId #1, NameId #1, Language id #1\r
- 00000004 (4 bytes of data)\r
- 00000000 (codepage)\r
- 00000000 (reserved)\r
-0108: 000001B0 (At offset 0x1B0, for TypeId #1, NameId #2,\r
- 00000004 (4 bytes of data)\r
- 00000000 (codepage)\r
- 00000000 (reserved)\r
-0118: 000001B4 (At offset 0x1B4, for TypeId #1, NameId #3,\r
- 00000004 (4 bytes of data)\r
- 00000000 (codepage)\r
- 00000000 (reserved)\r
-0128: 000001B8 (At offset 0x1B8, for TypeId #2, NameId #1,\r
- 00000004 (4 bytes of data)\r
- 00000000 (codepage)\r
- 00000000 (reserved)\r
-0138: 000001BC (At offset 0x1BC, for TypeId #2, NameId #2,\r
- 00000004 (4 bytes of data)\r
- 00000000 (codepage)\r
- 00000000 (reserved)\r
-0148: 000001C0 (At offset 0x1C0, for TypeId #2, NameId #3,\r
- 00000004 (4 bytes of data)\r
- 00000000 (codepage)\r
- 00000000 (reserved)\r
-0158: 000001C4 (At offset 0x1C4, for TypeId #2, NameId #4,\r
- 00000004 (4 bytes of data)\r
- 00000000 (codepage)\r
- 00000000 (reserved)\r
-0168: 000001C8 (At offset 0x1C8, for TypeId #9, NameId #1,\r
- 00000004 (4 bytes of data)\r
- 00000000 (codepage)\r
- 00000000 (reserved)\r
-0178: 000001CC (At offset 0x1CC, for TypeId #9, NameId #9, Language id #0\r
- 00000004 (4 bytes of data)\r
- 00000000 (codepage)\r
- 00000000 (reserved)\r
-0188: 000001D0 (At offset 0x1D0, for TypeId #9, NameId #9, Language id #1\r
- 00000004 (4 bytes of data)\r
- 00000000 (codepage)\r
- 00000000 (reserved)\r
-0198: 000001D4 (At offset 0x1D4, for TypeId #9, NameId #9, Language id #2\r
- 00000004 (4 bytes of data)\r
- 00000000 (codepage)\r
- 00000000 (reserved)\r
-\r
-And the data for the resources will look like:\r
-01A8: 00010001\r
-01AC: 10010001\r
-01B0: 00010002\r
-01B4: 00010003\r
-01B8: 00020001\r
-01BC: 00020002\r
-01C0: 00020003\r
-01C4: 00020004\r
-01C8: 00090001\r
-01CC: 00090009\r
-01D0: 10090009\r
-01D4: 20090009\r
-\r
-\r
-9. Fixup Table\r
-\r
-The Fixup Table contains entries for all fixups in the image. The\r
-Total Fixup Data Size in the PE Header is the number of bytes in the\r
-fixup table. The fixup table is broken into blocks of fixups. Each\r
-block represents the fixups for a 4K page.\r
-\r
-Fixups that are resolved by the linker do not need to be processed by\r
-the loader, unless the load image can't be loaded at the Image Base\r
-specified in the PE Header.\r
-\r
-9.1 Fixup Block\r
-\r
-Fixup blocks have the following format:\r
-\r
- ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³ PAGE RVA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ BLOCK SIZE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ TYPE/OFFSET ³ TYPE/OFFSET ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ TYPE/OFFSET ³ ... ³\r
- ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 20. Fixup Block Format\r
-\r
-To apply a fixup, a delta needs to be calculated. The 32-bit delta\r
-is the difference between the preferred base, and the base where the\r
-image is actually loaded. If the image is loaded at its preferred\r
-base, the delta would be zero, and thus the fixups would not have to\r
-be applied. Each block must start on a DWORD boundary. The ABSOLUTE\r
-fixup type can be used to pad a block.\r
-\r
-PAGE RVA = DD Page RVA. The image base plus the page rva is added to\r
-each offset to create the virtual address of where the fixup needs to\r
-be applied.\r
-\r
-BLOCK SIZE = DD Number of bytes in the fixup block. This includes the\r
-PAGE RVA and SIZE fields.\r
-\r
-TYPE/OFFSET is defined as:\r
-\r
- 1 1 0\r
- 5 1\r
- ÚÄÄÄÄÒÄÄÄÄÄÄÄÄÄÄÄÄ¿\r
- ³TYPEº OFFSET ³\r
- ÀÄÄÄÄÐÄÄÄÄÄÄÄÄÄÄÄÄÙ\r
-Figure 21. Fixup Record Format\r
-\r
-TYPE = 4-bit fixup type. This value has the following definitions:\r
-\r
- o 0h __ABSOLUTE. This is a NOP. The fixup is skipped.\r
- \r
- o 1h __HIGH. Add the high 16-bits of the delta to the 16-bit field\r
- at Offset. The 16-bit field represents the high value of a 32-\r
- bit word.\r
- \r
- o 2h __LOW. Add the low 16-bits of the delta to the 16-bit field\r
- at Offset. The 16-bit field represents the low half value of a\r
- 32-bit word. This fixup will only be emitted for a RISC machine\r
- when the image Object Align isn't the default of 64K.\r
- \r
- o 3h __HIGHLOW. Apply the 32-bit delta to the 32-bit field at\r
- Offset.\r
- \r
- o 4h __HIGHADJUST. This fixup requires a full 32-bit value. The\r
- high 16-bits is located at Offset, and the low 16-bits is\r
- located in the next Offset array element (this array element is\r
- included in the SIZE field). The two need to be combined into a\r
- signed variable. Add the 32-bit delta. Then add 0x8000 and\r
- store the high 16-bits of the signed variable to the 16-bit\r
- field at Offset.\r
- \r
- o 5h __MIPSJMPADDR.\r
- \r
-All other values are reserved.\r
-\r
-\r
-\r
-10. Debug Information\r
-\r
-The debug information is defined by the debugger and is not\r
-controlled by the portable EXE format or linker. The only data\r
-defined by the portable EXE format is the Debug Directory Table.\r
-\r
-10.1 Debug Directory\r
-\r
-The debug directory table consists of one or more entries that have\r
-the following format:\r
-\r
- ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿\r
- ³ DEBUG FLAGS ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ TIME/DATE STAMP ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ MAJOR VERSION ³ MINOR VERSION ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ DEBUG TYPE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ DATA SIZE ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ DATA RVA ³\r
- ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´\r
- ³ DATA SEEK ³\r
- ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ\r
- \r
-Figure 22. Debug Directory Entry\r
-\r
-DEBUG FLAGS = DD Set to zero for now.\r
-\r
-TIME/DATE STAMP = DD Time/Date the debug data was created.\r
-\r
-MAJOR/MINOR VERSION = DW Version stamp.\r
-This stamp can be used to determine the version of the debug data.\r
-\r
-DEBUG TYPE = DD Format type.\r
-To support multiple debuggers, this field determines the format of\r
-the debug information. This value has the following definitions:\r
-\r
- o 0001h __Image contains COFF symbolics.\r
- \r
- o 0001h __Image contains CodeView symbolics.\r
- \r
- o 0001h __Image contains FPO symbolics.\r
- \r
-DATA SIZE = DD The number of bytes in the debug data. This is the\r
-size of the actual debug data and does not include the debug\r
-directory.\r
-\r
-DATA RVA = DD The relative virtual address of the debug data. This\r
-address is relative to the beginning of the Image Base.\r
-\r
-DATA SEEK = DD The seek value from the beginning of the file to the\r
-debug data.\r
-\r
-If the image contains more than one type of debug information, then\r
-the next debug directory will immediately follow the first debug\r
-directory.\r
+
+ PORTABLE EXECUTABLE FORMAT
+
+ Author: Micheal J. O'Leary
+
+
+ Preface
+
+ This document was edited and released by Microsoft Developer
+ Support. It describes the binary portable executable format for NT.
+ The information is provided at this point because we feel it will
+ make the work of application development easier. Unfortunately, the
+ information in this document may change before the final release of
+ Windows NT. Microsoft is NOT committing to stay with these formats
+ by releasing this document. Questions or follow-ups for any of the
+ information presented here should be posted to CompuServe MSWIN32
+ forum, section 6.
+ --Steve Firebaugh
+ Microsoft Developer Support
+
+
+
+Contents
+
+ 1. Overview
+
+ 2. PE Header
+
+ 3. Object Table
+
+ 4. Image Pages
+
+ 5. Exports
+ 5.1 Export Directory Table
+ 5.2 Export Address Table
+ 5.3 Export Name Table Pointers
+ 5.4 Export Ordinal Table
+ 5.5 Export Name Table
+
+ 6. Imports
+ 6.1 Import Directory Table
+ 6.2 Import Lookup Table
+ 6.3 Hint-Name Table
+ 6.4 Import Address Table
+
+ 7. Thread Local Storage
+ 7.1 Thread Local Storage Directory Table
+ 7.2 Thread Local Storage CallBack Table
+
+ 8. Resources
+ 8.1 Resource Directory Table
+ 8.2 Resource Example
+
+ 9. Fixup Table
+ 9.1 Fixup Block
+
+ 10. Debug Information
+ 10.1 Debug Directory
+
+
+
+1. Overview
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ <ÄÄ¿ <ÄÄÄÄÄ Base of Image Header
+ ³ DOS 2 Compatible ³ ³
+ ³ EXE Header ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
+ ³ unused ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
+ ³ OEM Identifier ³ ³
+ ³ OEM Info ³ ³
+ ³ ³ ³ DOS 2.0 Section
+ ³ Offset to ³ ³ (for DOS compatibility only)
+ ³ PE Header ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
+ ³ DOS 2.0 Stub ³ ³
+ ³ Program & ³ ³
+ ³ Reloc. Table ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ <ÄÄÙ
+ ³ unused ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ <ÄÄÄÄÄÄÄÄÄ Aligned on 8 byte boundary
+ ³ PE Header ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ Object Table ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ Image Pages ³
+ ³ import info ³
+ ³ export info ³
+ ³ fixup info ³
+ ³ resource info³
+ ³ debug info ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+Figure 1. A typical 32-bit Portable EXE File Layout
+
+
+
+2. PE Header
+
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ SIGNATURE BYTES ³ CPU TYPE ³ # OBJECTS ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ TIME/DATE STAMP ³ RESERVED ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ RESERVED ³ NT HDR SIZE³ FLAGS ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÂÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ RESERVED ³LMAJOR³LMINOR³ RESERVED ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÁÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ RESERVED ³ RESERVED ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ ENTRYPOINT RVA ³ RESERVED ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ RESERVED ³ IMAGE BASE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ OBJECT ALIGN ³ FILE ALIGN ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ OS MAJOR ³ OS MINOR ³USER MAJOR ³USER MINOR ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ SUBSYS MAJOR³ SUBSYS MINOR³ RESERVED ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ IMAGE SIZE ³ HEADER SIZE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ FILE CHECKSUM ³ SUBSYSTEM ³ DLL FLAGS ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ STACK RESERVE SIZE ³ STACK COMMIT SIZE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ HEAP RESERVE SIZE ³ HEAP COMMIT SIZE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ RESERVED ³ # INTERESTING RVA/SIZES ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ EXPORT TABLE RVA ³ TOTAL EXPORT DATA SIZE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ IMPORT TABLE RVA ³ TOTAL IMPORT DATA SIZE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ RESOURCE TABLE RVA ³ TOTAL RESOURCE DATA SIZE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ EXCEPTION TABLE RVA ³ TOTAL EXCEPTION DATA SIZE³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ SECURITY TABLE RVA ³ TOTAL SECURITY DATA SIZE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ FIXUP TABLE RVA ³ TOTAL FIXUP DATA SIZE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ DEBUG TABLE RVA ³ TOTAL DEBUG DIRECTORIES ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ IMAGE DESCRIPTION RVA ³ TOTAL DESCRIPTION SIZE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ MACHINE SPECIFIC RVA ³ MACHINE SPECIFIC SIZE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ THREAD LOCAL STORAGE RVA ³ TOTAL TLS SIZE ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+Figure 2. PE Header
+
+Notes:
+
+ o A VA is a virtual address that is already biased by the Image
+ Base found in the PE Header. A RVA is a virtual address that is
+ relative to the Image Base.
+
+ o An RVA in the PE Header which has a value of zero indicates the
+ field isn't used.
+
+ o Image pages are aligned and zero padded to a File Align
+ boundary. The bases of all other tables and structures must be
+ aligned on DWORD (4 byte) boundary. Thus, all VA's and RVA's
+ must be on a 32 bit boundary. All table and structure fields
+ must be aligned on their "natural" boundaries, with the possible
+ exception of the Debug Info.
+
+SIGNATURE BYTES = DB * 4.
+Current value is "PE/0/0". Thats PE followed by two zeros (nulls).
+
+CPU TYPE = DW CPU Type.
+This field specifies the type of CPU compatibility required by this
+image to run. The values are:
+
+ o 0000h __unknown
+
+ o 014Ch __80386
+
+ o 014Dh __80486
+
+ o 014Eh __80586
+
+ o 0162h __MIPS Mark I (R2000, R3000)
+
+ o 0163h __MIPS Mark II (R6000)
+
+ o 0166h __MIPS Mark III (R4000)
+
+# OBJECTS = DW Number of object entries.
+This field specifies the number of entries in the Object Table.
+
+TIME/DATE STAMP = DD Used to store the time and date the file was
+created or modified by the linker.
+
+NT HDR SIZE = DW This is the number of remaining bytes in the NT
+header that follow the FLAGS field.
+
+FLAGS = DW Flag bits for the image.
+The flag bits have the following definitons:
+
+ o 0000h __Program image.
+
+ o 0002h __Image is executable.
+ If this bit isn't set, then it indicates that either errors
+ where detected at link time or that the image is being
+ incrementally linked and therefore can't be loaded.
+
+ o 0200h __Fixed.
+ Indicates that if the image can't be loaded at the Image Base,
+ then don't load it.
+
+ o 2000h __Library image.
+
+LMAJOR/LMINOR = DB Linker major/minor version number.
+
+ENTRYPOINT RVA = DD Entrypoint relative virtual address.
+The address is relative to the Image Base. The address is the
+starting address for program images and the library initialization
+and library termination address for library images.
+
+IMAGE BASE = DD The virtual base of the image.
+This will be the virtual address of the first byte of the file (Dos
+Header). This must be a multiple of 64K.
+
+OBJECT ALIGN = DD The alignment of the objects. This must be a power
+of 2 between 512 and 256M inclusive. The default is 64K.
+
+FILE ALIGN = DD Alignment factor used to align image pages. The
+alignment factor (in bytes) used to align the base of the image pages
+and to determine the granularity of per-object trailing zero pad.
+Larger alignment factors will cost more file space; smaller alignment
+factors will impact demand load performance, perhaps significantly.
+Of the two, wasting file space is preferable. This value should be a
+power of 2 between 512 and 64K inclusive.
+
+OS MAJOR/MINOR = DW OS version number required to run this image.
+
+USER MAJOR/MINOR # = DW User major/minor version number.
+This is useful for differentiating between revisions of
+images/dynamic linked libraries. The values are specified at link
+time by the user.
+
+SUBSYS MAJOR/MINOR # = DW Subsystem major/minor version number.
+
+IMAGE SIZE = DD The virtual size (in bytes) of the image.
+This includes all headers. The total image size must be a multiple
+of Object Align.
+
+HEADER SIZE = DD Total header size.
+The combined size of the Dos Header, PE Header and Object Table.
+
+FILE CHECKSUM = DD Checksum for entire file. Set to 0 by the linker.
+
+SUBSYSTEM = DW NT Subsystem required to run this image.
+The values are:
+
+ o 0000h __Unknown
+
+ o 0001h __Native
+
+ o 0002h __Windows GUI
+
+ o 0003h __Windows Character
+
+ o 0005h __OS/2 Character
+
+ o 0007h __Posix Character
+
+DLL FLAGS = DW Indicates special loader requirements.
+This flag has the following bit values:
+
+ o 0001h __Per-Process Library Initialization.
+
+ o 0002h __Per-Process Library Termination.
+
+ o 0004h __Per-Thread Library Initialization.
+
+ o 0008h __Per-Thread Library Termination.
+
+All other bits are reserved for future use and should be set to zero.
+
+STACK RESERVE SIZE = DD Stack size needed for image.
+The memory is reserved, but only the STACK COMMIT SIZE is committed.
+The next page of the stack is a 'guarded page'. When the application
+hits the guarded page, the guarded page becomes valid, and the next
+page becomes the guarded page. This continues until the RESERVE SIZE
+is reached.
+
+STACK COMMIT SIZE = DD Stack commit size.
+
+HEAP RESERVE SIZE = DD Size of local heap to reserve.
+
+HEAP COMMIT SIZE = DD Amount to commit in local heap.
+
+# INTERESTING VA/SIZES = DD Indicates the size of the VA/SIZE array
+that follows.
+
+EXPORT TABLE RVA = DD Relative Virtual Address of the Export Table.
+This address is relative to the Image Base.
+
+IMPORT TABLE RVA = DD Relative Virtual Address of the Import Table.
+This address is relative to the Image Base.
+
+RESOURCE TABLE RVA = DD Relative Virtual Address of the Resource
+Table. This address is relative to the Image Base.
+
+EXCEPTION TABLE RVA = DD Relative Virtual Address of the Exception
+Table. This address is relative to the Image Base.
+
+SECURITY TABLE RVA = DD Relative Virtual Address of the Security
+Table. This address is relative to the Image Base.
+
+FIXUP TABLE RVA = DD Relative Virtual Address of the Fixup Table.
+This address is relative to the Image Base.
+
+DEBUG TABLE RVA = DD Relative Virtual Address of the Debug Table.
+This address is relative to the Image Base.
+
+IMAGE DESCRIPTION RVA = DD Relative Virtual Address of the
+description string specified in the module definiton file.
+
+MACHINE SPECIFIC RVA = DD Relative Virtual Address of a machine
+specific value. This address is relative to the Image Base.
+
+TOTAL EXPORT DATA SIZE = DD Total size of the export data.
+
+TOTAL IMPORT DATA SIZE = DD Total size of the import data.
+
+TOTAL RESOURCE DATA SIZE = DD Total size of the resource data.
+
+TOTAL EXCEPTION DATA SIZE = DD Total size of the exception data.
+
+TOTAL SECURITY DATA SIZE = DD Total size of the security data.
+
+TOTAL FIXUP DATA SIZE = DD Total size of the fixup data.
+
+TOTAL DEBUG DIRECTORIES = DD Total number of debug directories.
+
+TOTAL DESCRIPTION SIZE = DD Total size of the description data.
+
+MACHINE SPECIFIC SIZE = DD A machine specific value.
+
+
+
+3. Object Table
+
+The number of entries in the Object Table is given by the # Objects
+field in the PE Header. Entries in the Object Table are numbered
+starting from one. The object table immediately follows the PE
+Header. The code and data memory object entries are in the order
+chosen by the linker. The virtual addresses for objects must be
+assigned by the linker such that they are in ascending order and
+adjacent, and must be a multiple of Object Align in the PE header.
+
+Each Object Table entry has the following format:
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ OBJECT NAME ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ VIRTUAL SIZE ³ RVA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ PHYSICAL SIZE ³ PHYSICAL OFFSET ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ RESERVED ³ RESERVED ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ RESERVED ³ OBJECT FLAGS ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+Figure 3. Object Table
+
+OBJECT NAME = DB * 8 Object name. This is an eight-byte null-padded
+ASCII string representing the object name.
+
+VIRTUAL SIZE = DD Virtual memory size. The size of the object that
+will be allocated when the object is loaded. Any difference between
+PHYSICAL SIZE and VIRTUAL SIZE is zero filled.
+
+RVA = DD Relative Virtual Address. The virtual address the object is
+currently relocated to, relative to the Image Base. Each Object's
+virtual address space consumes a multiple of Object Align (power of 2
+between 512 and 256M inclusive. Default is 64K), and immediately
+follows the previous Object in the virtual address space (the virtual
+address space for a image must be dense).
+
+PHYSICAL SIZE = DD Physical file size of initialized data. The size
+of the initialized data in the file for the object. The physical
+size must be a multiple of the File Align field in the PE Header, and
+must be less than or equal to the Virtual Size.
+
+PHYSICAL OFFSET = DD Physical offset for object's first page. This
+offset is relative to beginning of the EXE file, and is aligned on a
+multiple of the File Align field in the PE Header. The offset is
+used as a seek value.
+
+OBJECT FLAGS = DD Flag bits for the object. The object flag bits
+have the following definitions:
+
+ o 000000020h __Code object.
+
+ o 000000040h __Initialized data object.
+
+ o 000000080h __Uninitialized data object.
+
+ o 040000000h __Object must not be cached.
+
+ o 080000000h __Object is not pageable.
+
+ o 100000000h __Object is shared.
+
+ o 200000000h __Executable object.
+
+ o 400000000h __Readable object.
+
+ o 800000000h __Writeable object.
+
+All other bits are reserved for future use and should be set to zero.
+
+4. Image Pages
+
+The Image Pages section contains all initialized data for all
+objects. The seek offset for the first page in each object is
+specified in the object table and is aligned on a File Align
+boundary. The objects are ordered by the RVA. Every object begins
+on a multiple of Object Align.
+
+
+
+5. Exports
+
+A typical file layout for the export information follows:
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ DIRECTORY TABLE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ ADDRESS TABLE ³
+ ³ ³
+ ³ ³
+ ³ ³
+ ³ ³
+ ³ ³
+ ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ NAME PTR TABLE ³
+ ³ ³
+ ³ ³
+ ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ ORDINAL TABLE ³
+ ³ ³
+ ³ ³
+ ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ NAME STRINGS ³
+ ³ ³
+ ³ ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+Figure 4. Export File Layout
+
+5.1 Export Directory Table
+
+The export information begins with the Export Directory Table which
+describes the remainder of the export information. The Export
+Directory Table contains address information that is used to resolve
+fixup references to the entry points within this image.
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ EXPORT FLAGS ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ TIME/DATE STAMP ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ MAJOR VERSION ³ MINOR VERSION ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ NAME RVA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ ORDINAL BASE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ # EAT ENTRIES ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ # NAME PTRS ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ ADDRESS TABLE RVA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ NAME PTR TABLE RVA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ ORDINAL TABLE RVA ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+Figure 5. Export Directory Table Entry
+
+EXPORT FLAGS = DD Currently set to zero.
+
+TIME/DATE STAMP = DD Time/Date the export data was created.
+
+MAJOR/MINOR VERSION = DW A user settable major/minor version number.
+
+NAME RVA = DD Relative Virtual Address of the Dll asciiz Name.
+This is the address relative to the Image Base.
+
+ORDINAL BASE = DD First valid exported ordinal.
+This field specifies the starting ordinal number for the export
+address table for this image. Normally set to 1.
+
+# EAT ENTRIES = DD Indicates number of entries in the Export Address
+Table.
+
+# NAME PTRS = DD This indicates the number of entries in the Name Ptr
+Table (and parallel Ordinal Table).
+
+ADDRESS TABLE RVA = DD Relative Virtual Address of the Export Address
+Table.
+This address is relative to the Image Base.
+
+NAME TABLE RVA = DD Relative Virtual Address of the Export Name Table
+Pointers.
+This address is relative to the beginning of the Image Base. This
+table is an array of RVA's with # NAMES entries.
+
+ORDINAL TABLE RVA = DD Relative Virtual Address of Export Ordinals
+Table Entry.
+This address is relative to the beginning of the Image Base.
+
+5.2 Export Address Table
+
+The Export Address Table contains the address of exported entrypoints
+and exported data and absolutes. An ordinal number is used to index
+the Export Address Table. The ORDINAL BASE must be subracted from the
+ordinal number before indexing into this table.
+
+Export Address Table entry formats are described below:
+
+ ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿
+ ³ EXPORTED RVA ³
+ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ
+
+Figure 6. Export Address Table Entry
+
+EXPORTED RVA = DD Export address.
+This field contains the relative virtual address of the exported
+entry (relative to the Image Base).
+
+5.3 Export Name Table Pointers
+
+The export name table pointers array contains address into the Export
+Name Table. The pointers are 32-bits each, and are relative to the
+Image Base. The pointers are ordered lexically to allow binary
+searches.
+
+5.4 Export Ordinal Table
+
+The Export Name Table Pointers and the Export Ordinal Table form two
+parallel arrays, separated to allow natural field alignment. The
+export ordinal table array contains the Export Address Table ordinal
+numbers associated with the named export referenced by corresponding
+Export Name Table Pointers.
+
+The ordinals are 16-bits each, and already include the Ordinal Base
+stored in the Export Directory Table.
+
+5.5 Export Name Table
+
+The export name table contains optional ASCII names for exported
+entries in the image. These tables are used with the array of Export
+Name Table Pointers and the array of Export Ordinals to translate a
+procedure name string into an ordinal number by searching for a
+matching name string. The ordinal number is used to locate the entry
+point information in the export address table.
+
+Import references by name require the Export Name Table Pointers
+table to be binary searched to find the matching name, then the
+corresponding Export Ordinal Table is known to contain the entry
+point ordinal number. Import references by ordinal number provide
+the fastest lookup since searching the name table is not required.
+
+Each name table entry has the following format:
+
+ ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿
+ ³ ASCII STRING ::: :::::::: '\0' ³
+ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ
+
+Figure 7. Export Name Table Entry
+
+ASCII STRING = DB ASCII String.
+The string is case sensitive and is terminated by a null byte.
+
+
+
+6. Imports
+
+A typical file layout for the import information follows:
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ DIRECTORY TABLE ³
+ ³ ³
+ ³ ³
+ ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ NULL DIR ENTRY ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ DLL1 LOOKUP TABLE ³
+ ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ NULL ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ DLL2 LOOKUP TABLE ³
+ ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ NULL ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ Dll3 LOOKUP TABLE ³
+ ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ NULL ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ HINT-NAME TABLE ³
+ ³ ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ DLL1 ADDRESS TABLE ³
+ ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ NULL ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ DLL2 ADDRESS TABLE ³
+ ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ NULL ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ DLL3 ADDRESS TABLE ³
+ ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ NULL ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+Figure 8. Import File Layout
+
+6.1 Import Directory Table
+
+The import information begins with the Import Directory Table which
+describes the remainder of the import information. The Import
+Directory Table contains address information that is used to resolve
+fixup references to the entry points within a DLL image. The import
+directory table consists of an array of Import Directory Entries, one
+entry for each DLL this image references. The last directory entry is
+empty (NULL) which indicates the end of the directory table.
+
+An Import Directory Entry has the following format:
+
+ ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿
+ ³ IMPORT FLAGS ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ TIME/DATE STAMP ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ MAJOR VERSION ³ MINOR VERSION ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ NAME RVA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ IMPORT LOOKUP TABLE RVA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ IMPORT ADDRESS TABLE RVA ³
+ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ
+
+Figure 9. Import Directory Entry
+
+IMPORT FLAGS = DD Currently set to zero.
+
+TIME/DATE STAMP = DD Time/Date the import data was pre-snapped or
+zero if not pre-snapped.
+
+MAJOR/MINOR VERSION = DW The major/minor version number of the dll
+being referenced.
+
+NAME RVA = DD Relative Virtual Address of the Dll asciiz Name.
+This is the address relative to the Image Base.
+
+IMPORT LOOKUP TABLE RVA = DD This field contains the address of the
+start of the import lookup table for this image. The address is
+relative to the beginning of the Image Base.
+
+IMPORT ADDRESS TABLE RVA = DD This field contains the address of the
+start of the import addresses for this image. The address is
+relative to the beginning of the Image Base.
+
+6.2 Import Lookup Table
+
+The Import Lookup Table is an array of ordinal or hint/name RVA's for
+each DLL. The last entry is empty (NULL) which indicates the end of
+the table.
+
+The last element is empty.
+
+ 3 0
+ 1
+ ÚÄÒÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿
+ ³0º ORDINAL#/HINT-NAME TABLE RVA ³
+ ÀÄÐÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ
+
+Figure 10. Import Address Table Format
+
+ORDINAL/HINT-NAME TABLE RVA = 31-bits (mask = 7fffffffh) Ordinal
+Number or Name Table RVA.
+If the import is by ordinal, this field contains a 31 bit ordinal
+number. If the import is by name, this field contains a 31 bit
+address relative to the Image Base to the Hint-Name Table.
+
+O = 1-bit (mask = 80000000h) Import by ordinal flag.
+
+ o 00000000h __Import by name.
+
+ o 80000000h __Import by ordinal.
+
+6.3 Hint-Name Table
+
+The Hint-Name Table format follows:
+
+ ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿
+ ³ HINT ³ ASCII STRING |||³
+ ÃÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄ´
+ ³|||||||||||||||||³ '\0' PAD ³
+ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ
+
+
+ The PAD field is optional.
+
+Figure 11. Import Hint-Name Table
+
+HINT = DW Hint into Export Name Table Pointers.
+The hint value is used to index the Export Name Table Pointers array,
+allowing faster by-name imports. If the hint is incorrect, then a
+binary search is performed on the Export Name Ptr Table.
+
+ASCII STRING = DB ASCII String.
+The string is case sensitive and is terminated by a null byte.
+
+PAD = DB Zero pad byte.
+A trailing zero pad byte appears after the trailing null byte if
+necessary to align the next entry on an even boundary.
+
+The loader overwrites the import address table when loading the image
+with the 32-bit address of the import.
+
+
+
+6.4 Import Address Table
+
+The Import Address Table is an array of addresses of the imported
+routines for each DLL. The last entry is empty (NULL) which indicates
+the end of the table.
+
+7. Thread Local Storage
+
+Thread local storage is a special contiguous block of data. Each
+thread will gets its own block upon creation of the thread.
+
+The file layout for thread local storage follows:
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ DIRECTORY TABLE ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ TLS DATA ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ INDEX VARIABLE ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ CALLBACK ADDRESSES ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+Figure 12. Thread Local Storage Layout
+
+7.1 Thread Local Storage Directory Table
+
+The Thread Local Storage Directory Table contains address information
+that is used to describe the rest of TLS.
+
+The Thread Local Storage Directory Table has the following format:
+
+ ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿
+ ³ START DATA BLOCK VA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ END DATA BLOCK VA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ INDEX VA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ CALLBACK TABLE VA ³
+ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ
+
+Figure 13. Thread Local Storage Directory Table
+
+START DATA BLOCK VA = DD Virtual Address of the start of the thread
+local storage data block.
+
+END DATA BLOCK VA = DD Virtual Address of the end of the thread local
+storage data block.
+
+INDEX VA = DD Virtual Address of the index variable used to access
+the thread local storage data block.
+
+CALLBACK TABLE VA = DD Virtual Address of the callback table.
+
+7.2 Thread Local Storage CallBack Table
+
+The Thread Local Storage Callbacks is an array of Virtual Address of
+functions to be called by the loader after thread creation and thread
+termination. The last entry is empty (NULL) which indicates the end
+of the table.
+
+The Thread Local Storage CallBack Table has the following format:
+
+ ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿
+ ³ FUNCTION1 VA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ FUNCTION2 VA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ NULL ³
+ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ
+
+Figure 14. Thread Local Storage CallBack Table
+
+8. Resources
+
+Resources are indexed by a multiple level binary-sorted tree
+structure. The overall design can incorporate 2**31 levels, however,
+NT uses only three: the highest is TYPE, then NAME, then LANGUAGE.
+
+A typical file layout for the resource information follows:
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ RESOURCE DIRECTORY ³
+ ³ ³
+ ³ ³
+ ³ ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ RESOURCE DATA ³
+ ³ ³
+ ³ ³
+ ³ ³
+ ³ ³
+ ³ ³
+ ³ ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+Figure 15. Resource File Layout
+
+
+The Resource directory is made up of the following tables:
+
+
+
+8.1 Resource Directory Table
+ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿
+³ RESOURCE FLAGS ³
+ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+³ TIME/DATE STAMP ³
+ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+³ MAJOR VERSION ³ MINOR VERSION ³
+ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+³ # NAME ENTRY ³ # ID ENTRY ³
+ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+³ RESOURCE DIR ENTRIES ³
+ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ
+
+Figure 16. Resource Table Entry
+
+
+RESOURCE FLAGS = DD Currently set to zero.
+
+TIME/DATE STAMP = DD Time/Date the resource data was created by the
+resource compiler.
+
+MAJOR/MINOR VERSION = DW A user settable major/minor version number.
+
+# NAME ENTRY = DW The number of name entries.
+This field contains the number of entries at the beginning of the
+array of directory entries which have actual string names associated
+with them.
+
+# ID ENTRY = DW The number of ID integer entries.
+This field contains the number of 32-bit integer IDs as their names
+in the array of directory entries.
+
+The resource directory is followed by a variable length array of
+directory entries. # NAME ENTRY is the number of entries at the
+beginning of the array that have actual names associated with each
+entry. The entires are in ascending order, case insensitive strings.
+# ID ENTRY identifies the number of entries that have 32-bit integer
+IDs as their name. These entries are also sorted in ascending order.
+
+This structure allows fast lookup by either name or number, but for
+any given resource entry only one form of lookup is supported, not
+both. This is consistent with the syntax of the .RC file and the .RES
+file.
+
+
+
+The array of directory entries have the following format:
+ 3 0
+ 1
+ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿
+³ NAME RVA/INTEGER ID ³
+ÃÄÒÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+³Eº DATA ENTRY RVA/SUBDIR RVA ³
+ÀÄÐÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ
+
+Figure 17. Resource Directory Entry
+
+
+INTERGER ID = DD ID.
+This field contains a integer ID field to identify a resource.
+
+NAME RVA = DD Name RVA address.
+This field contains a 31-bit address relative to the beginning of the
+Image Base to a Resource Directory String Entry.
+
+E = 1-bit (mask 80000000h) Unescape bit.
+This bit is zero for unescaped Resource Data Entries.
+
+DATA RVA = 31-bits (mask 7fffffffh) Data entry address.
+This field contains a 31-bit address relative to the beginning of the
+Image Base to a Resource Data Entry.
+
+E = 1-bit (mask 80000000h) Escape bit.
+This bit is 1 for escaped Subdirectory Entry.
+
+DATA RVA = 31-bits (mask 7fffffffh) Directory entries.
+This field contains a 31-bit address relative to the beginning of the
+Image Base to Subdirectory Entry.
+
+
+
+Each resource directory string entry has the following format:
+ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿
+³ LENGTH ³ UNICODE STRING ³
+ÃÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄ´
+³ ³
+ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ
+
+Figure 18. Resource Directory String Entry
+
+
+LENGTH = DW Length of string.
+
+UNICODE STRING = DW UNICODE String.
+
+All of these string objects are stored together after the last
+resource directory entry and before the first resource data object.
+This minimizes the impact of these variable length objects on the
+alignment of the fixed size directory entry objects. The length needs
+to be word aligned.
+
+
+
+Each Resource Data Entry has the following format:
+
+ ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿
+ ³ DATA RVA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ SIZE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ CODEPAGE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ RESERVED ³
+ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ
+
+Figure 19. Resource Data Entry
+
+
+
+DATA RVA = DD Address of Resource Data.
+This field contains 32-bit virtaul address of the resource data
+(relative to the Image Base).
+
+SIZE = DD Size of Resource Data.
+This field contains the size of the resource data for this resource.
+
+CODEPAGE = DD Codepage.
+
+RESERVED = DD Reserved - must be zero.
+
+Each resource data entry describes a leaf node in the resource
+directory tree. It contains an address which is relative to the
+beginning of Image Base, a size field that gives the number of bytes
+of data at that address, a CodePage that should be used when decoding
+code point values within the resource data. Typically for new
+applications the code page would be the unicode code page.
+
+
+
+8.2 Resource Example
+
+The following is an example for an app. which wants to use the following data
+as resources:
+
+ TypeId# NameId# Language ID Resource Data
+ 00000001 00000001 0 00010001
+ 00000001 00000001 1 10010001
+ 00000001 00000002 0 00010002
+ 00000001 00000003 0 00010003
+ 00000002 00000001 0 00020001
+ 00000002 00000002 0 00020002
+ 00000002 00000003 0 00020003
+ 00000002 00000004 0 00020004
+ 00000009 00000001 0 00090001
+ 00000009 00000009 0 00090009
+ 00000009 00000009 1 10090009
+ 00000009 00000009 2 20090009
+
+Then the Resource Directory in the Portable format looks like:
+Offset Data
+0000: 00000000 00000000 00000000 00030000 (3 entries in this directory)
+0010: 00000001 80000028 (TypeId #1, Subdirectory at offset 0x28)
+0018: 00000002 80000050 (TypeId #2, Subdirectory at offset 0x50)
+0020: 00000009 80000080 (TypeId #9, Subdirectory at offset 0x80)
+0028: 00000000 00000000 00000000 00030000 (3 entries in this directory)
+0038: 00000001 800000A0 (NameId #1, Subdirectory at offset 0xA0)
+0040: 00000002 00000108 (NameId #2, data desc at offset 0x108)
+0048: 00000003 00000118 (NameId #3, data desc at offset 0x118)
+0050: 00000000 00000000 00000000 00040000 (4 entries in this directory)
+0060: 00000001 00000128 (NameId #1, data desc at offset 0x128)
+0068: 00000002 00000138 (NameId #2, data desc at offset 0x138)
+0070: 00000003 00000148 (NameId #3, data desc at offset 0x148)
+0078: 00000004 00000158 (NameId #4, data desc at offset 0x158)
+0080: 00000000 00000000 00000000 00020000 (2 entries in this directory)
+0090: 00000001 00000168 (NameId #1, data desc at offset 0x168)
+0098: 00000009 800000C0 (NameId #9, Subdirectory at offset 0xC0)
+00A0: 00000000 00000000 00000000 00020000 (2 entries in this directory)
+00B0: 00000000 000000E8 (Language ID 0, data desc at offset 0xE8
+00B8: 00000001 000000F8 (Language ID 1, data desc at offset 0xF8
+00C0: 00000000 00000000 00000000 00030000 (3 entries in this directory)
+00D0: 00000001 00000178 (Language ID 0, data desc at offset 0x178
+00D8: 00000001 00000188 (Language ID 1, data desc at offset 0x188
+00E0: 00000001 00000198 (Language ID 2, data desc at offset 0x198
+
+00E8: 000001A8 (At offset 0x1A8, for TypeId #1, NameId #1, Language id #0
+ 00000004 (4 bytes of data)
+ 00000000 (codepage)
+ 00000000 (reserved)
+00F8: 000001AC (At offset 0x1AC, for TypeId #1, NameId #1, Language id #1
+ 00000004 (4 bytes of data)
+ 00000000 (codepage)
+ 00000000 (reserved)
+0108: 000001B0 (At offset 0x1B0, for TypeId #1, NameId #2,
+ 00000004 (4 bytes of data)
+ 00000000 (codepage)
+ 00000000 (reserved)
+0118: 000001B4 (At offset 0x1B4, for TypeId #1, NameId #3,
+ 00000004 (4 bytes of data)
+ 00000000 (codepage)
+ 00000000 (reserved)
+0128: 000001B8 (At offset 0x1B8, for TypeId #2, NameId #1,
+ 00000004 (4 bytes of data)
+ 00000000 (codepage)
+ 00000000 (reserved)
+0138: 000001BC (At offset 0x1BC, for TypeId #2, NameId #2,
+ 00000004 (4 bytes of data)
+ 00000000 (codepage)
+ 00000000 (reserved)
+0148: 000001C0 (At offset 0x1C0, for TypeId #2, NameId #3,
+ 00000004 (4 bytes of data)
+ 00000000 (codepage)
+ 00000000 (reserved)
+0158: 000001C4 (At offset 0x1C4, for TypeId #2, NameId #4,
+ 00000004 (4 bytes of data)
+ 00000000 (codepage)
+ 00000000 (reserved)
+0168: 000001C8 (At offset 0x1C8, for TypeId #9, NameId #1,
+ 00000004 (4 bytes of data)
+ 00000000 (codepage)
+ 00000000 (reserved)
+0178: 000001CC (At offset 0x1CC, for TypeId #9, NameId #9, Language id #0
+ 00000004 (4 bytes of data)
+ 00000000 (codepage)
+ 00000000 (reserved)
+0188: 000001D0 (At offset 0x1D0, for TypeId #9, NameId #9, Language id #1
+ 00000004 (4 bytes of data)
+ 00000000 (codepage)
+ 00000000 (reserved)
+0198: 000001D4 (At offset 0x1D4, for TypeId #9, NameId #9, Language id #2
+ 00000004 (4 bytes of data)
+ 00000000 (codepage)
+ 00000000 (reserved)
+
+And the data for the resources will look like:
+01A8: 00010001
+01AC: 10010001
+01B0: 00010002
+01B4: 00010003
+01B8: 00020001
+01BC: 00020002
+01C0: 00020003
+01C4: 00020004
+01C8: 00090001
+01CC: 00090009
+01D0: 10090009
+01D4: 20090009
+
+
+9. Fixup Table
+
+The Fixup Table contains entries for all fixups in the image. The
+Total Fixup Data Size in the PE Header is the number of bytes in the
+fixup table. The fixup table is broken into blocks of fixups. Each
+block represents the fixups for a 4K page.
+
+Fixups that are resolved by the linker do not need to be processed by
+the loader, unless the load image can't be loaded at the Image Base
+specified in the PE Header.
+
+9.1 Fixup Block
+
+Fixup blocks have the following format:
+
+ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³ PAGE RVA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ BLOCK SIZE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ TYPE/OFFSET ³ TYPE/OFFSET ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ TYPE/OFFSET ³ ... ³
+ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
+
+Figure 20. Fixup Block Format
+
+To apply a fixup, a delta needs to be calculated. The 32-bit delta
+is the difference between the preferred base, and the base where the
+image is actually loaded. If the image is loaded at its preferred
+base, the delta would be zero, and thus the fixups would not have to
+be applied. Each block must start on a DWORD boundary. The ABSOLUTE
+fixup type can be used to pad a block.
+
+PAGE RVA = DD Page RVA. The image base plus the page rva is added to
+each offset to create the virtual address of where the fixup needs to
+be applied.
+
+BLOCK SIZE = DD Number of bytes in the fixup block. This includes the
+PAGE RVA and SIZE fields.
+
+TYPE/OFFSET is defined as:
+
+ 1 1 0
+ 5 1
+ ÚÄÄÄÄÒÄÄÄÄÄÄÄÄÄÄÄÄ¿
+ ³TYPEº OFFSET ³
+ ÀÄÄÄÄÐÄÄÄÄÄÄÄÄÄÄÄÄÙ
+Figure 21. Fixup Record Format
+
+TYPE = 4-bit fixup type. This value has the following definitions:
+
+ o 0h __ABSOLUTE. This is a NOP. The fixup is skipped.
+
+ o 1h __HIGH. Add the high 16-bits of the delta to the 16-bit field
+ at Offset. The 16-bit field represents the high value of a 32-
+ bit word.
+
+ o 2h __LOW. Add the low 16-bits of the delta to the 16-bit field
+ at Offset. The 16-bit field represents the low half value of a
+ 32-bit word. This fixup will only be emitted for a RISC machine
+ when the image Object Align isn't the default of 64K.
+
+ o 3h __HIGHLOW. Apply the 32-bit delta to the 32-bit field at
+ Offset.
+
+ o 4h __HIGHADJUST. This fixup requires a full 32-bit value. The
+ high 16-bits is located at Offset, and the low 16-bits is
+ located in the next Offset array element (this array element is
+ included in the SIZE field). The two need to be combined into a
+ signed variable. Add the 32-bit delta. Then add 0x8000 and
+ store the high 16-bits of the signed variable to the 16-bit
+ field at Offset.
+
+ o 5h __MIPSJMPADDR.
+
+All other values are reserved.
+
+
+
+10. Debug Information
+
+The debug information is defined by the debugger and is not
+controlled by the portable EXE format or linker. The only data
+defined by the portable EXE format is the Debug Directory Table.
+
+10.1 Debug Directory
+
+The debug directory table consists of one or more entries that have
+the following format:
+
+ ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿
+ ³ DEBUG FLAGS ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ TIME/DATE STAMP ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ MAJOR VERSION ³ MINOR VERSION ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ DEBUG TYPE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ DATA SIZE ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ DATA RVA ³
+ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
+ ³ DATA SEEK ³
+ ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ
+
+Figure 22. Debug Directory Entry
+
+DEBUG FLAGS = DD Set to zero for now.
+
+TIME/DATE STAMP = DD Time/Date the debug data was created.
+
+MAJOR/MINOR VERSION = DW Version stamp.
+This stamp can be used to determine the version of the debug data.
+
+DEBUG TYPE = DD Format type.
+To support multiple debuggers, this field determines the format of
+the debug information. This value has the following definitions:
+
+ o 0001h __Image contains COFF symbolics.
+
+ o 0001h __Image contains CodeView symbolics.
+
+ o 0001h __Image contains FPO symbolics.
+
+DATA SIZE = DD The number of bytes in the debug data. This is the
+size of the actual debug data and does not include the debug
+directory.
+
+DATA RVA = DD The relative virtual address of the debug data. This
+address is relative to the beginning of the Image Base.
+
+DATA SEEK = DD The seek value from the beginning of the file to the
+debug data.
+
+If the image contains more than one type of debug information, then
+the next debug directory will immediately follow the first debug
+directory.
projects / reactos.git / blobdiff