The .bf and .ef symbol records (but not .lf records) are followed by an auxiliary record with the following format:

5.5.3 Auxiliary Format 3: Weak Externals

"Weak externals" are a mechanism for object files allowing flexibility at link time. A module can contain an unresolved external symbol (sym1), but it can also include an auxiliary record indicating that if sym1 is not present at link time, another external symbol (sym2) is used to resolve references instead.

If a definition of sym1 is linked, then an external reference to the symbol is resolved normally. If a definition of sym1 is not linked, then all references to the weak external for sym1 refer to sym2 instead. The external symbol, sym2, must always be linked; typically it is defined in the module containing the weak reference to sym1.

Weak externals are represented by a Symbol Table record with EXTERNAL storage class, UNDEF section number, and a value of 0. The weak-external symbol record is followed by an auxiliary record with the following format:

Note that the Characteristics field is not defined in WINNT.H; instead, the Total Size field is used.

5.5.4 Auxiliary Format 4: Files

This format follows a symbol-table record with storage class FILE (103). The symbol name itself should be .file, and the auxiliary record that follows it gives the name of a source-code file.

5.5.5 Auxiliary Format 5: Section Definitions

This format follows a symbol-table record that defines a section: such a record has a symbol name that is the name of a section (such as .text or .drectve) and has storage class STATIC (3). The auxiliary record provides information on the section referred to. Thus it duplicates some of the information in the section header.

5.5.6 COMDAT Sections (Object Only)

The Selection field of the Section Definition auxiliary format is applicable if the section is a COMDAT section: a section that can be defined by more than one object file. (The flag IMAGE_SCN_LNK_COMDAT is set in the Section Flags field of the section header.) The Selection field determines the way that the linker resolves the multiple definitions of COMDAT sections.

The first symbol having the section value of the COMDAT section must be the section symbol. This symbol has the name of the section, Value field equal to 0, the section number of the COMDAT section in question, Type field equal to IMAGE_SYM_TYPE_NULL, Class field equal to IMAGE_SYM_CLASS_STATIC, and one auxiliary record. The second symbol is called "the COMDAT symbol" and is used by the linker in conjunction with the Selection field.

Values for the Selection field are shown below.

5.6. COFF String Table

Immediately following the COFF symbol table is the COFF string table. The position of this table is found by taking the symbol table address in the COFF header, and adding the number of symbols multiplied by the size of a symbol.

At the beginning of the COFF string table are 4 bytes containing the total size (in bytes) of the rest of the string table. This size includes the size field itself, so that the value in this location would be 4 if no strings were present.

Following the size are null-terminated strings pointed to by symbols in the COFF symbol table.

5.7 The Attribute Certificate Table (Image Only)

Attribute Certificates may be associated with an image by adding an Attribute Certificate Table. There are a number of different types of Attribute Certificates. The meaning and use of each certificate type is not covered in this document. For this information see the Microsoft Distributed System Architecture, Attribute Certificate Architecture Specification.

An Attribute Certificate Table is added at the end of the image, with only a .debug section following (if a .debug section is present). The Attribute Certificate Table contains one or more fixed length table entries which can be found via the Certificate Table field of the Optional Header Data Directories list (offset 128). Each entry of this table identifies the beginning location and length of a corresponding certificate. There is one Certificate Table entry for each certificate stored in this section. The number of entries in the certificate table can be calculated by dividing the size of the certificate table (found in offset 132) by the size of an entry in the certificate table (8). Note that the size of the certificate table includes only the table entries, not the actual certificates which the table entries, in turn, point to.

The format of each table entry is:

Notice that certificates always start on an octaword boundary. If a certificate is not an even number of octawords long, it is zero padded to the next octaword boundary. However, the length of the certificate does not include this padding and so any certificate navigation software must be sure to round up to the next octaword to locate another certificate.

5.7.1 Certificate Data

This is the binary data representing an Attribute Certificate. The format and meaning of each certificate is defined in Attribute Certificate Architecture Specification. The certificate starting location and length is specified by an entry in the Certificate Table. Each certificate is represented by a single Certificate Table entry.

5.8 Delay-Load Import Tables (Image Only)

These tables were added to the image in order to support a uniform mechanism for applications to delay the loading of a dll until the first call into that dll. The layout of the tables matches that of the traditional import tables (see Section "6.4. The .idata Section" for details), so only a few details will be discussed here.

5.8.1 The Delay-Load Directory Table

The Delay-Load Directory Table is the counterpart to the Import Directory Table, and can be retrieved via the Delay Import Descriptor entry in the Optional Header Data Directories list (offset 200). The Table is arranged as follows:

The tables referenced in this data structure are organized and sorted just as their counterparts are for traditional imports. See Section "Section 6.4. The .idata Section" for details.

5.8.2 Attributes

As yet, there are no attribute flags defined. This field is currently set to zero by the linker in the image. This field can be used to extend the record by indicating the presence of new fields or for indicating behaviors to the delay and/or unload helper functions.

5.8.3 Name

The name of the DLL to be delay loaded resides in the read-only data section of the image and is referenced via the szName field.

5.8.4 Module handle

The handle of the DLL to be delay loaded is located in the data section of the image and pointed to via the phmod field. The supplied delay load helper uses this location to store the handle to the loaded DLL.

5.8.5 Delay Import Address Table (IAT)

The delay IAT is referenced by the delay import descriptor via the pIAT field. This is the working copy of the entry point function pointers that resides in the data section of the image and initially refer to the delay load thunks. The delay load helper is responsible for updating these pointers with the real entry points so that the thunks are no longer in the calling loop. The function pointers are access via the expression pINT->u1.Function.

5.8.6 Delay Import Name Table (INT)

The delay INT has the names of the imports that may need to be loaded. They are ordered in the same fashion as the function pointers in the IAT. They consist of the same structures as the standard INT and are accessed via the expression pINT->u1.AddressOfData->Name[0].

5.8.7 Delay Bound Import Address Table (BIAT) and Time Stamp

The delay BIAT is an optional table of IMAGE_THUNK_DATA items that is used along with the timestamp field by a post process binding phase.

5.8.8 Delay Unload Import Address Table (UIAT)

The delay UIAT is an optional table of IMAGE_THUNK_DATA items that is used by the unload code to handle an explicit unload request. It is initialized data in the read-only section that is an exact copy of the original IAT that referred the code to the delay load thunks. On the unload request, the library can be freed, the *phmod cleared, and the UIAT written over the IAT to restore everything to its pre-load state.

6. Special Sections

Typical COFF sections contain code or data that linkers and Win32 loaders process without special knowledge of the sections' contents. The contents are relevant only to the application being linked or executed.

However, some COFF sections have special meanings when found in object files and/or image files. Tools and loaders recognize these sections because they have special flags set in the section header, or because they are pointed to from special locations in the image optional header, or because the section name is "magic": that is, the name indicates a special function of the section. (Even where the section name is not magic, the name is dictated by convention, so we will refer to a name.)

Some of the sections listed here are marked "(object only)" or "(image only)" to indicate that their special semantics are relevant only for object files or image files, respectively. A section that says "(image only)" may still appear in an object file as a way of getting into the image file, but the section has no special meaning to the linker, only to the image file loader.

6.1 The .debug Section

The .debug section is used in object files to contain compiler-generated debug information, and in image files to contain the total debug information generated. This section describes the packaging of debug information in object and image files. The actual format of CodeView debug information is not described here. See the document CV4 Symbolic Debug Information Specification.

The next section describes the format of the debug directory, which can be anywhere in the image. Subsequent sections describe the "groups" in object files that contain debug information.

The default for the linker is that debug information is not mapped into the address space of the image. A .debug section exists only when debug information is mapped in the address space.

6.1.1 Debug Directory (Image Only)

Image files contain an optional "debug directory" indicating what form of debug information is present and where it is. This directory consists of an array of "debug directory entries" whose location and size are indicated in the image optional header.

The debug directory may be in a discardable .debug section (if one exists) or it may be included in any other section in the image file, or not in a section at all.

Each debug directory entry identifies the location and size of a block of debug information. The RVA specified may be 0 if the debug information is not covered by a section header (i.e., it resides in the image file and is not mapped into the run-time address space). If it is mapped, the RVA is its address.

Here is the format of a debug directory entry:

6.1.2 Debug Type

The following values are defined for the Debug Type field of the debug directory:

If Debug Type is set to IMAGE_DEBUG_TYPE_FPO, the debug raw data is an array in which each member describes the stack frame of a function. Not every function in the image file need have FPO information defined for it, even though debug type is FPO. Those functions that do not have FPO information are assumed to have normal stack frames. The format for FPO information is defined as follows:

#define FRAME_FPO   0
#define FRAME_TRAP  1
#define FRAME_TSS   2


typedef struct _FPO_DATA {
    DWORD       ulOffStart;            // offset 1st byte of function code
    DWORD       cbProcSize;            // # bytes in function
    DWORD       cdwLocals;             // # bytes in locals/4
    WORD        cdwParams;             // # bytes in params/4


    WORD        cbProlog : 8;          // # bytes in prolog
    WORD        cbRegs   : 3;          // # regs saved
    WORD        fHasSEH  : 1;          // TRUE if SEH in func
    WORD        fUseBP   : 1;          // TRUE if EBP has been allocated
    WORD        reserved : 1;          // reserved for future use
    WORD        cbFrame  : 2;          // frame type
} FPO_DATA;

6.1.3 .debug$F (Object Only)

Object files can contain .debug$F sections whose contents are one or more FPO_DATA
records (Frame Pointer Omission information). See "IMAGE_DEBUG_TYPE_FPO" in table above.

The linker recognizes these .debug$F records. If debug information is being generated, the linker sorts the FPO_DATA records by procedure RVA, and generates a debug directory entry for them.

The compiler should not generate FPO records for procedures that have a standard frame format.

6.1.4 .debug$S (Object Only)

This section contains CV4 symbolic information: a stream of CV4 symbol records as described in the CV4 spec.

6.1.5 .debug$T (Object Only)

This section contains CV4 type information: a stream of CV4 type records as described in the CV4 spec.

6.1.6 Linker Support for Microsoft CodeView® Debug Information

To support CodeView debug information, the linker:

• Generates the header and "NB05" signature.
• Packages the header with .debug$S and .debug$T sections from object files and synthetic (linker-generated) CV4 information, and creates a debug directory entry.
• Generates the subsection directory containing a pointer to each known subsection, including subsections that are linker-generated.
• Generates the sstModules subsection, which specifies the address and size of each module's contribution(s) to the image address space.
• Generates the sstSegMap subsection, which specifies the address and size of each section in the image.
• Generates the sstPublicSym subsection, which contains the name and address of all externally defined symbols. (A symbol may be represented both by .debug$S information and by an sstPublicSym entry.)

6.2 The .drectve Section (Object Only)

A section is a "directive" section if it has the IMAGE_SCN_LNK_INFO flag set in the section header. By convention, such a section also has the name .drectve. The linker removes a .drectve section after processing the information, so the section does not appear in the image file being linked. Note that a section marked with IMAGE_SCN_LNK_INFO that is not named .drectve is ignored and discarded by the linker.

A .drectve section consists of a string of ASCII text. This string is a series of linker options (each option containing hyphen, option name, and any appropriate attribute) separated by spaces. The .drectve section must not have relocations or line numbers.

In a .drectve section, if the hyphen preceding an option is followed by a question mark (for example, "-?export"), and the option is not recognized as a valid directive, the linker must ignore it. This allows compilers and linkers to add new directives while maintaining compatibility with existing linkers, as long as the new directives are not required for the correct linking of the application. For example, if the directive enables a link-time optimization, it is acceptable if some linkers cannot recognize it.

6.3 The .edata Section (Image Only)

The export data section, named .edata, contains information about symbols that other images can access through dynamic linking. Exports are generally found in DLLs, but DLLs can import symbols as well.

An overview of the general structure of the export section is described below. The tables described are generally contiguous in the file and present in the order shown (though this is not strictly required). Only the Directory Table and Address Table are necessary for exporting symbols as ordinals. (An ordinal is an export accessed directly as an Export Address Table index.) The Name Pointer Table, Ordinal Table, and Export Name Table all exist to support use of export names.

When another image file imports a symbol by name, the Name Pointer Table is searched for a matching string. If one is found, the associated ordinal is then determined by looking at the corresponding member in the Ordinal Table (that is, the member of the Ordinal Table with the same index as the string pointer found in the Name Pointer Table). The resulting ordinal is an index into the Export Address Table, which gives the actual location of the desired symbol. Every export symbol can be accessed by an ordinal.

Direct use of an ordinal is therefore more efficient, because it avoids the need to search the Name Pointer Table for a matching string. However, use of an export name is more mnemonic and does not require the user to know the table index for the symbol.

6.3.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 fix-up references to the entry points within this image.

6.3.2 Export Address Table

The Export Address Table contains the address of exported entry points and exported data and absolutes. An ordinal number is used to index the Export Address Table, after subtracting the value of the Ordinal Base field to get a true, zero-based index. (Thus, if the Ordinal Base is set to 1, a common value, an ordinal of 6 is the same as a zero-based index of 5.)

Each entry in the Export Address Table is a field that uses one of two formats, as shown in the following table. If the address specified is not within the export section (as defined by the address and length indicated in the Optional Header), the field is an Export RVA: an actual address in code or data. Otherwise, the field is a Forwarder RVA, which names a symbol in another DLL.

A Forwarder RVA exports a definition from some other image, making it appear as if it were being exported by the current image. Thus the symbol is simultaneously imported and exported.

For example, in KERNEL32.DLL in Windows NT, the export named "HeapAlloc" is forwarded to the string "NTDLL.RtlAllocateHeap". This allows applications to use the NT-specific module "NTDLL.DLL" without actually containing import references to it. The application's import table references only "KERNEL32.DLL." Therefore, the application is not specific to Windows NT and can run on any Win32 system.

6.3.3 Export Name Pointer Table

The Export Name Pointer Table is an array of addresses (RVAs) 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.

An export name is defined only if the Export Name Pointer Table contains a pointer to it.

6.3.4 Export Ordinal Table

The Export Ordinal Table is an array of 16-bit indexes into the Export Address Table. The ordinals are biased by the Ordinal Base field of the Export Directory Table. In other words, the Ordinal Base must be subtracted from the ordinals to obtain true indexes into the Export Address Table.

The Export Name Pointer Table and the Export Ordinal Table form two parallel arrays, separated to allow natural field alignment. These two tables, in effect, operate as one table, in which the Export Name Pointer "column" points to a public (exported) name, and the Export Ordinal "column" gives the corresponding ordinal for that public name. A member of the Export Name Pointer Table and a member of the Export Ordinal Table are associated by having the same position (index) in their respective arrays.

Thus, when the Export Name Pointer Table is searched and a matching string is found at position i, the algorithm for finding the symbol's address is:

i = Search_ExportNamePointerTable (ExportName);
ordinal = ExportOrdinalTable [i];
SymbolRVA = ExportAddressTable [ordinal - OrdinalBase];

6.3.5 Export Name Table

The Export Name Table contains the actual string data pointed to by the Export Name Pointer Table. The strings in this table are public names that can be used by other images to import the symbols; these public export names are not necessarily the same as the (private) symbol names that the symbols have in their own image file and source code, although they can be.

Every exported symbol has an ordinal value, which is just the index into the Export Address Table (plus the Ordinal Base value). Use of export names, however, is optional. Some, all, or none of the exported symbols can have export names. For those exported symbols that do have export names, corresponding entries in the Export Name Pointer Table and Export Ordinal Table work together to associate each name with an ordinal.

The structure of the Export Name Table is a series of ASCII strings, of variable length, each null terminated.

6.4 The .idata Section

All image files that import symbols, including virtually all .EXE files, have an .idata section. A typical file layout for the import information follows:

Figure 3. Typical Import Section Layout

6.4.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 fix-up 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 the image references. The last directory entry is empty (filled with null values), which indicates the end of the directory table.

Each Import Directory entry has the following format:

6.4.2 Import Lookup Table

An Import Lookup Table is an array of 32-bit numbers, each using the bit-field format described below, in which bit 31 is the most significant bit. The collection of these entries describes all imports from the image to a given DLL. The last entry is set to zero (NULL) to indicate end of the table.

The lower 31 bits can be masked as 0x7FFFFFFF. In either case, the resulting number is a 32-bit integer or pointer in which the high bit is always zero (zero extension to 32 bits).

6.4.3 Hint/Name Table

One Hint/Name Table suffices for the entire import section. Each entry in the Hint/Name Table has the following format:

6.4.4 Import Address Table

The structure and content of the Import Address Table are identical to that of the Import Lookup Table, until the file is bound. During binding, the entries in the Import Address Table are overwritten with the 32-bit addresses of the symbols being imported: these addresses are the actual memory addresses of the symbols themselves (although technically, they are still called "virtual addresses"). The processing of binding is typically performed by the loader.

6.5 The .reloc Section (Image Only)

The Fix-Up Table contains entries for all fixups in the image. The Total Fix-Up Data Size in the Optional 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. Each block must start on a 32-bit boundary.

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.

6.5.1 Fixup Block

Each fixup block starts with the following structure:

The Block Size field is then followed by any number of Type/Offset entries. Each entry is a word (2 bytes) and has the following structure:

To apply a fixup, a delta is calculated as the difference between the preferred base address, 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.

6.5.2 Fixup Types

6.6 The .tls Section

The .tls section provides direct PE/COFF support for static Thread Local Storage (TLS). TLS is a special storage class supported by Windows NT, in which a data object is not an automatic (stack) variable, yet it is local to each individual thread that runs the code. Thus, each thread can maintain a different value for a variable declared using TLS.

Note that any amount of TLS data can be supported by using the API calls TlsAlloc, TlsFree, TlsSetValue, and TlsGetValue. The PE/COFF implementation is an alternative approach to using the API, and it has the advantage of being simpler from the high-level-language programmer's point of view. This implementation enables TLS data to be defined and initialized in a manner similar to ordinary static variables in a program. For example, in Microsoft Visual C++, a static TLS variable can be defined as follows, without using the Windows API:

__declspec (thread) int tlsFlag = 1;

To support this programming construct, the PE/COFF .tls section specifies the following information: initialization data, callback routines for per-thread initialization and termination, and the TLS index, explained in the following discussion.

Note: Statically declared TLS data objects can be used only in statically loaded image files. This fact makes it unreliable to use static TLS data in a DLL unless you know that the DLL, or anything statically linked with it, will never be loaded dynamically with the LoadLibrary API function.

Executable code accesses a static TLS data object through the following steps:

1. At link time, the linker sets the Address of Index field of the TLS Directory. This field points to a location where the program will expect to receive the TLS index.
   
   
2. The Microsoft run-time library facilitates this process by defining a memory image of the TLS Directory and giving it the special name "__tls_used" (Intel x86 platforms) or "_tls_used" (other platforms). The linker looks for this memory image and uses the data there to create the TLS Directory. Other compilers that support TLS and work with the Microsoft linker must use this same technique.
   
   
3. When a thread is created, the loader communicates the address of the thread's TLS array by placing the address of the Thread Environment Block (TEB) in the FS register. A pointer to the TLS array is at the offset of 0x2C from the beginning of TEB. This behavior is Intel x86 specific.
   
   
4. The loader assigns the value of the TLS index to the place indicated by the Address of Index field.
   
   
5. The executable code retrieves the TLS index and also the location of the TLS array.
   
   
6. The code uses the TLS index and the TLS array location (multiplying the index by four and using it as an offset to the array) to get the address of the TLS data area for the given program and module. Each thread has its own TLS data area, but this is transparent to the program, which doesn't need to know how data is allocated for individual threads.
   
   
7. An individual TLS data object is accessed as some fixed offset into the TLS data area.

   The TLS array is an array of addresses that the system maintains for each thread. Each address in this array gives the location of TLS data for a given module (.EXE or DLL) within the program. The TLS index indicates which member of the array to use. (The index is a number, meaningful only to the system, that identifies the module).

6.6.1 The TLS Directory

The TLS Directory has the following format:

6.6.2 TLS Callback Functions

The program can provide one or more TLS callback functions (though Microsoft compilers do not currently use this feature) to support additional initialization and termination for TLS data objects. A typical reason to use such a callback function would be to call constructors and destructors for objects.

Although there is typically no more than one callback function, a callback is implemented as an array to make it possible to add additional callback functions if desired. If there is more than one callback function, each function is called in the order its address appears in the array. A null pointer terminates the array. It is perfectly valid to have an empty list (no callback supported), in which case the callback array has exactly one member—a null pointer.

The prototype for a callback function (pointed to by a pointer of type PIMAGE_TLS_CALLBACK) has the same parameters as a DLL entry-point function:

6.7 The .rsrc Section

Resources are indexed by a multiple level binary-sorted tree structure. The general design can incorporate 2**31 levels. By convention, however, Windows NT uses three levels:

A series of Resource Directory Tables relate all the levels in the following way: each directory table is followed by a series of directory entries, which give the name or ID for that level (Type, Name, or Language level) and an address of either a data description or another directory table. If a data description is pointed to, then the data is a leaf in the tree. If another directory table is pointed to, then that table lists directory entries at the next level down.

A leaf's Type, Name, and Language IDs are determined by the path taken, through directory tables, to reach the leaf. The first table determines Type ID, the second table (pointed to by the directory entry in the first table) determines Name ID, and the third table determines Language ID.

The general structure of the .rsrc section is:

6.7.1 Resource Directory Table

Each Resource Directory Table has the following format. This data structure should be considered the heading of a table, because the table actually consists of directory entries (see next section) as well as this structure:

6.7.2 Resource Directory Entries

The directory entries make up the rows of a table. Each Resource Directory Entry has the following format. Note that whether the entry is a Name or ID entry is indicated by the Resource Directory Table, which indicates how many Name and ID entries follow it (remember that all the Name entries precede all the ID entries for the table). All entries for the table are sorted in ascending order: the Name entries by case-insensitive string, and the ID entries by numeric value.

6.7.3 Resource Directory String

The Resource Directory String area consists of Unicode strings, which are word aligned. These strings are stored together after the last Resource Directory Entry and before the first Resource Data Entry. This minimizes the impact of these variable length strings on the alignment of the fixed-size directory entries. Each Resource Directory String has the following format:

6.7.4 Resource Data Entry

Each Resource Data Entry describes an actual unit of raw data in the Resource Data area, and has the following format:

6.7.5 Resource Example

The resource example shows the PE/COFF representation of the following resource data:

TypeId#NameId#Language ID Resource Data
11000010001
11110010001
12000010002
13000010003
21000020001
22000020002
23000020003
24000020004
91000090001
99000090009
99110090009
99220090009

When this data is encoded, a dump of the PE/COFF Resource Directory results in the following output:

OffsetData
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)
0000000(reserved)
0198:000001D4(At offset 0x1D4, for TypeId #9, NameId #9, Language id #2
00000004(4 bytes of data)
00000000(codepage)
00000000(reserved)

6.8 The .textbss Section (Image Only)

This section closely resembles the .bss section in that it contains unitialized data (code), which therefore requires no space in the disk image. It serves as padding in order to support tools that may need additional space at runtime in the executable section of the image. The attributes for this section match those of the .text section, except for the addition of the uninitialized data flag. The linker generates this section at the compiler's request.

7. Archive (Library) File Format

The COFF archive format provides a standard mechanism for storing collections of object files. These collections are frequently referred to as "libraries" in programming documentation.

The first eight bytes of an archive consist of the file signature. The rest of the archive consists of a series of archive members, as follows:

• The first and second members are "linker members." Each has of these members has its own format as described in Section 8.3. Typically, a linker places information into these archive members. The linker members contain the directory of the archive.
• The third member is the longnames member. This member consists of a series of null-terminated ASCII strings, in which each string is the name of another archive member.
• The rest of the archive consists of standard (object-file) members. Each of these members contains the contents of one object file in its entirety.

An archive member header precedes each member. The following illustration shows the general structure of an archive:

7.1 Archive File Signature

The archive file signature identifies the file type. Any utility (for example, a linker) expecting an archive file as input can check the file type by reading this signature. The signature consists of the following ASCII characters, in which each character below is represented literally, except for the newline (\n) character:

!<arch>\n

7.2 Archive Member Headers

Each member (linker, longnames, or object-file member) is preceded by a header. An archive member header has the following format, in which each field is an ASCII text string that is left-justified and padded with spaces to the end of the field. There is no terminating null character in any of these fields.

Each member header starts on the first even address after the end of the previous archive member.

The Name field has one of the formats shown in the following table. As mentioned above, each of these strings is left justified and padded with trailing spaces within a field of 16 bytes:

7.3 First Linker Member

The name of the first linker member is "\". The first linker member, which is included for backward compatibility, is not used by current linkers but its format must be correct. This linker member provides a directory of symbol names, as does the second linker member. For each symbol, the information indicates where to find the archive member that contains the symbol.

The first linker member has the following format. This information appears after the header:

The elements in the Offsets array must be arranged in ascending order. This fact implies that the symbols listed in the String Table must be arranged according to the order of archive members. For example, all the symbols in the first object-file member would have to be listed before the symbols in the second object file.

7.4 Second Linker Member

The second linker member has the name "\" as does the first linker member. Although both the linker members provide a directory of symbols and archive members that contain them, the second linker member is used in preference to the first by all current linkers. The second linker member includes symbol names in lexical order, which enables faster searching by name.

The first second member has the following format. This information appears after the header:

7.5 Longnames Member

The name of the longnames member is "\\". The longnames member is a series of strings of archive member names. A name appears here only when there is insufficient room in the Name field (16 bytes). The longnames member can be empty, though its header must appear.

The strings are null-terminated. Each string begins immediately after the null byte in the previous string.

8. Import Library Format

Traditional import libraries, i.e., libraries that describe the exports from one image for use by another, typically follow the layout described in 7. Archive (Library) File Format. The primary difference is that import library members contain pseudo-object files instead of real ones, where each member includes the section contributions needed to build the Import Tables described in Section 6.4. The .idata Section. The linker generates this archive while building the exporting application.

The section contributions for an import can be inferred from a small set of information. The linker can either generate the complete, verbose information into the import library for each member at the time of the library’s creation, or it can write only the canonical information to the library and let the application that later uses it generate the necessary data on-the-fly.

In an import library with the long format, a single member contains the following information:

     Archive member header
     File header
     Section headers
     Data corresponding to each of the section headers COFF symbol table
     Strings

In contrast a short import library is written as follows:

     Archive member header
     Import header
     Null-terminated import name string
     Null-terminated dll name string

This is sufficient information to accurately reconstruct the entire contents of the member at the time of its use.

8.1 Import Header

The import header contains the following fields and offsets:

This structure is followed by two null-terminated strings describing the imported symbol's name, and the dll from which it came.

8.2 Import Type

The following values are defined for the Type field in the Import Header:

These values are used to determine which section contributions must be generated by the tool using the library if it must access that data.

8.3 Import Name Type

The null-terminated import symbol name immediately follows its associated Import Header. The following values are defined for the Name Type field in the Import Header, indicating how the name is to be used to generate the correct symbols representing the import:

Appendix: Example Object File

This section describes the PE/COFF object file produced by compiling the file HELLO2.C, which contains the following small C program:

main(
{
foo();
}

foo()
{
}

The commands used to compile HELLO.C (with debug information) and generate this example were the following (the -Gy option to the compiler is used, which causes each procedure to be generated as a separate COMDAT section):

cl -c -Zi -Gy hello2.c

link -dump -all hello2.obj >hello2.dmp

Here is the resulting file HELLO2.DMP: (The reader is encouraged to experiment with various other examples, in order to clarify the concepts described in this specification.)

Dump of file hello2.ob

File Type: COFF OBJECT

FILE HEADER VALUES
     14C machine (i386)
       7 number of sections
3436E157 time date stamp Sat Oct 04 17:37:43 1997
     2A0 file pointer to symbol table
      1E number of symbols
       0 size of optional header
       0 characteristics

SECTION HEADER #1
.drectve name
       0 physical address
       0 virtual address
      26 size of raw data
     12C file pointer to raw data
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
  100A00 flags
         Info
         Remove
         1 byte align

RAW DATA #1
00000000  2D 64 65 66 61 75 6C 74 | 6C 69 62 3A 4C 49 42 43 -default|lib:LIBC
00000010  20 2D 64 65 66 61 75 6C | 74 6C 69 62 3A 4F 4C 44  -defaul|tlib:OLD
00000020  4E 41 4D 45 53 20                                 NAMES 

   Linker Directives
   -----------------
   -defaultlib:LIBC
   -defaultlib:OLDNAMES

SECTION HEADER #2
.debug$S name
       0 physical address
       0 virtual address
      5C size of raw data
     152 file pointer to raw data
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
42100048 flags
         No Pad
         Initialized Data
         Discardable
         1 byte align
         Read Only

RAW DATA #2
00000000  02 00 00 00 11 00 09 00 | 00 00 00 00 0A 68 65 6C ........|.....hel
00000010  6C 6F 32 2E 6F 62 6A 43 | 00 01 00 05 00 00 00 3C lo2.objC|.......<
00000020  4D 69 63 72 6F 73 6F 66 | 74 20 28 52 29 20 33 32 Microsof|t (R) 32
00000030  2D 62 69 74 20 43 2F 43 | 2B 2B 20 4F 70 74 69 6D -bit C/C|++ Optim
00000040  69 7A 69 6E 67 20 43 6F | 6D 70 69 6C 65 72 20 56 izing Co|mpiler V
00000050  65 72 73 69 6F 6E 20 31 | 31 2E 30 30             version 1|1.00

SECTION HEADER #3
   .text name
       0 physical address
       0 virtual address
       A size of raw data
     1AE file pointer to raw data
     1B8 file pointer to relocation table
     1C2 file pointer to line numbers
       1 number of relocations
       3 number of line numbers
60501020 flags
         Code
         Communal; sym= _main
         16 byte align
         Execute Read

RAW DATA #3
00000000  55 8B EC E8 00 00 00 00 | 5D C3                   U‹ìè....|].

RELOCATIONS #3
                                                Symbol    Symbol
 Offset    Type              Applied To         Index     Name
 --------  ----------------  -----------------  --------  ------
 00000004  REL32                      00000000        13  _foo

LINENUMBERS #3

 Symbol index:        8 Base line number:     2
 Symbol name = _main
 00000003(    3)  00000008(    4)

SECTION HEADER #4
.debug$S name
       0 physical address
       0 virtual address
      30 size of raw data
     1D4 file pointer to raw data

     204 file pointer to relocation table
       0 file pointer to line numbers
       2 number of relocations
       0 number of line numbers
42101048 flags
         No Pad
         Initialized Data
         Communal (no symbol)
         Discardable
         1 byte align
         Read Only

RAW DATA #4
00000000  2A 00 0B 10 00 00 00 00 | 00 00 00 00 00 00 00 00 *.......|........
00000010  0A 00 00 00 03 00 00 00 | 08 00 00 00 01 10 00 00 ........|........
00000020  00 00 00 00 00 00 01 04 | 6D 61 69 6E 02 00 06 00 ........|main....


RELOCATIONS #4
                                                Symbol    Symbol
 Offset    Type              Applied To         Index     Name
 --------  ----------------  -----------------  --------  ------
 00000020  SECREL                     00000000         8  _main
 00000024  SECTION                        0000         8  _main

SECTION HEADER #5
   .text name
       0 physical address
       0 virtual address
       5 size of raw data
     218 file pointer to raw data
       0 file pointer to relocation table
     21D file pointer to line numbers
       0 number of relocations
       2 number of line numbers
60501020 flags
         Code
         Communal; sym= _foo
         16 byte align
         Execute Read

RAW DATA #5
00000000  55 8B EC 5D C3                                    U‹ì].

LINENUMBERS #5

 Symbol index:       13 Base line number:     7
 Symbol name = _foo
 00000003(    8)

SECTION HEADER #6
.debug$S name
       0 physical address
       0 virtual address
      2F size of raw data
     229 file pointer to raw data
     258 file pointer to relocation table
       0 file pointer to line numbers
       2 number of relocations
       0 number of line numbers
42101048 flags
         No Pad
         Initialized Data
         Communal (no symbol)
         Discardable
         1 byte align
         Read Only

RAW DATA #6
00000000  29 00 0B 10 00 00 00 00 | 00 00 00 00 00 00 00 00 ).......|........
00000010  05 00 00 00 03 00 00 00 | 03 00 00 00 01 10 00 00 ........|........
00000020  00 00 00 00 00 00 01 03 | 66 6F 6F 02 00 06 00    ........|foo....

RELOCATIONS #6
                                                Symbol    Symbol
 Offset    Type              Applied To         Index     Name
 --------  ----------------  -----------------  --------  ------
 00000020  SECREL                     00000000        13  _foo
 00000024  SECTION                        0000        13  _foo

SECTION HEADER #7
.debug$T name
       0 physical address

       0 virtual address
      34 size of raw data
     26C file pointer to raw data
       0 file pointer to relocation table

       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers

42100048 flags
         No Pad
         Initialized Data
         Discardable
         1 byte align
         Read Only

RAW DATA #7
00000000  02 00 00 00 2E 00 16 00 | 33 E1 36 34 01 00 00 00 ........|3á64....
00000010  22 65 3A 5C 62 62 74 5C | 74 6F 6F 6C 73 5C 76 63 "e:\bbt\|tools\vc
00000020  35 30 5C 62 69 6E 5C 78 | 38 36 5C 76 63 35 30 2E 50\bin\x|86\vc50.
00000030  70 64 62 F1                                       pdb.

COFF SYMBOL TABLE
000 00000000 DEBUG  notype       Filename     | .file
    hello2.c
002 00000000 SECT1  notype       Static       | .drectve
    Section length   26, #relocs    0, #linenums    0, checksum        0
004 00000000 SECT2  notype       Static       | .debug$S
    Section length   5C, #relocs    0, #linenums    0, checksum        0
006 00000000 SECT3  notype       Static       | .text
    Section length    A, #relocs    1, #linenums    3, checksum        0, selection    1 (pick no duplicates)
008 00000000 SECT3  notype ()    External     | _main
    tag index 0000000A size 0000000A lines 000001C2 next function 00000013
00A 00000000 SECT3  notype       BeginFunction | .bf
    line# 0002 end 00000015
00C 00000003 SECT3  notype       .bf or.ef    | .lf
00D 0000000A SECT3  notype       EndFunction  | .ef
    line# 0004
00F 00000000 SECT4  notype       Static       | .debug$S
    Section length   30, #relocs    2, #linenums    0, checksum        0, selection    5 (pick associative Section 3)
011 00000000 SECT5  notype       Static       | .text
    Section length    5, #relocs    0, #linenums    2, checksum        0, selection    1 (pick no duplicates)
013 00000000 SECT5  notype ()    External     | _foo
    tag index 00000015 size 00000005 lines 0000021D next function 00000000

015 00000000 SECT5  notype       BeginFunction | .bf

    line# 0007 end 00000000
017 00000002 SECT5  notype       .bf or.ef    | .lf
018 00000005 SECT5  notype       EndFunction  | .ef
    line# 0008
01A 00000000 SECT6  notype       Static       | .debug$S
    Section length   2F, #relocs    2, #linenums    0, checksum        0, selection    5 (pick associative Section 5)
01C 00000000 SECT7  notype       Static       | .debug$T
    Section length   34, #relocs    0, #linenums    0, checksum        0

String Table Size = 0x0 bytes

     Summary

          BB .debug$S
          34 .debug$T
          26 .drectve
           F .text

Here is a hexadecimal dump of HELLO2.OBJ:

hello2.obj: 
00000000   4c 01 07 00 57 e1 36 34 a0 02 00 00 1e 00 00 00  L...W.64........
00000010   00 00 00 00 2e 64 72 65 63 74 76 65 00 00 00 00  .....drectve....
00000020   00 00 00 00 26 00 00 00 2c 01 00 00 00 00 00 00  ....&...,.......
00000030   00 00 00 00 00 00 00 00 00 0a 10 00 2e 64 65 62  .............deb
00000040   75 67 24 53 00 00 00 00 00 00 00 00 5c 00 00 00  ug$S........\...
00000050   52 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00  R...............
00000060   48 00 10 42 2e 74 65 78 74 00 00 00 00 00 00 00  H..B.text.......
00000070   00 00 00 00 0a 00 00 00 ae 01 00 00 b8 01 00 00  ................
00000080   c2 01 00 00 01 00 03 00 20 10 50 60 2e 64 65 62  ........ .P`.deb
00000090   75 67 24 53 00 00 00 00 00 00 00 00 30 00 00 00  ug$S........0...
000000a0   d4 01 00 00 04 02 00 00 00 00 00 00 02 00 00 00  ................
000000b0   48 10 10 42 2e 74 65 78 74 00 00 00 00 00 00 00  H..B.text.......
000000c0   00 00 00 00 05 00 00 00 18 02 00 00 00 00 00 00  ................
000000d0   1d 02 00 00 00 00 02 00 20 10 50 60 2e 64 65 62  ........ .P`.deb
000000e0   75 67 24 53 00 00 00 00 00 00 00 00 2f 00 00 00  ug$S......../...
000000f0   29 02 00 00 58 02 00 00 00 00 00 00 02 00 00 00  )...X...........
00000100   48 10 10 42 2e 64 65 62 75 67 24 54 00 00 00 00  H..B.debug$T....
00000110   00 00 00 00 34 00 00 00 6c 02 00 00 00 00 00 00  ....4...l.......
00000120   00 00 00 00 00 00 00 00 48 00 10 42 2d 64 65 66  ........H..B-def
00000130   61 75 6c 74 6c 69 62 3a 4c 49 42 43 20 2d 64 65  aultlib:LIBC -de
00000140   66 61 75 6c 74 6c 69 62 3a 4f 4c 44 4e 41 4d 45  faultlib:OLDNAME
00000150   53 20 02 00 00 00 11 00 09 00 00 00 00 00 0a 68  S .............h
00000160   65 6c 6c 6f 32 2e 6f 62 6a 43 00 01 00 05 00 00  ello2.objC......
00000170   00 3c 4d 69 63 72 6f 73 6f 66 74 20 28 52 29 20  .<Microsoft (R) 
00000180   33 32 2d 62 69 74 20 43 2f 43 2b 2b 20 4f 70 74  32-bit C/C++ Opt
00000190   69 6d 69 7a 69 6e 67 20 43 6f 6d 70 69 6c 65 72  imizing Compiler
000001a0   20 56 65 72 73 69 6f 6e 20 31 31 2e 30 30 55 8b   Version 11.00U.
000001b0   ec e8 00 00 00 00 5d c3 04 00 00 00 13 00 00 00  ......].........
000001c0   14 00 08 00 00 00 00 00 03 00 00 00 01 00 08 00  ................
000001d0   00 00 02 00 2a 00 0b 10 00 00 00 00 00 00 00 00  ....*...........
000001e0   00 00 00 00 0a 00 00 00 03 00 00 00 08 00 00 00  ................
000001f0   01 10 00 00 00 00 00 00 00 00 01 04 6d 61 69 6e  ............main
00000200   02 00 06 00 20 00 00 00 08 00 00 00 0b 00 24 00  .... .........$.
00000210   00 00 08 00 00 00 0a 00 55 8b ec 5d c3 13 00 00  ........U..]....
00000220   00 00 00 03 00 00 00 01 00 29 00 0b 10 00 00 00  .........)......
00000230   00 00 00 00 00 00 00 00 00 05 00 00 00 03 00 00  ................
00000240   00 03 00 00 00 01 10 00 00 00 00 00 00 00 00 01  ................
00000250   03 66 6f 6f 02 00 06 00 20 00 00 00 13 00 00 00  .foo.... .......
00000260   0b 00 24 00 00 00 13 00 00 00 0a 00 02 00 00 00  ..$.............
00000270   2e 00 16 00 33 e1 36 34 01 00 00 00 22 65 3a 5c  ....3.64...."e:\
00000280   62 62 74 5c 74 6f 6f 6c 73 5c 76 63 35 30 5c 62  bbt\tools\vc50\b
00000290   69 6e 5c 78 38 36 5c 76 63 35 30 2e 70 64 62 f1  in\x86\vc50.pdb.
000002a0   2e 66 69 6c 65 00 00 00 00 00 00 00 fe ff 00 00  .file...........
000002b0   67 01 68 65 6c 6c 6f 32 2e 63 00 00 00 00 00 00  g.hello2.c......
000002c0   00 00 00 00 2e 64 72 65 63 74 76 65 00 00 00 00  .....drectve....
000002d0   01 00 00 00 03 01 26 00 00 00 00 00 00 00 00 00  ......&.........
000002e0   00 00 00 00 00 00 00 00 2e 64 65 62 75 67 24 53  .........debug$S
000002f0   00 00 00 00 02 00 00 00 03 01 5c 00 00 00 00 00  ..........\.....
00000300   00 00 00 00 00 00 00 00 00 00 00 00 2e 74 65 78  .............texv
00000310   74 00 00 00 00 00 00 00 03 00 00 00 03 01 0a 00  t...............
00000320   00 00 01 00 03 00 00 00 00 00 00 00 01 00 00 00  ................
00000330   5f 6d 61 69 6e 00 00 00 00 00 00 00 03 00 20 00  _main......... .
00000340   02 01 0a 00 00 00 0a 00 00 00 c2 01 00 00 13 00  ................
00000350   00 00 00 00 2e 62 66 00 00 00 00 00 00 00 00 00  .....bf.........
00000360   03 00 00 00 65 01 00 00 00 00 02 00 00 00 00 00  ....e...........
00000370   00 00 15 00 00 00 00 00 2e 6c 66 00 00 00 00 00  .........lf.....
00000380   03 00 00 00 03 00 00 00 65 00 2e 65 66 00 00 00  ........e..ef...
00000390   00 00 0a 00 00 00 03 00 00 00 65 01 00 00 00 00  ..........e.....
000003a0   04 00 00 00 00 00 00 00 00 00 00 00 00 00 2e 64  ...............d
000003b0   65 62 75 67 24 53 00 00 00 00 04 00 00 00 03 01  ebug$S..........
000003c0   30 00 00 00 02 00 00 00 00 00 00 00 03 00 05 00  0...............
000003d0   00 00 2e 74 65 78 74 00 00 00 00 00 00 00 05 00  ...text.........
000003e0   00 00 03 01 05 00 00 00 00 00 02 00 00 00 00 00  ................
000003f0   00 00 01 00 00 00 5f 66 6f 6f 00 00 00 00 00 00  ......_foo......
00000400   00 00 05 00 20 00 02 01 15 00 00 00 05 00 00 00  .... ...........
00000410   1d 02 00 00 00 00 00 00 00 00 2e 62 66 00 00 00  ...........bf...
00000420   00 00 00 00 00 00 05 00 00 00 65 01 00 00 00 00  ..........e.....
00000430   07 00 00 00 00 00 00 00 00 00 00 00 00 00 2e 6c  ...............l
00000440   66 00 00 00 00 00 02 00 00 00 05 00 00 00 65 00  f.............e.
00000450   2e 65 66 00 00 00 00 00 05 00 00 00 05 00 00 00  .ef.............
00000460   65 01 00 00 00 00 08 00 00 00 00 00 00 00 00 00  e...............
00000470   00 00 00 00 2e 64 65 62 75 67 24 53 00 00 00 00  .....debug$S....
00000480   06 00 00 00 03 01 2f 00 00 00 02 00 00 00 00 00  ....../.........
00000490   00 00 05 00 05 00 00 00 2e 64 65 62 75 67 24 54  .........debug$T
000004a0   00 00 00 00 07 00 00 00 03 01 34 00 00 00 00 00  ..........4.....
000004b0   00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00  ................

Appendix: Calculating Image Message Digests

Several Attribute Certificates are expected to be used to verify the integrity of the images. That is, they will be used to ensure that a particular image file, or part of that image file, has not been altered in any way from its original form. To accomplish this task, these certificates will typically include something called a Message Digest.

Message digests are similar to a file checksum in that they produce a small value that relates to the integrity of a file. A checksum is produced by a simple algorithm and its use is primarily to detect memory failures. That is, it is used to detect whether or not a block of memory on disk has gone bad and the values stored there have become corrupted. A message digest is similar to a checksum in that it will also detect file corruption. However, unlike most checksum algorithms, a message digest also has the property that it is very difficult to modify a file such that it will have the same message digest as its original (unmodified) form. That is, a checksum is intended to detect simple memory failures leading to corruption, but a message digest may be used to detect intentional, and even crafty modifications to a file, such as those introduced by viruses, hackers, or Trojan Horse programs.

It is not desirable to include all image file data in the calculation of a message digest. In some cases it simply presents undesirable characteristics (like the file is no longer localizable without regenerating certificates) and in other cases it is simply impossible. For example, It is not possible to include all information within an image file in a message digest, then insert a certificate containing that message digest in the file, and later be able to generate an identical message digest by including all image file data in the calculation again (since the file now contains a certificate that wasn't originally there).

This specification does not attempt to architect what each Attribute Certificate may be used for, or which fields or sections of an image file must be included in a message digest. However, this section does identify which fields you may not want to or may not include in a message digest.

In addition to knowing which fields are and are not included in the calculation of a message digest, it is important to know the order in which the contents of the image are presented to the digest algorithm. This section specifies that order.

Fields Not To Include In Digests

There are some parts of an image that you may not want to include in any message digest. This section identifies those parts, and describes why you might not want to include them in a message digest.

Information related to Attribute Certificates - It is not possible to include a certificate in the calculation of a message digest that resides within the certificate. Since certificates can be added to or removed from an image without effecting the overall integrity of the image this is not a problem. Therefore, it is best to leave all attribute certificates out of the image even if there are certificates already in the image at the time you are calculating your message digest. There is no guarantee those certificates will still be there later, or that other certificates won't have been added. To exclude attribute certificate information from the message digest calculation, you must exclude the following information from that calculation:

• The Certificate Table field of the Optional Header Data Directories.
  
  
• The Certificate Table and corresponding certificates pointed to by the Certificate Table field listed immediately above.

  Debug information - Debug information may generally be considered advisory (to debuggers) and does not effect the actual integrity of the executable program. It is quite literally possible to remove debug information from an image after a product has been delivered and not effect the functionality of the program. This is, in fact, a disk saving measure that is sometimes utilized. If you do not want to include debug information in your message digest, then you should not include the following information in your message digest calculation:

• The Debug entry of the Data Directory in with optional header.
  
  
• The .debug section
  

  File Checksum field of the Windows NT-Specific Fields of the Optional Header - This checksum includes the entire file (including any attribute certificates included in the file) and will, in all likelihood, be different after inserting your certificate than when you were originally calculating a message digest to include in your certificate.

  Unused, or obsolete fields - There are several fields that are either unused or obsolete. The value of these fields is undefined an may change after you calculate your message digest. These fields include:

• Reserved field of the Optional Header Windows NT-Specific Fields (offset 52).
  
  
• The DLL Flags field of the Optional Header Windows NT-Specific Fields. This field is obsolete.
  
  
• Loader Flags field of the Optional Header Windows NT-Specific Fields. This field is obsolete.
  
  
• Reserved entries of the Data Directory in the object header.

  Resources (makes localization easier) - depending upon the specific your Attribute Certificate, it may be desirable or undesirable to include resources in the message digest. If you want to allow localization without the generation of new certificates, then you do not want to include resources in your message digest. If the values of the resources are critical to your application, then you probably do want them included in your message digest, and you will accept the overhead of generating a certificate for each localized copy of the image. If you do not want to include resources in your message digest, then you should not include the following information in the message digest calculation:

• Resource Table entry of the Optional Header Data Directory.
  
  
• The .rsrc section.