CARDS.DLL loader for SDL
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

exefmt.txt 22KB

  1. INF: Executable-File Header Format [P_WinSDK]
  2. 3.00
  4. PSSONLY | Windows 3 Developers Notes softlib ENDUSER
  5. Summary:
  6. Note: This article is part of a set of seven articles, collectively
  7. called the "Windows 3.00 Developer's Notes." More information about
  8. the contents of the other articles, and procedures for ordering a
  9. hard-copy set, can be found in the knowledge base article titled "INF:
  10. The Windows 3.00 Developer's Notes" (Q65260).
  11. This article can be found in the Software/Data Library by searching on
  12. the word EXEFMT or S12688. EXEFMT was archived using the PKware
  13. file-compression utility.
  14. More Information:
  15. Microsoft defined the segmented executable file format for Windows
  16. applications and dynamic-link libraries (DLLs). This file format is
  17. also referred to as the New Executable Format. This new format is an
  18. extension of the existing MS-DOS .EXE format (old-style format). The
  19. purpose of the segmented executable format is to provide the
  20. information needed to support the dynamic linking and segmentation
  21. capabilities of the Windows environment.
  22. An executable file contains Microsoft Windows code and data, or
  23. Windows code, data, and resources. Specific fields have been added to
  24. the old-style .EXE format header to indicate the existence of the
  25. segmented file format. The old-style header may contain a valid
  26. executable program, called a stub program, that will be executed if
  27. the program is run on MS-DOS (without Windows). This stub program
  28. usually prints a message indicating that Microsoft Windows is required
  29. to run the program. The segmented executable format extensions also
  30. begin with a header that describes the contents and location of the
  31. executable image in the file. The loader uses this header information
  32. when it loads the executable segments in memory.
  33. ======================================================================
  35. ======================================================================
  36. The old-style header contains information the loader expects for a DOS
  37. executable file. It describes a stub program (WINSTUB) the loader can
  38. place in memory when necessary, it points to the new-style header, and
  39. it contains the stub programs relocation table.
  40. The following illustrates the distinct parts of the old-style
  41. executable format:
  42. +-------------------------+
  43. 00h | Old-style header info |
  44. +-------------------------+
  45. 20h | Reserved |
  46. +-------------------------+
  47. 3Ch | Offset to segmented |
  48. | .EXE header |
  49. +-------------------------+
  50. 40h | Relocation table and |
  51. | DOS stub program |
  52. +-------------------------+
  53. | Segmented .EXE Header |
  54. | . |
  55. | . |
  56. | . |
  57. The word at offset 18h in the old-style .EXE header contains the
  58. relative byte offset to the stub program's relocation table. If this
  59. offset is 40h, then the double word at offset 3Ch is assumed to be the
  60. relative byte offset from the beginning of the file to the beginning
  61. of the segmented executable header. A new-format .EXE file is
  62. identified if the segmented executable header contains a valid
  63. signature. If the signature is not valid, the file is assumed to be an
  64. old-style format .EXE file. The remainder of the old-style format
  65. header will describe a DOS program, the stub. The stub may be any
  66. valid program but will typically be a program that displays an error
  67. message.
  68. ======================================================================
  70. ======================================================================
  71. Because Windows executable files are often larger than one segment
  72. (64K), additional information (that does not appear in the old-style
  73. header) is required so that the loader can load each segment properly.
  74. The segmented EXE format was developed to provide the loader with this
  75. information.
  76. The segmented .EXE file has the following format:
  77. +-----------------+
  78. 00h | Old-style EXE |
  79. | Header |
  80. +-----------------+
  81. 20h | Reserved |
  82. +-----------------+
  83. 3Ch | Offset to | ---+
  84. | Segmented Header| |
  85. +-----------------+ |
  86. 40h | Relocation Table| |
  87. | & Stub Program | |
  88. +-----------------+ |
  89. | | |
  90. +-----------------+ |
  91. xxh | Segmented EXE | <--+
  92. | Header |
  93. +-----------------+
  94. | Segment Table |
  95. +-----------------+
  96. | Resource Table |
  97. +-----------------+
  98. | Resident Name |
  99. | Table |
  100. +-----------------+
  101. | Module Reference|
  102. | Table |
  103. +-----------------+
  104. | Imported Names |
  105. | Table |
  106. +-----------------+
  107. | Entry Table |
  108. +-----------------+
  109. | Non-Resident |
  110. | Name Table |
  111. +-----------------+
  112. | Seg #1 Data |
  113. | Seg #1 Info |
  114. +-----------------+
  115. .
  116. .
  117. .
  118. +-----------------+
  119. | Seg #n Data |
  120. | Seg #n Info |
  121. +-----------------+
  122. The following sections describe each of the components that make up
  123. the segmented EXE format. Each section contains a description of the
  124. component and the fields in the structures that make up that
  125. component.
  126. Note: All unused fields and flag bits are reserved for future use and
  127. must contain 0 (zero) values.
  128. ======================================================================
  130. ======================================================================
  131. The segmented EXE header contains general information about the EXE
  132. file and contains information on the location and size of the other
  133. sections. The Windows loader copies this section, along with other
  134. data, into the module table in the system data. The module table is
  135. internal data used by the loader to manage the loaded executable
  136. modules in the system and to support dynamic linking.
  137. The following describes the format of the segmented executable header.
  138. For each field, the offset is given relative to the beginning of the
  139. segmented header, the size of the field is defined, and a description
  140. is given.
  141. Offset Size Description
  142. ------ ---- -----------
  143. 00h DW Signature word.
  144. "N" is low-order byte.
  145. "E" is high-order byte.
  146. 02h DB Version number of the linker.
  147. 03h DB Revision number of the linker.
  148. 04h DW Entry Table file offset, relative to the beginning of
  149. the segmented EXE header.
  150. 06h DW Number of bytes in the entry table.
  151. 08h DD 32-bit CRC of entire contents of file.
  152. These words are taken as 00 during the calculation.
  153. 0Ch DW Flag word.
  154. 0000h = NOAUTODATA
  155. 0001h = SINGLEDATA (Shared automatic data segment)
  156. 0002h = MULTIPLEDATA (Instanced automatic data
  157. segment)
  158. 2000h = Errors detected at link time, module will not
  159. load.
  160. 8000h = Library module.
  161. The SS:SP information is invalid, CS:IP points
  162. to an initialization procedure that is called
  163. with AX equal to the module handle. This
  164. initialization procedure must perform a far
  165. return to the caller, with AX not equal to
  166. zero to indicate success, or AX equal to zero
  167. to indicate failure to initialize. DS is set
  168. to the library's data segment if the
  169. SINGLEDATA flag is set. Otherwise, DS is set
  170. to the caller's data segment.
  171. A program or DLL can only contain dynamic
  172. links to executable files that have this
  173. library module flag set. One program cannot
  174. dynamic-link to another program.
  175. 0Eh DW Segment number of automatic data segment.
  176. This value is set to zero if SINGLEDATA and
  177. MULTIPLEDATA flag bits are clear, NOAUTODATA is
  178. indicated in the flags word.
  179. A Segment number is an index into the module's segment
  180. table. The first entry in the segment table is segment
  181. number 1.
  182. 10h DW Initial size, in bytes, of dynamic heap added to the
  183. data segment. This value is zero if no initial local
  184. heap is allocated.
  185. 12h DW Initial size, in bytes, of stack added to the data
  186. segment. This value is zero to indicate no initial
  187. stack allocation, or when SS is not equal to DS.
  188. 14h DD Segment number:offset of CS:IP.
  189. 18h DD Segment number:offset of SS:SP.
  190. If SS equals the automatic data segment and SP equals
  191. zero, the stack pointer is set to the top of the
  192. automatic data segment just below the additional heap
  193. area.
  194. +--------------------------+
  195. | additional dynamic heap |
  196. +--------------------------+ <- SP
  197. | additional stack |
  198. +--------------------------+
  199. | loaded auto data segment |
  200. +--------------------------+ <- DS, SS
  201. 1Ch DW Number of entries in the Segment Table.
  202. 1Eh DW Number of entries in the Module Reference Table.
  203. 20h DW Number of bytes in the Non-Resident Name Table.
  204. 22h DW Segment Table file offset, relative to the beginning
  205. of the segmented EXE header.
  206. 24h DW Resource Table file offset, relative to the beginning
  207. of the segmented EXE header.
  208. 26h DW Resident Name Table file offset, relative to the
  209. beginning of the segmented EXE header.
  210. 28h DW Module Reference Table file offset, relative to the
  211. beginning of the segmented EXE header.
  212. 2Ah DW Imported Names Table file offset, relative to the
  213. beginning of the segmented EXE header.
  214. 2Ch DD Non-Resident Name Table offset, relative to the
  215. beginning of the file.
  216. 30h DW Number of movable entries in the Entry Table.
  217. 32h DW Logical sector alignment shift count, log(base 2) of
  218. the segment sector size (default 9).
  219. 34h DW Number of resource entries.
  220. 36h DB Executable type, used by loader.
  221. 02h = WINDOWS
  222. 37h-3Fh DB Reserved, currently 0's.
  223. ======================================================================
  225. ======================================================================
  226. The segment table contains an entry for each segment in the executable
  227. file. The number of segment table entries are defined in the segmented
  228. EXE header. The first entry in the segment table is segment number 1.
  229. The following is the structure of a segment table entry.
  230. Size Description
  231. ---- -----------
  232. DW Logical-sector offset (n byte) to the contents of the segment
  233. data, relative to the beginning of the file. Zero means no
  234. file data.
  235. DW Length of the segment in the file, in bytes. Zero means 64K.
  236. DW Flag word.
  237. 0007h = TYPE_MASK Segment-type field.
  238. 0000h = CODE Code-segment type.
  239. 0001h = DATA Data-segment type.
  240. 0010h = MOVEABLE Segment is not fixed.
  241. 0040h = PRELOAD Segment will be preloaded; read-only if
  242. this is a data segment.
  243. 0100h = RELOCINFO Set if segment has relocation records.
  244. F000h = DISCARD Discard priority.
  245. DW Minimum allocation size of the segment, in bytes. Total size
  246. of the segment. Zero means 64K.
  247. ======================================================================
  249. ======================================================================
  250. The resource table follows the segment table and contains entries for
  251. each resource in the executable file. The resource table consists of
  252. an alignment shift count, followed by a table of resource records. The
  253. resource records define the type ID for a set of resources. Each
  254. resource record contains a table of resource entries of the defined
  255. type. The resource entry defines the resource ID or name ID for the
  256. resource. It also defines the location and size of the resource. The
  257. following describes the contents of each of these structures:
  258. Size Description
  259. ---- -----------
  260. DW Alignment shift count for resource data.
  261. A table of resource type information blocks follows. The following
  262. is the format of each type information block:
  263. DW Type ID. This is an integer type if the high-order bit is
  264. set (8000h); otherwise, it is an offset to the type string,
  265. the offset is relative to the beginning of the resource
  266. table. A zero type ID marks the end of the resource type
  267. information blocks.
  268. DW Number of resources for this type.
  269. DD Reserved.
  270. A table of resources for this type follows. The following is
  271. the format of each resource (8 bytes each):
  272. DW File offset to the contents of the resource data,
  273. relative to beginning of file. The offset is in terms
  274. of the alignment shift count value specified at
  275. beginning of the resource table.
  276. DW Length of the resource in the file (in bytes).
  277. DW Flag word.
  278. 0010h = MOVEABLE Resource is not fixed.
  279. 0020h = PURE Resource can be shared.
  280. 0040h = PRELOAD Resource is preloaded.
  281. DW Resource ID. This is an integer type if the high-order
  282. bit is set (8000h), otherwise it is the offset to the
  283. resource string, the offset is relative to the
  284. beginning of the resource table.
  285. DD Reserved.
  286. Resource type and name strings are stored at the end of the
  287. resource table. Note that these strings are NOT null terminated and
  288. are case sensitive.
  289. DB Length of the type or name string that follows. A zero value
  290. indicates the end of the resource type and name string, also
  291. the end of the resource table.
  292. DB ASCII text of the type or name string.
  293. ======================================================================
  295. ======================================================================
  296. The resident-name table follows the resource table, and contains this
  297. module's name string and resident exported procedure name strings. The
  298. first string in this table is this module's name. These name strings
  299. are case-sensitive and are not null-terminated. The following
  300. describes the format of the name strings:
  301. Size Description
  302. ---- -----------
  303. DB Length of the name string that follows. A zero value indicates
  304. the end of the name table.
  305. DB ASCII text of the name string.
  306. DW Ordinal number (index into entry table). This value is ignored
  307. for the module name.
  308. ======================================================================
  310. ======================================================================
  311. The module-reference table follows the resident-name table. Each entry
  312. contains an offset for the module-name string within the imported-
  313. names table; each entry is 2 bytes long.
  314. Size Description
  315. ---- -----------
  316. DW Offset within Imported Names Table to referenced module name
  317. string.
  318. ======================================================================
  320. ======================================================================
  321. The imported-name table follows the module-reference table. This table
  322. contains the names of modules and procedures that are imported by the
  323. executable file. Each entry is composed of a 1-byte field that
  324. contains the length of the string, followed by any number of
  325. characters. The strings are not null-terminated and are case
  326. sensitive.
  327. Size Description
  328. ---- -----------
  329. DB Length of the name string that follows.
  330. DB ASCII text of the name string.
  331. ======================================================================
  333. ======================================================================
  334. The entry table follows the imported-name table. This table contains
  335. bundles of entry-point definitions. Bundling is done to save space in
  336. the entry table. The entry table is accessed by an ordinal value.
  337. Ordinal number one is defined to index the first entry in the entry
  338. table. To find an entry point, the bundles are scanned searching for a
  339. specific entry point using an ordinal number. The ordinal number is
  340. adjusted as each bundle is checked. When the bundle that contains the
  341. entry point is found, the ordinal number is multiplied by the size of
  342. the bundle's entries to index the proper entry.
  343. The linker forms bundles in the most dense manner it can, under the
  344. restriction that it cannot reorder entry points to improve bundling.
  345. The reason for this restriction is that other .EXE files may refer to
  346. entry points within this bundle by their ordinal number. The following
  347. describes the format of the entry table bundles.
  348. Size Description
  349. ---- -----------
  350. DB Number of entries in this bundle. All records in one bundle
  351. are either moveable or refer to the same fixed segment. A zero
  352. value in this field indicates the end of the entry table.
  353. DB Segment indicator for this bundle. This defines the type of
  354. entry table entry data within the bundle. There are three
  355. types of entries that are defined.
  356. 000h = Unused entries. There is no entry data in an unused
  357. bundle. The next bundle follows this field. This is
  358. used by the linker to skip ordinal numbers.
  359. 001h-0FEh = Segment number for fixed segment entries. A fixed
  360. segment entry is 3 bytes long and has the following
  361. format.
  362. DB Flag word.
  363. 01h = Set if the entry is exported.
  364. 02h = Set if the entry uses a global (shared) data
  365. segments.
  366. The first assembly-language instruction in the
  367. entry point prologue must be "MOV AX,data
  368. segment number". This may be set only for
  369. SINGLEDATA library modules.
  370. DW Offset within segment to entry point.
  371. 0FFH = Moveable segment entries. The entry data contains the
  372. segment number for the entry points. A moveable segment
  373. entry is 6 bytes long and has the following format.
  374. DB Flag word.
  375. 01h = Set if the entry is exported.
  376. 02h = Set if the entry uses a global (shared) data
  377. segments.
  378. INT 3FH.
  379. DB Segment number.
  380. DW Offset within segment to entry point.
  381. ======================================================================
  383. ======================================================================
  384. The nonresident-name table follows the entry table, and contains a
  385. module description and nonresident exported procedure name strings.
  386. The first string in this table is a module description. These name
  387. strings are case-sensitive and are not null-terminated. The name
  388. strings follow the same format as those defined in the resident name
  389. table.
  390. ======================================================================
  392. ======================================================================
  393. The location and size of the per-segment data is defined in the
  394. segment table entry for the segment. If the segment has relocation
  395. fixups, as defined in the segment table entry flags, they directly
  396. follow the segment data in the file. The relocation fixup information
  397. is defined as follows:
  398. Size Description
  399. ---- -----------
  400. DW Number of relocation records that follow.
  401. A table of relocation records follows. The following is the format
  402. of each relocation record.
  403. DB Source type.
  404. 0Fh = SOURCE_MASK
  405. 00h = LOBYTE
  406. 02h = SEGMENT
  407. 03h = FAR_ADDR (32-bit pointer)
  408. 05h = OFFSET (16-bit offset)
  409. DB Flags byte.
  410. 03h = TARGET_MASK
  411. 00h = INTERNALREF
  412. 01h = IMPORTORDINAL
  413. 02h = IMPORTNAME
  414. 03h = OSFIXUP
  415. 04h = ADDITIVE
  416. DW Offset within this segment of the source chain.
  417. If the ADDITIVE flag is set, then target value is added to
  418. the source contents, instead of replacing the source and
  419. following the chain. The source chain is an 0FFFFh
  420. terminated linked list within this segment of all
  421. references to the target.
  422. The target value has four types that are defined in the flag
  423. byte field. The following are the formats for each target
  424. type:
  426. DB Segment number for a fixed segment, or 0FFh for a
  427. movable segment.
  428. DB 0
  429. DW Offset into segment if fixed segment, or ordinal
  430. number index into Entry Table if movable segment.
  432. DW Index into module reference table for the imported
  433. module.
  434. DW Offset within Imported Names Table to procedure name
  435. string.
  437. DW Index into module reference table for the imported
  438. module.
  439. DW Procedure ordinal number.
  440. OSFIXUP
  441. DW Operating system fixup type.
  442. Floating-point fixups.
  443. 0001h = FIARQQ, FJARQQ
  444. 0002h = FISRQQ, FJSRQQ
  445. 0003h = FICRQQ, FJCRQQ
  446. 0004h = FIERQQ
  447. 0005h = FIDRQQ
  448. 0006h = FIWRQQ
  449. DW 0
  450. ======================================================================
  451. Microsoft is a registered trademark and Windows is a trademark of
  452. Microsoft Corporation.
  453. Additional reference words: 3.0