1 INF: Executable-File Header Format [P_WinSDK]
5 PSSONLY | Windows 3 Developers Notes softlib ENDUSER
9 Note: This article is part of a set of seven articles, collectively
10 called the "Windows 3.00 Developer's Notes." More information about
11 the contents of the other articles, and procedures for ordering a
12 hard-copy set, can be found in the knowledge base article titled "INF:
13 The Windows 3.00 Developer's Notes" (Q65260).
15 This article can be found in the Software/Data Library by searching on
16 the word EXEFMT or S12688. EXEFMT was archived using the PKware
17 file-compression utility.
21 Microsoft defined the segmented executable file format for Windows
22 applications and dynamic-link libraries (DLLs). This file format is
23 also referred to as the New Executable Format. This new format is an
24 extension of the existing MS-DOS .EXE format (old-style format). The
25 purpose of the segmented executable format is to provide the
26 information needed to support the dynamic linking and segmentation
27 capabilities of the Windows environment.
29 An executable file contains Microsoft Windows code and data, or
30 Windows code, data, and resources. Specific fields have been added to
31 the old-style .EXE format header to indicate the existence of the
32 segmented file format. The old-style header may contain a valid
33 executable program, called a stub program, that will be executed if
34 the program is run on MS-DOS (without Windows). This stub program
35 usually prints a message indicating that Microsoft Windows is required
36 to run the program. The segmented executable format extensions also
37 begin with a header that describes the contents and location of the
38 executable image in the file. The loader uses this header information
39 when it loads the executable segments in memory.
42 ======================================================================
43 OLD-STYLE HEADER EXTENSIONS
44 ======================================================================
46 The old-style header contains information the loader expects for a DOS
47 executable file. It describes a stub program (WINSTUB) the loader can
48 place in memory when necessary, it points to the new-style header, and
49 it contains the stub programs relocation table.
51 The following illustrates the distinct parts of the old-style
54 +-------------------------+
55 00h | Old-style header info |
56 +-------------------------+
58 +-------------------------+
59 3Ch | Offset to segmented |
61 +-------------------------+
62 40h | Relocation table and |
64 +-------------------------+
65 | Segmented .EXE Header |
70 The word at offset 18h in the old-style .EXE header contains the
71 relative byte offset to the stub program's relocation table. If this
72 offset is 40h, then the double word at offset 3Ch is assumed to be the
73 relative byte offset from the beginning of the file to the beginning
74 of the segmented executable header. A new-format .EXE file is
75 identified if the segmented executable header contains a valid
76 signature. If the signature is not valid, the file is assumed to be an
77 old-style format .EXE file. The remainder of the old-style format
78 header will describe a DOS program, the stub. The stub may be any
79 valid program but will typically be a program that displays an error
82 ======================================================================
84 ======================================================================
86 Because Windows executable files are often larger than one segment
87 (64K), additional information (that does not appear in the old-style
88 header) is required so that the loader can load each segment properly.
89 The segmented EXE format was developed to provide the loader with this
92 The segmented .EXE file has the following format:
100 3Ch | Offset to | ---+
101 | Segmented Header| |
102 +-----------------+ |
103 40h | Relocation Table| |
105 +-----------------+ |
107 +-----------------+ |
108 xxh | Segmented EXE | <--+
141 The following sections describe each of the components that make up
142 the segmented EXE format. Each section contains a description of the
143 component and the fields in the structures that make up that
146 Note: All unused fields and flag bits are reserved for future use and
147 must contain 0 (zero) values.
149 ======================================================================
151 ======================================================================
153 The segmented EXE header contains general information about the EXE
154 file and contains information on the location and size of the other
155 sections. The Windows loader copies this section, along with other
156 data, into the module table in the system data. The module table is
157 internal data used by the loader to manage the loaded executable
158 modules in the system and to support dynamic linking.
160 The following describes the format of the segmented executable header.
161 For each field, the offset is given relative to the beginning of the
162 segmented header, the size of the field is defined, and a description
165 Offset Size Description
166 ------ ---- -----------
168 00h DW Signature word.
169 "N" is low-order byte.
170 "E" is high-order byte.
172 02h DB Version number of the linker.
174 03h DB Revision number of the linker.
176 04h DW Entry Table file offset, relative to the beginning of
177 the segmented EXE header.
178 06h DW Number of bytes in the entry table.
180 08h DD 32-bit CRC of entire contents of file.
181 These words are taken as 00 during the calculation.
185 0001h = SINGLEDATA (Shared automatic data segment)
186 0002h = MULTIPLEDATA (Instanced automatic data
188 2000h = Errors detected at link time, module will not
190 8000h = Library module.
191 The SS:SP information is invalid, CS:IP points
192 to an initialization procedure that is called
193 with AX equal to the module handle. This
194 initialization procedure must perform a far
195 return to the caller, with AX not equal to
196 zero to indicate success, or AX equal to zero
197 to indicate failure to initialize. DS is set
198 to the library's data segment if the
199 SINGLEDATA flag is set. Otherwise, DS is set
200 to the caller's data segment.
202 A program or DLL can only contain dynamic
203 links to executable files that have this
204 library module flag set. One program cannot
205 dynamic-link to another program.
207 0Eh DW Segment number of automatic data segment.
208 This value is set to zero if SINGLEDATA and
209 MULTIPLEDATA flag bits are clear, NOAUTODATA is
210 indicated in the flags word.
212 A Segment number is an index into the module's segment
213 table. The first entry in the segment table is segment
216 10h DW Initial size, in bytes, of dynamic heap added to the
217 data segment. This value is zero if no initial local
220 12h DW Initial size, in bytes, of stack added to the data
221 segment. This value is zero to indicate no initial
222 stack allocation, or when SS is not equal to DS.
224 14h DD Segment number:offset of CS:IP.
226 18h DD Segment number:offset of SS:SP.
227 If SS equals the automatic data segment and SP equals
228 zero, the stack pointer is set to the top of the
229 automatic data segment just below the additional heap
232 +--------------------------+
233 | additional dynamic heap |
234 +--------------------------+ <- SP
236 +--------------------------+
237 | loaded auto data segment |
238 +--------------------------+ <- DS, SS
240 1Ch DW Number of entries in the Segment Table.
242 1Eh DW Number of entries in the Module Reference Table.
243 20h DW Number of bytes in the Non-Resident Name Table.
245 22h DW Segment Table file offset, relative to the beginning
246 of the segmented EXE header.
248 24h DW Resource Table file offset, relative to the beginning
249 of the segmented EXE header.
251 26h DW Resident Name Table file offset, relative to the
252 beginning of the segmented EXE header.
254 28h DW Module Reference Table file offset, relative to the
255 beginning of the segmented EXE header.
257 2Ah DW Imported Names Table file offset, relative to the
258 beginning of the segmented EXE header.
260 2Ch DD Non-Resident Name Table offset, relative to the
261 beginning of the file.
263 30h DW Number of movable entries in the Entry Table.
265 32h DW Logical sector alignment shift count, log(base 2) of
266 the segment sector size (default 9).
268 34h DW Number of resource entries.
270 36h DB Executable type, used by loader.
273 37h-3Fh DB Reserved, currently 0's.
276 ======================================================================
278 ======================================================================
280 The segment table contains an entry for each segment in the executable
281 file. The number of segment table entries are defined in the segmented
282 EXE header. The first entry in the segment table is segment number 1.
283 The following is the structure of a segment table entry.
288 DW Logical-sector offset (n byte) to the contents of the segment
289 data, relative to the beginning of the file. Zero means no
292 DW Length of the segment in the file, in bytes. Zero means 64K.
295 0007h = TYPE_MASK Segment-type field.
296 0000h = CODE Code-segment type.
297 0001h = DATA Data-segment type.
298 0010h = MOVEABLE Segment is not fixed.
299 0040h = PRELOAD Segment will be preloaded; read-only if
300 this is a data segment.
301 0100h = RELOCINFO Set if segment has relocation records.
302 F000h = DISCARD Discard priority.
304 DW Minimum allocation size of the segment, in bytes. Total size
305 of the segment. Zero means 64K.
308 ======================================================================
310 ======================================================================
312 The resource table follows the segment table and contains entries for
313 each resource in the executable file. The resource table consists of
314 an alignment shift count, followed by a table of resource records. The
315 resource records define the type ID for a set of resources. Each
316 resource record contains a table of resource entries of the defined
317 type. The resource entry defines the resource ID or name ID for the
318 resource. It also defines the location and size of the resource. The
319 following describes the contents of each of these structures:
324 DW Alignment shift count for resource data.
326 A table of resource type information blocks follows. The following
327 is the format of each type information block:
329 DW Type ID. This is an integer type if the high-order bit is
330 set (8000h); otherwise, it is an offset to the type string,
331 the offset is relative to the beginning of the resource
332 table. A zero type ID marks the end of the resource type
335 DW Number of resources for this type.
339 A table of resources for this type follows. The following is
340 the format of each resource (8 bytes each):
342 DW File offset to the contents of the resource data,
343 relative to beginning of file. The offset is in terms
344 of the alignment shift count value specified at
345 beginning of the resource table.
347 DW Length of the resource in the file (in bytes).
350 0010h = MOVEABLE Resource is not fixed.
351 0020h = PURE Resource can be shared.
352 0040h = PRELOAD Resource is preloaded.
354 DW Resource ID. This is an integer type if the high-order
355 bit is set (8000h), otherwise it is the offset to the
356 resource string, the offset is relative to the
357 beginning of the resource table.
361 Resource type and name strings are stored at the end of the
362 resource table. Note that these strings are NOT null terminated and
365 DB Length of the type or name string that follows. A zero value
366 indicates the end of the resource type and name string, also
367 the end of the resource table.
369 DB ASCII text of the type or name string.
372 ======================================================================
374 ======================================================================
376 The resident-name table follows the resource table, and contains this
377 module's name string and resident exported procedure name strings. The
378 first string in this table is this module's name. These name strings
379 are case-sensitive and are not null-terminated. The following
380 describes the format of the name strings:
385 DB Length of the name string that follows. A zero value indicates
386 the end of the name table.
388 DB ASCII text of the name string.
390 DW Ordinal number (index into entry table). This value is ignored
394 ======================================================================
395 MODULE-REFERENCE TABLE
396 ======================================================================
398 The module-reference table follows the resident-name table. Each entry
399 contains an offset for the module-name string within the imported-
400 names table; each entry is 2 bytes long.
405 DW Offset within Imported Names Table to referenced module name
409 ======================================================================
411 ======================================================================
413 The imported-name table follows the module-reference table. This table
414 contains the names of modules and procedures that are imported by the
415 executable file. Each entry is composed of a 1-byte field that
416 contains the length of the string, followed by any number of
417 characters. The strings are not null-terminated and are case
423 DB Length of the name string that follows.
425 DB ASCII text of the name string.
428 ======================================================================
430 ======================================================================
432 The entry table follows the imported-name table. This table contains
433 bundles of entry-point definitions. Bundling is done to save space in
434 the entry table. The entry table is accessed by an ordinal value.
435 Ordinal number one is defined to index the first entry in the entry
436 table. To find an entry point, the bundles are scanned searching for a
437 specific entry point using an ordinal number. The ordinal number is
438 adjusted as each bundle is checked. When the bundle that contains the
439 entry point is found, the ordinal number is multiplied by the size of
440 the bundle's entries to index the proper entry.
442 The linker forms bundles in the most dense manner it can, under the
443 restriction that it cannot reorder entry points to improve bundling.
444 The reason for this restriction is that other .EXE files may refer to
445 entry points within this bundle by their ordinal number. The following
446 describes the format of the entry table bundles.
451 DB Number of entries in this bundle. All records in one bundle
452 are either moveable or refer to the same fixed segment. A zero
453 value in this field indicates the end of the entry table.
455 DB Segment indicator for this bundle. This defines the type of
456 entry table entry data within the bundle. There are three
457 types of entries that are defined.
459 000h = Unused entries. There is no entry data in an unused
460 bundle. The next bundle follows this field. This is
461 used by the linker to skip ordinal numbers.
463 001h-0FEh = Segment number for fixed segment entries. A fixed
464 segment entry is 3 bytes long and has the following
468 01h = Set if the entry is exported.
469 02h = Set if the entry uses a global (shared) data
471 The first assembly-language instruction in the
472 entry point prologue must be "MOV AX,data
473 segment number". This may be set only for
474 SINGLEDATA library modules.
476 DW Offset within segment to entry point.
478 0FFH = Moveable segment entries. The entry data contains the
479 segment number for the entry points. A moveable segment
480 entry is 6 bytes long and has the following format.
483 01h = Set if the entry is exported.
484 02h = Set if the entry uses a global (shared) data
491 DW Offset within segment to entry point.
494 ======================================================================
495 NONRESIDENT-NAME TABLE
496 ======================================================================
498 The nonresident-name table follows the entry table, and contains a
499 module description and nonresident exported procedure name strings.
500 The first string in this table is a module description. These name
501 strings are case-sensitive and are not null-terminated. The name
502 strings follow the same format as those defined in the resident name
506 ======================================================================
508 ======================================================================
510 The location and size of the per-segment data is defined in the
511 segment table entry for the segment. If the segment has relocation
512 fixups, as defined in the segment table entry flags, they directly
513 follow the segment data in the file. The relocation fixup information
514 is defined as follows:
520 DW Number of relocation records that follow.
522 A table of relocation records follows. The following is the format
523 of each relocation record.
529 03h = FAR_ADDR (32-bit pointer)
530 05h = OFFSET (16-bit offset)
540 DW Offset within this segment of the source chain.
541 If the ADDITIVE flag is set, then target value is added to
542 the source contents, instead of replacing the source and
543 following the chain. The source chain is an 0FFFFh
544 terminated linked list within this segment of all
545 references to the target.
547 The target value has four types that are defined in the flag
548 byte field. The following are the formats for each target
553 DB Segment number for a fixed segment, or 0FFh for a
558 DW Offset into segment if fixed segment, or ordinal
559 number index into Entry Table if movable segment.
563 DW Index into module reference table for the imported
566 DW Offset within Imported Names Table to procedure name
571 DW Index into module reference table for the imported
573 DW Procedure ordinal number.
577 DW Operating system fixup type.
578 Floating-point fixups.
579 0001h = FIARQQ, FJARQQ
580 0002h = FISRQQ, FJSRQQ
581 0003h = FICRQQ, FJCRQQ
588 ======================================================================
590 Microsoft is a registered trademark and Windows is a trademark of
591 Microsoft Corporation.
593 Additional reference words: 3.0