API tools faq
paste
Advertisement
Guest User

Untitled

a guest
Nov 6th, 2012
236
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 75.20 KB | None | 0 0
raw download clone embed print report
  1.  
  2. LX - Linear eXecutable Module Format Description
  3.  
  4. June 3, 1992
  5.  
  6.  
  7.  
  8. Figure 1. 32-bit Linear EXE File Layout
  9.  
  10. 00h +------------------+ <--+
  11. | DOS 2 Compatible | |
  12. | EXE Header | |
  13. 1Ch +------------------+ |
  14. | unused | |
  15. +------------------+ |
  16. 24h | OEM Identifier | |
  17. 26h | OEM Info | |
  18. | | |-- DOS 2.0 Section
  19. 3Ch | Offset to | | (Discarded)
  20. | Linear EXE | |
  21. | Header | |
  22. 40h +------------------+ |
  23. | DOS 2.0 Stub | |
  24. | Program & | |
  25. | Reloc. Table | |
  26. +------------------+ <--+
  27. | |
  28. xxh +------------------+ <--+
  29. | Executable | |
  30. | Info | |
  31. +------------------+ |
  32. | Module | |
  33. | Info | |
  34. +------------------+ |-- Linear Executable
  35. | Loader Section | | Module Header
  36. | Info | | (Resident)
  37. +------------------+ |
  38. | Table Offset | |
  39. | Info | |
  40. +------------------+ <--+
  41. | Object Table | |
  42. +------------------+ |
  43. | Object Page Table| |
  44. +------------------+ |
  45. | Resource Table | |
  46. +------------------+ |
  47. | Resident Name | |
  48. | Table | |
  49. +------------------+ |-- Loader Section
  50. | Entry Table | | (Resident)
  51. +------------------+ |
  52. | Module Format | |
  53. | Directives Table | |
  54. | (Optional) | |
  55. +------------------+ |
  56. | Resident | |
  57. | Directives Data | |
  58. | (Optional) | |
  59. | | |
  60. | (Verify Record) | |
  61. +------------------+ |
  62. | Per-Page | |
  63. | Checksum | |
  64. +------------------+ <--+
  65. | Fixup Page Table | |
  66. +------------------+ |
  67. | Fixup Record | |
  68. | Table | |
  69. +------------------+ |-- Fixup Section
  70. | Import Module | | (Optionally Resident)
  71. | Name Table | |
  72. +------------------+ |
  73. | Import Procedure | |
  74. | Name Table | |
  75. +------------------+ <--+
  76. | Preload Pages | |
  77. +------------------+ |
  78. | Demand Load | |
  79. | Pages | |
  80. +------------------+ |
  81. | Iterated Pages | |
  82. +------------------+ |
  83. | Non-Resident | |-- (Non-Resident)
  84. | Name Table | |
  85. +------------------+ |
  86. | Non-Resident | |
  87. | Directives Data | |
  88. | (Optional) | |
  89. | | |
  90. | (To be Defined) | |
  91. +------------------+ <--+
  92. | Debug Info | |-- (Not used by Loader)
  93. +------------------+ <--+
  94.  
  95.  
  96.  
  97. Figure 2. 32-bit Linear EXE Header
  98.  
  99. +-----+-----+-----+-----+-----+-----+-----+-----+
  100. 00h | "L" "X" |B-ORD|W-ORD| FORMAT LEVEL |
  101. +-----+-----+-----+-----+-----+-----+-----+-----+
  102. 08h | CPU TYPE | OS TYPE | MODULE VERSION |
  103. +-----+-----+-----+-----+-----+-----+-----+-----+
  104. 10h | MODULE FLAGS | MODULE # OF PAGES |
  105. +-----+-----+-----+-----+-----+-----+-----+-----+
  106. 18h | EIP OBJECT # | EIP |
  107. +-----+-----+-----+-----+-----+-----+-----+-----+
  108. 20h | ESP OBJECT # | ESP |
  109. +-----+-----+-----+-----+-----+-----+-----+-----+
  110. 28h | PAGE SIZE | PAGE OFFSET SHIFT |
  111. +-----+-----+-----+-----+-----+-----+-----+-----+
  112. 30h | FIXUP SECTION SIZE | FIXUP SECTION CHECKSUM|
  113. +-----+-----+-----+-----+-----+-----+-----+-----+
  114. 38h | LOADER SECTION SIZE |LOADER SECTION CHECKSUM|
  115. +-----+-----+-----+-----+-----+-----+-----+-----+
  116. 40h | OBJECT TABLE OFF | # OBJECTS IN MODULE |
  117. +-----+-----+-----+-----+-----+-----+-----+-----+
  118. 48h | OBJECT PAGE TABLE OFF | OBJECT ITER PAGES OFF |
  119. +-----+-----+-----+-----+-----+-----+-----+-----+
  120. 50h | RESOURCE TABLE OFFSET |#RESOURCE TABLE ENTRIES|
  121. +-----+-----+-----+-----+-----+-----+-----+-----+
  122. 58h | RESIDENT NAME TBL OFF | ENTRY TABLE OFFSET |
  123. +-----+-----+-----+-----+-----+-----+-----+-----+
  124. 60h | MODULE DIRECTIVES OFF | # MODULE DIRECTIVES |
  125. +-----+-----+-----+-----+-----+-----+-----+-----+
  126. 68h | FIXUP PAGE TABLE OFF |FIXUP RECORD TABLE OFF |
  127. +-----+-----+-----+-----+-----+-----+-----+-----+
  128. 70h | IMPORT MODULE TBL OFF | # IMPORT MOD ENTRIES |
  129. +-----+-----+-----+-----+-----+-----+-----+-----+
  130. 78h | IMPORT PROC TBL OFF | PER-PAGE CHECKSUM OFF |
  131. +-----+-----+-----+-----+-----+-----+-----+-----+
  132. 80h | DATA PAGES OFFSET | #PRELOAD PAGES |
  133. +-----+-----+-----+-----+-----+-----+-----+-----+
  134. 88h | NON-RES NAME TBL OFF | NON-RES NAME TBL LEN |
  135. +-----+-----+-----+-----+-----+-----+-----+-----+
  136. 90h | NON-RES NAME TBL CKSM | AUTO DS OBJECT # |
  137. +-----+-----+-----+-----+-----+-----+-----+-----+
  138. 98h | DEBUG INFO OFF | DEBUG INFO LEN |
  139. +-----+-----+-----+-----+-----+-----+-----+-----+
  140. A0h | #INSTANCE PRELOAD | #INSTANCE DEMAND |
  141. +-----+-----+-----+-----+-----+-----+-----+-----+
  142. A8h | HEAPSIZE |
  143. +-----+-----+-----+-----+
  144.  
  145. Note: The OBJECT ITER PAGES OFF must either be 0 or set to the
  146. same value as DATA PAGES OFFSET in OS/2 2.0. Ie., iterated pages are
  147. required to be in the same section of the file as regular pages.
  148.  
  149. Note: Table offsets in the Linear EXE Header may be set to
  150. zero to indicate that the table does not exist in the EXE
  151. file and it's size is zero.
  152.  
  153. "L" "X" = DW Signature word.
  154. The signature word is used by the loader to identify
  155. the EXE file as a valid 32-bit Linear Executable
  156. Module Format. "L" is low order byte. "X" is high
  157. order byte.
  158.  
  159. B-ORD = DB Byte Ordering.
  160. This byte specifies the byte ordering for the linear
  161. EXE format. The values are:
  162.  
  163. 00H - Little Endian Byte Ordering.
  164. 01H - Big Endian Byte Ordering.
  165.  
  166. W-ORD = DB Word Ordering.
  167. This byte specifies the Word ordering for the linear
  168. EXE format. The values are:
  169.  
  170. 00H - Little Endian Word Ordering.
  171. 01H - Big Endian Word Ordering.
  172.  
  173. Format Level = DD Linear EXE Format Level.
  174. The Linear EXE Format Level is set to 0 for the
  175. initial version of the 32-bit linear EXE format.
  176. Each incompatible change to the linear EXE format
  177. must increment this value. This allows the system
  178. to recognized future EXE file versions so that an
  179. appropriate error message may be displayed if an
  180. attempt is made to load them.
  181.  
  182. CPU Type = DW Module CPU Type.
  183. This field specifies the type of CPU required by
  184. this module to run. The values are:
  185.  
  186. 01H - 80286 or upwardly compatible CPU is
  187. required to execute this module.
  188. 02H - 80386 or upwardly compatible CPU is
  189. required to execute this module.
  190. 03H - 80486 or upwardly compatible CPU is
  191. required to execute this module.
  192.  
  193. OS Type = DW Module OS Type.
  194. This field specifies the type of Operating system
  195. required to run this module. The currently defined
  196. values are:
  197.  
  198. 00H - Unknown (any "new-format" OS)
  199. 01H - OS/2 (default)
  200. 02H - Windows
  201. 03H - DOS 4.x
  202. 04H - Windows 386
  203.  
  204. MODULE VERSION = DD Version of the linear EXE module.
  205. This is useful for differentiating between revisions
  206. of dynamic linked modules. This value is specified
  207. at link time by the user.
  208.  
  209. MODULE FLAGS = DD Flag bits for the module.
  210. The module flag bits have the following definitions.
  211.  
  212. 00000001h = Reserved for system use.
  213. 00000002h = Reserved for system use.
  214. 00000004h = Per-Process Library Initialization.
  215. The setting of this bit requires the EIP
  216. Object # and EIP fields to have valid
  217. values. If the EIP Object # and EIP fields
  218. are valid and this bit is NOT set, then
  219. Global Library Initialization is assumed.
  220. Setting this bit for an EXE file is invalid.
  221.  
  222. 00000008h = Reserved for system use.
  223. 00000010h = Internal fixups for the module have
  224. been applied.
  225. The setting of this bit in a Linear
  226. Executable Module indicates that each object
  227. of the module has a preferred load address
  228. specified in the Object Table Reloc Base
  229. Addr. If the module's objects can not be
  230. loaded at these preferred addresses, then
  231. the relocation records that have been
  232. retained in the file data will be applied.
  233.  
  234. 00000020h = External fixups for the module have
  235. been applied.
  236. 00000040h = Reserved for system use.
  237. 00000080h = Reserved for system use.
  238. 00000100h = Incompatible with PM windowing.
  239. 00000200h = Compatible with PM windowing.
  240. 00000300h = Uses PM windowing API.
  241. 00000400h = Reserved for system use.
  242. 00000800h = Reserved for system use.
  243. 00001000h = Reserved for system use.
  244. 00002000h = Module is not loadable.
  245. When the 'Module is not loadable' flag is
  246. set, it indicates that either errors were
  247. detected at link time or that the module is
  248. being incrementally linked and therefore
  249. can't be loaded.
  250.  
  251. 00004000h = Reserved for system use.
  252. 00038000h = Module type mask.
  253. 00000000h = Program module.
  254. A module can not contain dynamic links to
  255. other modules that have the 'program module'
  256. type.
  257.  
  258. 00008000h = Library module.
  259. 00018000h = Protected Memory Library module.
  260. 00020000h = Physical Device Driver module.
  261. 00028000h = Virtual Device Driver module.
  262. 40000000h = Per-process Library Termination.
  263. The setting of this bit requires the EIP
  264. Object # and EIP fields to have valid
  265. values. If the EIP Object # and EIP fields
  266. are valid and this bit is NOT set, then
  267. Global Library Termination is assumed.
  268. Setting this bit for an EXE file is invalid.
  269.  
  270. MODULE # PAGES = DD Number of pages in module.
  271.  
  272. This field specifies the number of pages physically
  273. contained in this module. In other words, pages
  274. containing either enumerated or iterated data, or
  275. zero-fill pages that have relocations, not invalid
  276. or zero-fill pages implied by the Virtual Size in
  277. the Object Table being larger than the number of
  278. pages actually in the linear EXE file. These pages
  279. are contained in the 'preload pages', 'demand load
  280. pages' and 'iterated data pages' sections of the
  281. linear EXE module. This is used to determine the
  282. size of the page information tables in the linear
  283. EXE module.
  284.  
  285. EIP OBJECT # = DD The Object number to which the Entry
  286. Address is relative.
  287. This specifies the object to which the Entry Address
  288. is relative. This must be a nonzero value for a
  289. program module to be correctly loaded. A zero value
  290. for a library module indicates that no library entry
  291. routine exists. If this value is zero, then both
  292. the Per-process Library Initialization bit and the
  293. Per-process Library Termination bit must be clear in
  294. the module flags, or else the loader will fail to
  295. load the module. Further, if the Per-process
  296. Library Termination bit is set, then the object to
  297. which this field refers must be a 32-bit object
  298. (i.e., the Big/Default bit must be set in the object
  299. flags; see below).
  300.  
  301. EIP = DD Entry Address of module.
  302. The Entry Address is the starting address for
  303. program modules and the library initialization and
  304. Library termination address for library modules.
  305.  
  306. ESP OBJECT # = DD The Object number to which the ESP is
  307. relative.
  308. This specifies the object to which the starting ESP
  309. is relative. This must be a nonzero value for a
  310. program module to be correctly loaded. This field
  311. is ignored for a library module.
  312.  
  313. ESP = DD Starting stack address of module.
  314. The ESP defines the starting stack pointer address
  315. for program modules. A zero value in this field
  316. indicates that the stack pointer is to be
  317. initialized to the highest address/offset in the
  318. object. This field is ignored for a library module.
  319.  
  320. PAGE SIZE = DD The size of one page for this system.
  321. This field specifies the page size used by the
  322. linear EXE format and the system. For the initial
  323. version of this linear EXE format the page size is
  324. 4Kbytes. (The 4K page size is specified by a value
  325. of 4096 in this field.)
  326.  
  327. PAGE OFFSET SHIFT = DD The shift left bits for page
  328. offsets.
  329. This field gives the number of bit positions to
  330. shift left when interpreting the Object Page Table
  331. entries' page offset field. This determines the
  332. alignment of the page information in the file. For
  333. example, a value of 4 in this field would align all
  334. pages in the Data Pages and Iterated Pages sections
  335. on 16 byte (paragraph) boundaries. A Page Offset
  336. Shift of 9 would align all pages on a 512 byte (disk
  337. sector) basis. The default value for this field is
  338. 12 (decimal), which give a 4096 byte alignment. All
  339. other offsets are byte aligned.
  340.  
  341. FIXUP SECTION SIZE = DD Total size of the fixup
  342. information in bytes.
  343. This includes the following 4 tables:
  344.  
  345. - Fixup Page Table
  346. - Fixup Record Table
  347. - Import Module name Table
  348. - Import Procedure Name Table
  349.  
  350. FIXUP SECTION CHECKSUM = DD Checksum for fixup
  351. information.
  352. This is a cryptographic checksum covering all of the
  353. fixup information. The checksum for the fixup
  354. information is kept separate because the fixup data
  355. is not always loaded into main memory with the
  356. 'loader section'. If the checksum feature is not
  357. implemented, then the linker will set these fields
  358. to zero.
  359.  
  360. LOADER SECTION SIZE = DD Size of memory resident
  361. tables.
  362. This is the total size in bytes of the tables
  363. required to be memory resident for the module, while
  364. the module is in use. This total size includes all
  365. tables from the Object Table down to and including
  366. the Per-Page Checksum Table.
  367.  
  368. LOADER SECTION CHECKSUM = DD Checksum for loader
  369. section.
  370. This is a cryptographic checksum covering all of the
  371. loader section information. If the checksum feature
  372. is not implemented, then the linker will set these
  373. fields to zero.
  374.  
  375. OBJECT TABLE OFF = DD Object Table offset.
  376. This offset is relative to the beginning of the
  377. linear EXE header.
  378.  
  379. # OBJECTS IN MODULE = DD Object Table Count.
  380. This defines the number of entries in Object Table.
  381.  
  382. OBJECT PAGE TABLE OFFSET = DD Object Page Table offset
  383. This offset is relative to the beginning of the
  384. linear EXE header.
  385.  
  386. OBJECT ITER PAGES OFF = DD Object Iterated Pages
  387. offset.
  388. This offset is relative to the beginning of the EXE
  389. file.
  390.  
  391. RESOURCE TABLE OFF = DD Resource Table offset.
  392. This offset is relative to the beginning of the
  393. linear EXE header.
  394.  
  395. # RESOURCE TABLE ENTRIES = DD Number of entries in
  396. Resource Table.
  397.  
  398. RESIDENT NAME TBL OFF = DD Resident Name Table offset.
  399. This offset is relative to the beginning of the
  400. linear EXE header.
  401.  
  402. ENTRY TBL OFF = DD Entry Table offset.
  403. This offset is relative to the beginning of the
  404. linear EXE header.
  405.  
  406. MODULE DIRECTIVES OFF = DD Module Format Directives
  407. Table offset.
  408. This offset is relative to the beginning of the
  409. linear EXE header.
  410.  
  411. # MODULE DIRECTIVES = DD Number of Module Format
  412. Directives in the Table.
  413. This field specifies the number of entries in the
  414. Module Format Directives Table.
  415.  
  416. FIXUP PAGE TABLE OFF = DD Fixup Page Table offset.
  417. This offset is relative to the beginning of the
  418. linear EXE header.
  419.  
  420. FIXUP RECORD TABLE OFF = DD Fixup Record Table Offset
  421. This offset is relative to the beginning of the
  422. linear EXE header.
  423.  
  424. IMPORT MODULE TBL OFF = DD Import Module Name Table
  425. offset.
  426. This offset is relative to the beginning of the
  427. linear EXE header.
  428.  
  429. # IMPORT MOD ENTRIES = DD The number of entries in the
  430. Import Module Name Table.
  431.  
  432. IMPORT PROC TBL OFF = DD Import Procedure Name Table
  433. offset.
  434. This offset is relative to the beginning of the
  435. linear EXE header.
  436.  
  437. PER-PAGE CHECKSUM OFF = DD Per-Page Checksum Table
  438. offset.
  439. This offset is relative to the beginning of the
  440. linear EXE header.
  441.  
  442. DATA PAGES OFFSET = DD Data Pages Offset.
  443. This offset is relative to the beginning of the EXE
  444. file.
  445.  
  446. # PRELOAD PAGES = DD Number of Preload pages for this
  447. module. Note that OS/2 2.0 does not respect the preload
  448. of pages as specified in the executable file for performance
  449. reasons.
  450.  
  451. NON-RES NAME TBL OFF = DD Non-Resident Name Table
  452. offset.
  453. This offset is relative to the beginning of the EXE
  454. file.
  455.  
  456. NON-RES NAME TBL LEN = DD Number of bytes in the
  457. Non-resident name table.
  458.  
  459. NON-RES NAME TBL CKSM = DD Non-Resident Name Table
  460. Checksum.
  461. This is a cryptographic checksum of the Non-Resident
  462. Name Table.
  463.  
  464. AUTO DS OBJECT # = DD The Auto Data Segment Object
  465. number.
  466. This is the object number for the Auto Data Segment
  467. used by 16-bit modules. This field is supported for
  468. 16-bit compatibility only and is not used by 32-bit
  469. modules.
  470.  
  471. DEBUG INFO OFF = DD Debug Information offset.
  472. This offset is relative to the beginning of the
  473. linear EXE header.
  474.  
  475. DEBUG INFO LEN = DD Debug Information length.
  476. The length of the debug information in bytes.
  477.  
  478. # INSTANCE PRELOAD = DD Instance pages in preload
  479. section.
  480. The number of instance data pages found in the
  481. preload section.
  482.  
  483. # INSTANCE DEMAND = DD Instance pages in demand
  484. section.
  485. The number of instance data pages found in the
  486. demand section.
  487.  
  488. HEAPSIZE = DD Heap size added to the Auto DS Object.
  489. The heap size is the number of bytes added to the
  490. Auto Data Segment by the loader. This field is
  491. supported for 16-bit compatibility only and is not
  492. used by 32-bit modules.
  493.  
  494.  
  495.  
  496.  
  497.  
  498. Program (EXE) startup registers and Library entry registers
  499.  
  500.  
  501. Program startup registers are defined as follows.
  502.  
  503. EIP = Starting program entry address.
  504.  
  505. ESP = Top of stack address.
  506.  
  507. CS = Code selector for base of linear address space.
  508.  
  509. DS = ES = SS = Data selector for base of linear
  510. address space.
  511.  
  512. FS = Data selector of base of Thread Information
  513. Block (TIB).
  514.  
  515. GS = 0.
  516.  
  517. EAX = EBX = 0.
  518.  
  519. ECX = EDX = 0.
  520.  
  521. ESI = EDI = 0.
  522.  
  523. EBP = 0.
  524.  
  525. [ESP+0] = Return address to routine which calls
  526. DosExit(1,EAX).
  527.  
  528. [ESP+4] = Module handle for program module.
  529.  
  530. [ESP+8] = Reserved.
  531.  
  532. [ESP+12] = Environment data object address.
  533.  
  534. [ESP+16] = Command line linear address in
  535. environment data object.
  536.  
  537.  
  538. Library initialization registers are defined as follows.
  539.  
  540. EIP = Library entry address.
  541.  
  542. ESP = User program stack.
  543.  
  544. CS = Code selector for base of linear address space.
  545.  
  546. DS = ES = SS = Data selector for base of linear
  547. address space.
  548.  
  549. Note that a 32-bit Protected Memory Library module
  550. will be given a GDT selector in the DS and ES
  551. registers (PROTDS) that addresses the full linear
  552. address space available to a application. This
  553. selector should be saved by the initialization
  554. routine. Non-Protected Memory Library modules will
  555. receive a selector (FLATDS) that addresses the same
  556. amount of linear address space as an application's
  557. .EXE can.
  558.  
  559. FS = Data selector of base of Thread Information
  560. Block (TIB).
  561.  
  562. GS = 0.
  563.  
  564. EAX = EBX = 0.
  565.  
  566. ECX = EDX = 0.
  567.  
  568. ESI = EDI = 0.
  569.  
  570. EBP = 0.
  571.  
  572. [ESP+0] = Return address to system, (EAX) = return
  573. code.
  574.  
  575. [ESP+4] = Module handle for library module.
  576.  
  577. [ESP+8] = 0 (Initialization)
  578.  
  579. Note that a 32-bit library may specify that its entry
  580. address is in a 16-bit code object. In this case, the
  581. entry registers are the same as for entry to a library
  582. using the Segmented EXE format. These are documented
  583. elsewhere. This means that a 16-bit library may be
  584. relinked to take advantage of the benefits of the Linear
  585. EXE format (notably, efficient paging).
  586.  
  587.  
  588. Library termination registers are defined as follows.
  589.  
  590. EIP = Library entry address.
  591.  
  592. ESP = User program stack.
  593.  
  594. CS = Code selector for base of linear address space.
  595.  
  596. DS = ES = SS = Data selector for base of linear
  597. address space.
  598.  
  599. FS = Data selector of base of Thread Information
  600. Block (TIB).
  601.  
  602. GS = 0.
  603.  
  604. EAX = EBX = 0.
  605.  
  606. ECX = EDX = 0.
  607.  
  608. ESI = EDI = 0.
  609.  
  610. EBP = 0.
  611.  
  612. [ESP+0] = Return address to system.
  613.  
  614. [ESP+4] = Module handle for library module.
  615.  
  616. [ESP+8] = 1 (Termination)
  617.  
  618. Note that Library termination is not allowed for
  619. libraries with 16-bit entries.
  620.  
  621.  
  622.  
  623.  
  624.  
  625. Object Table
  626.  
  627.  
  628. The number of entries in the Object Table is given by the #
  629. Objects in Module field in the linear EXE header. Entries
  630. in the Object Table are numbered starting from one.
  631.  
  632. Each Object Table entry has the following format:
  633.  
  634. +-----+-----+-----+-----+-----+-----+-----+-----+
  635. 00h | VIRTUAL SIZE | RELOC BASE ADDR |
  636. +-----+-----+-----+-----+-----+-----+-----+-----+
  637. 08h | OBJECT FLAGS | PAGE TABLE INDEX |
  638. +-----+-----+-----+-----+-----+-----+-----+-----+
  639. 10h | # PAGE TABLE ENTRIES | RESERVED |
  640. +-----+-----+-----+-----+-----+-----+-----+-----+
  641.  
  642. VIRTUAL SIZE = DD Virtual memory size.
  643. This is the size of the object that will be
  644. allocated when the object is loaded. The object's
  645. virtual size (rounded up to the page size value)
  646. must be greater than or equal to the total size of
  647. the pages in the EXE file for the object. This
  648. memory size must also be large enough to contain all
  649. of the iterated data and uninitialized data in the
  650. EXE file.
  651.  
  652. RELOC BASE ADDR = DD Relocation Base Address.
  653. The relocation base address the object is currently
  654. relocated to. If the internal relocation fixups for
  655. the module have been removed, this is the address
  656. the object will be allocated at by the loader.
  657.  
  658. OBJECT FLAGS = DW Flag bits for the object.
  659. The object flag bits have the following definitions.
  660.  
  661. 0001h = Readable Object.
  662. 0002h = Writable Object.
  663. 0004h = Executable Object.
  664. The readable, writable and executable flags
  665. provide support for all possible
  666. protections. In systems where all of these
  667. protections are not supported, the loader
  668. will be responsible for making the
  669. appropriate protection match for the system.
  670.  
  671. 0008h = Resource Object.
  672. 0010h = Discardable Object.
  673. 0020h = Object is Shared.
  674. 0040h = Object has Preload Pages.
  675. 0080h = Object has Invalid Pages.
  676. 0100h = Object has Zero Filled Pages.
  677. 0200h = Object is Resident (valid for VDDs, PDDs
  678. only).
  679. 0300h = Object is Resident & Contiguous (VDDs,
  680. PDDs only).
  681. 0400h = Object is Resident & 'long-lockable'
  682. (VDDs, PDDs only).
  683. 0800h = Reserved for system use.
  684. 1000h = 16:16 Alias Required (80x86 Specific).
  685. 2000h = Big/Default Bit Setting (80x86
  686. Specific).
  687. The 'big/default' bit , for data segments,
  688. controls the setting of the Big bit in the
  689. segment descriptor. (The Big bit, or B-bit,
  690. determines whether ESP or SP is used as the
  691. stack pointer.) For code segments, this bit
  692. controls the setting of the Default bit in
  693. the segment descriptor. (The Default bit,
  694. or D-bit, determines whether the default
  695. word size is 32-bits or 16-bits. It also
  696. affects the interpretation of the
  697. instruction stream.)
  698.  
  699. 4000h = Object is conforming for code (80x86
  700. Specific).
  701. 8000h = Object I/O privilege level (80x86
  702. Specific).
  703. Only used for 16:16 Alias Objects.
  704.  
  705. PAGE TABLE INDEX = DD Object Page Table Index.
  706. This specifies the number of the first object page
  707. table entry for this object. The object page table
  708. specifies where in the EXE file a page can be found
  709. for a given object and specifies per-page
  710. attributes.
  711.  
  712. The object table entries are ordered by logical page
  713. in the object table. In other words the object
  714. table entries are sorted based on the object page
  715. table index value.
  716.  
  717. # PAGE TABLE ENTRIES = DD # of object page table
  718. entries for this object.
  719. Any logical pages at the end of an object that do
  720. not have an entry in the object page table
  721. associated with them are handled as zero filled or
  722. invalid pages by the loader.
  723.  
  724. When the last logical pages of an object are not
  725. specified with an object page table entry, they are
  726. treated as either zero filled pages or invalid pages
  727. based on the last entry in the object page table for
  728. that object. If the last entry was neither a zero
  729. filled or invalid page, then the additional pages
  730. are treated as zero filled pages.
  731.  
  732. RESERVED = DD Reserved for future use. Must be set to
  733. zero.
  734.  
  735.  
  736.  
  737. Object Page Table
  738.  
  739.  
  740. The Object page table provides information about a logical
  741. page in an object. A logical page may be an enumerated
  742. page, a pseudo page or an iterated page. The structure of
  743. the object page table in conjunction with the structure of
  744. the object table allows for efficient access of a page when
  745. a page fault occurs, while still allowing the physical page
  746. data to be located in the preload page, demand load page or
  747. iterated data page sections in the linear EXE module. The
  748. logical page entries in the Object Page Table are numbered
  749. starting from one. The Object Page Table is parallel to the
  750. Fixup Page Table as they are both indexed by the logical
  751. page number.
  752.  
  753. Each Object Page Table entry has the following format:
  754.  
  755. 63 32 31 16 15 0
  756. +-----+-----+-----+-----+-----+-----+-----+-----+
  757. 00h | PAGE DATA OFFSET | DATA SIZE | FLAGS |
  758. +-----+-----+-----+-----+-----+-----+-----+-----+
  759.  
  760. PAGE DATA OFFSET = DD Offset to the page data in the
  761. EXE file.
  762. This field, when bit shifted left by the PAGE OFFSET
  763. SHIFT from the module header, specifies the offset
  764. from the beginning of the Preload Page section of
  765. the physical page data in the EXE file that
  766. corresponds to this logical page entry. The page
  767. data may reside in the Preload Pages, Demand Load
  768. Pages or the Iterated Data Pages sections.
  769.  
  770. If the FLAGS field specifies that this is a
  771. zero-Filled page then the PAGE DATA OFFSET field
  772. will contain a 0.
  773.  
  774. If the logical page is specified as an iterated data
  775. page, as indicated by the FLAGS field, then this
  776. field specifies the offset into the Iterated Data
  777. Pages section.
  778.  
  779. The logical page number (Object Page Table index),
  780. is used to index the Fixup Page Table to find any
  781. fixups associated with the logical page.
  782.  
  783.  
  784. DATA SIZE = DW Number of bytes of data for this page.
  785. This field specifies the actual number of bytes that
  786. represent the page in the file. If the PAGE SIZE
  787. field from the module header is greater than the
  788. value of this field and the FLAGS field indicates a
  789. Legal Physical Page, the remaining bytes are to be
  790. filled with zeros. If the FLAGS field indicates an
  791. Iterated Data Page, the iterated data records will
  792. completely fill out the remainder.
  793.  
  794.  
  795. FLAGS = DW Attributes specifying characteristics of
  796. this logical page.
  797. The bit definitions for this word field follow,
  798.  
  799. 00h = Legal Physical Page in the module (Offset
  800. from Preload Page Section).
  801. 01h = Iterated Data Page (Offset from Iterated
  802. Data Pages Section).
  803. 02h = Invalid Page (zero).
  804. 03h = Zero Filled Page (zero).
  805. 04h = Range of Pages.
  806.  
  807.  
  808.  
  809.  
  810. Resource Table
  811.  
  812.  
  813. The resource table is an array of resource table entries.
  814. Each resource table entry contains a type ID and name ID.
  815. These entries are used to locate resource objects contained
  816. in the Object table. The number of entries in the resource
  817. table is defined by the Resource Table Count located in the
  818. linear EXE header. More than one resource may be contained
  819. within a single object. Resource table entries are in a
  820. sorted order, (ascending, by Resource Name ID within the
  821. Resource Type ID). This allows the DosGetResource API
  822. function to use a binary search when looking up a resource
  823. in a 32-bit module instead of the linear search being used
  824. in the current 16-bit module.
  825.  
  826. Each resource entry has the following format:
  827.  
  828. +-----+-----+-----+-----+
  829. 00h | TYPE ID | NAME ID |
  830. +-----+-----+-----+-----+
  831. 04h | RESOURCE SIZE |
  832. +-----+-----+-----+-----+-----+-----+
  833. 08h | OBJECT | OFFSET |
  834. +-----+-----+-----+-----+-----+-----+
  835.  
  836.  
  837. TYPE ID = DW Resource type ID.
  838. The type of resources are:
  839.  
  840. BTMP = Bitmap
  841. EMSG = Error message string
  842. FONT = Fonts
  843.  
  844. NAME ID = DW An ID used as a name for the resource when
  845. referred to.
  846.  
  847. RESOURCE SIZE = DD The number of bytes the resource
  848. consists of.
  849.  
  850. OBJECT = DW The number of the object which contains the
  851. resource.
  852.  
  853. OFFSET = DD The offset within the specified object
  854. where the resource begins.
  855.  
  856.  
  857.  
  858.  
  859.  
  860. Resident or Non-resident Name Table Entry
  861.  
  862.  
  863. The resident and non-resident name tables define the ASCII
  864. names and ordinal numbers for exported entries in the
  865. module. In addition the first entry in the resident name
  866. table contains the module name. These tables are used to
  867. translate a procedure name string into an ordinal number by
  868. searching for a matching name string. The ordinal number is
  869. used to locate the entry point information in the entry
  870. table.
  871.  
  872. The resident name table is kept resident in system memory
  873. while the module is loaded. It is intended to contain the
  874. exported entry point names that are frequently dynamicaly
  875. linked to by name. Non-resident names are not kept in
  876. memory and are read from the EXE file when a dynamic link
  877. reference is made. Exported entry point names that are
  878. infrequently dynamicaly linked to by name or are commonly
  879. referenced by ordinal number should be placed in the
  880. non-resident name table. The trade off made for references
  881. by name is performance vs memory usage.
  882.  
  883. Import references by name require these tables to be
  884. searched to obtain the entry point ordinal number. Import
  885. references by ordinal number provide the fastest lookup
  886. since the search of these tables is not required.
  887.  
  888. The strings are CASE SENSITIVE and are NOT NULL TERMINATED.
  889.  
  890. Each name table entry has the following format:
  891.  
  892. +-----+-----+-----+-----+ +-----+-----+-----+
  893. 00h | LEN | ASCII STRING . . . | ORDINAL # |
  894. +-----+-----+-----+-----+ +-----+-----+-----+
  895.  
  896.  
  897. LEN = DB String Length.
  898. This defines the length of the string in bytes. A
  899. zero length indicates there are no more entries in
  900. table. The length of each ascii name string is
  901. limited to 127 characters.
  902.  
  903. The high bit in the LEN field (bit 7) is defined as
  904. an Overload bit. This bit signifies that additional
  905. information is contained in the linear EXE module
  906. and will be used in the future for parameter type
  907. checking.
  908.  
  909. ASCII STRING = DB ASCII String.
  910. This is a variable length string with it's length
  911. defined in bytes by the LEN field. The string is
  912. case case sensitive and is not null terminated.
  913.  
  914. ORDINAL # = DW Ordinal number.
  915. The ordinal number in an ordered index into the
  916. entry table for this entry point.
  917.  
  918.  
  919.  
  920.  
  921.  
  922. Entry Table
  923.  
  924.  
  925. The entry table contains object and offset information that
  926. is used to resolve fixup references to the entry points
  927. within this module. Not all entry points in the entry table
  928. will be exported, some entry points will only be used within
  929. the module. An ordinal number is used to index into the
  930. entry table. The entry table entries are numbered starting
  931. from one.
  932.  
  933. The list of entries are compressed into 'bundles', where
  934. possible. The entries within each bundle are all the same
  935. size. A bundle starts with a count field which indicates
  936. the number of entries in the bundle. The count is followed
  937. by a type field which identifies the bundle format. This
  938. provides both a means for saving space as well as a
  939. mechanism for extending the bundle types.
  940.  
  941. The type field allows the definition of 256 bundle types.
  942. The following bundle types will initially be defined:
  943.  
  944. Unused Entry.
  945. 16-bit Entry.
  946. 286 Call Gate Entry.
  947. 32-bit Entry.
  948. Forwarder Entry.
  949.  
  950. The bundled entry table has the following format:
  951.  
  952. +-----+-----+-----+-----+-----+
  953. 00h | CNT |TYPE | BUNDLE INFO . . .
  954. +-----+-----+-----+-----+-----+
  955.  
  956.  
  957. CNT = DB Number of entries.
  958. This is the number of entries in this bundle.
  959.  
  960. A zero value for the number of entries identifies
  961. the end of the entry table. There is no further
  962. bundle information when the number of entries is
  963. zero. In other words the entry table is terminated
  964. by a single zero byte.
  965.  
  966. TYPE = DB Bundle type.
  967. This defines the bundle type which determines the
  968. contents of the BUNDLE INFO.
  969.  
  970. The follow types are defined:
  971.  
  972. 00h = Unused Entry.
  973. 01h = 16-bit Entry.
  974. 02h = 286 Call Gate Entry.
  975. 03h = 32-bit Entry.
  976. 04h = Forwarder Entry.
  977. 80h = Parameter Typing Information Present.
  978. This bit signifies that additional
  979. information is contained in the linear
  980. EXE module and will be used in the
  981. future for parameter type checking.
  982.  
  983.  
  984. The following is the format for each bundle type:
  985.  
  986. +-----+-----+
  987. 00h | CNT |TYPE |
  988. +-----+-----+
  989.  
  990. CNT = DB Number of entries.
  991. This is the number of unused entries to skip.
  992.  
  993. TYPE = DB 0 (Unused Entry)
  994.  
  995. +-----+-----+-----+-----+
  996. 00h | CNT |TYPE | OBJECT |
  997. +-----+-----+-----+-----+
  998. 04h |FLAGS| OFFSET |
  999. +-----+-----+-----+
  1000. 07h | ... | . . . |
  1001. + + + +
  1002.  
  1003.  
  1004. CNT = DB Number of entries.
  1005. This is the number of 16-bit entries in this
  1006. bundle. The flags and offset value are repeated
  1007. this number of times.
  1008.  
  1009. TYPE = DB 1 (16-bit Entry)
  1010.  
  1011. OBJECT = DW Object number.
  1012. This is the object number for the entries in
  1013. this bundle.
  1014.  
  1015. FLAGS = DB Entry flags.
  1016. These are the flags for this entry point.
  1017. They have the following definition.
  1018.  
  1019. 01h = Exported entry flag.
  1020. F8h = Parameter word count mask.
  1021.  
  1022. OFFSET = DW Offset in object.
  1023. This is the offset in the object for the
  1024. entry point defined at this ordinal number.
  1025.  
  1026.  
  1027. +-----+-----+-----+-----+
  1028. 00h | CNT |TYPE | OBJECT |
  1029. +-----+-----+-----+-----+-----+
  1030. 04h |FLAGS| OFFSET | CALLGATE |
  1031. +-----+-----+-----+-----+-----+
  1032. 09h | ... | . . . | . . . |
  1033. + + + + + +
  1034.  
  1035.  
  1036. CNT = DB Number of entries.
  1037. This is the number of 286 call gate entries in
  1038. this bundle. The flags, callgate, and offset
  1039. value are repeated this number of times.
  1040.  
  1041. TYPE = DB 2 (286 Call Gate Entry)
  1042. The 286 Call Gate Entry Point type is needed by
  1043. the loader only if ring 2 segments are to be
  1044. supported. 286 Call Gate entries contain 2
  1045. extra bytes which are used by the loader to
  1046. store an LDT callgate selector value.
  1047.  
  1048. OBJECT = DW Object number.
  1049. This is the object number for the entries in
  1050. this bundle.
  1051.  
  1052. FLAGS = DB Entry flags.
  1053. These are the flags for this entry point. They
  1054. have the following definition.
  1055.  
  1056. 01h = Exported entry flag.
  1057. F8h = Parameter word count mask.
  1058.  
  1059. OFFSET = DW Offset in object.
  1060. This is the offset in the object for the entry
  1061. point defined at this ordinal number.
  1062.  
  1063. CALLGATE = DW Callgate selector.
  1064. The callgate selector is a reserved field used
  1065. by the loader to store a call gate selector
  1066. value for references to ring 2 entry points.
  1067. When a ring 3 reference to a ring 2 entry point
  1068. is made, the callgate selector with a zero
  1069. offset is place in the relocation fixup address.
  1070. The segment number and offset in segment is
  1071. placed in the LDT callgate.
  1072.  
  1073.  
  1074. +-----+-----+-----+-----+
  1075. 00h | CNT |TYPE | OBJECT |
  1076. +-----+-----+-----+-----+-----+
  1077. 04h |FLAGS| OFFSET |
  1078. +-----+-----+-----+-----+-----+
  1079. 09h | ... | . . . |
  1080. + + + + + +
  1081.  
  1082. CNT = DB Number of entries.
  1083. This is the number of 32-bit entries in this
  1084. bundle. The flags and offset value are repeated
  1085. this number of times.
  1086.  
  1087. TYPE = DB 3 (32-bit Entry)
  1088. The 32-bit Entry type will only be defined by
  1089. the linker when the offset in the object can not
  1090. be specified by a 16-bit offset.
  1091.  
  1092. OBJECT = DW Object number.
  1093. This is the object number for the entries in
  1094. this bundle.
  1095.  
  1096. FLAGS = DB Entry flags.
  1097. These are the flags for this entry point. They
  1098. have the following definition.
  1099.  
  1100. 01h = Exported entry flag.
  1101. F8h = Parameter dword count mask.
  1102.  
  1103. OFFSET = DD Offset in object.
  1104. This is the offset in the object for the entry
  1105. point defined at this ordinal number.
  1106.  
  1107. +-----+-----+-----+-----+
  1108. 00h | CNT |TYPE | RESERVED |
  1109. +-----+-----+-----+-----+-----+-----+-----+
  1110. 04h |FLAGS| MOD ORD# | OFFSET / ORDNUM |
  1111. +-----+-----+-----+-----+-----+-----+-----+
  1112. 09h | ... | ... | ... |
  1113. + + + + + + + +
  1114.  
  1115. CNT = DB Number of entries.
  1116. This is the number of forwarder entries in this
  1117. bundle. The FLAGS, MOD ORD#, and OFFSET/ORDNUM
  1118. values are repeated this number of times.
  1119.  
  1120. TYPE = DB 4 (Forwarder Entry)
  1121.  
  1122. RESERVED = DW 0
  1123. This field is reserved for future use.
  1124.  
  1125. FLAGS = DB Forwarder flags.
  1126. These are the flags for this entry point. They
  1127. have the following definition.
  1128.  
  1129. 01h = Import by ordinal.
  1130. F7h = Reserved for future use; should be zero.
  1131.  
  1132. MOD ORD# = DW Module Ordinal Number
  1133. This is the index into the Import Module Name Table
  1134. for this forwarder.
  1135.  
  1136. OFFSET / ORDNUM = DD Procedure Name Offset or Import
  1137. Ordinal Number
  1138. If the FLAGS field indicates import by ordinal, then
  1139. this field is the ordinal number into the Entry
  1140. Table of the target module, otherwise this field is
  1141. the offset into the Procedure Names Table of the
  1142. target module.
  1143.  
  1144. A Forwarder entry (type = 4) is an entry point whose value
  1145. is an imported reference. When a load time fixup occurs
  1146. whose target is a forwarder, the loader obtains the address
  1147. imported by the forwarder and uses that imported address to
  1148. resolve the fixup.
  1149.  
  1150. A forwarder may refer to an entry point in another module
  1151. which is itself a forwarder, so there can be a chain of
  1152. forwarders. The loader will traverse the chain until it
  1153. finds a non-forwarded entry point which terminates the chain
  1154. , and use this to resolve the original fixup. Circular
  1155. chains are detected by the loader and result in a load time
  1156. error. A maximum of 1024 forwarders is allowed in a chain;
  1157. more than this results in a load time error.
  1158.  
  1159. Forwarders are useful for merging and recombining API calls
  1160. into different sets of libraries, while maintaining
  1161. compatibility with applications. For example, if one wanted
  1162. to combine MONCALLS, MOUCALLS, and VIOCALLS into a single
  1163. libraries, one could provide entry points for the three
  1164. libraries that are forwarders pointing to the common
  1165. implementation.
  1166.  
  1167.  
  1168.  
  1169. Module Format Directives Table
  1170.  
  1171.  
  1172. The Module Format Directives Table is an optional table that
  1173. allows additional options to be specified. It also allows
  1174. for the extension of the linear EXE format by allowing
  1175. additional tables of information to be added to the linear
  1176. EXE module without affecting the format of the linear EXE
  1177. header. Likewise, module format directives provide a place
  1178. in the linear EXE module for 'temporary tables' of
  1179. information, such as incremental linking information and
  1180. statistic information gathered on the module. When there
  1181. are no module format directives for a linear EXE module, the
  1182. fields in the linear EXE header referencing the module
  1183. format directives table are zero.
  1184.  
  1185. Each Module Format Directive Table entry has the following
  1186. format:
  1187.  
  1188. +-----+-----+-----+-----+-----+-----+----+----+
  1189. 00h | DIRECT # | DATA LEN | DATA OFFSET |
  1190. +-----+-----+-----+-----+-----+-----+----+----+
  1191.  
  1192. DIRECT # = DW Directive number.
  1193. The directive number specifies the type of directive
  1194. defined. This can be used to determine the format
  1195. of the information in the directive data. The
  1196. following directive numbers have been defined:
  1197.  
  1198. 8000h = Resident Flag Mask.
  1199. Directive numbers with this bit set indicate
  1200. that the directive data is in the resident
  1201. area and will be kept resident in memory
  1202. when the module is loaded.
  1203.  
  1204. 8001h = Verify Record Directive. (Verify record
  1205. is a resident table.)
  1206. 0002h = Language Information Directive. (This is
  1207. a non-resident table.)
  1208. 0003h = Co-Processor Required Support Table.
  1209. 0004h = Thread State Initialization Directive.
  1210.  
  1211. Additional directives can be added as needed in the
  1212. future, as long as they do not overlap previously
  1213. defined directive numbers.
  1214.  
  1215. DATA LEN = DW Directive data length.
  1216. This specifies the length in byte of the directive
  1217. data for this directive number.
  1218.  
  1219. DIRECTIVE OFFSET = DD Directive data offset.
  1220. This is the offset to the directive data for this
  1221. directive number. It is relative to beginning of
  1222. linear EXE header for a resident table, and relative
  1223. to the beginning of the EXE file for non-resident
  1224. tables.
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230. Verify Record Directive Table
  1231.  
  1232.  
  1233. The Verify Record Directive Table is an optional table. It
  1234. maintains a record of the pages in the EXE file that have
  1235. been fixed up and written back to the original linear EXE
  1236. module, along with the module dependencies used to perform
  1237. these fixups. This table provides an efficient means for
  1238. verifying the virtual addresses required for the fixed up
  1239. pages when the module is loaded.
  1240.  
  1241. Each Verify Record entry has the following format:
  1242.  
  1243. +-----+-----+
  1244. 00h |# OF ENTRY |
  1245. +-----+-----+-----+-----+-----+-----+
  1246. 02h | MOD ORD # | VERSION | MOD # OBJ |
  1247. +-----+-----+-----+-----+-----+-----+
  1248. 08h | OBJECT # | BASE ADDR | VIRTUAL |
  1249. +-----+-----+-----+-----+-----+-----+
  1250. 0Eh | . . . | . . . | . . . |
  1251. + + + + + + +
  1252.  
  1253. # OF ENTRY = DW Number of module dependencies.
  1254. This field specifies how many entries there are in
  1255. the verify record directive table. This is equal to
  1256. the number of modules referenced by this module.
  1257.  
  1258. MOD ORD # = DW Ordinal index into the Import Module
  1259. Name Table.
  1260. This value is an ordered index in to the Import
  1261. Module Name Table for the referenced module.
  1262.  
  1263. VERSION = DW Module Version.
  1264.  
  1265. This is the version of the referenced module that
  1266. the fixups were originally performed. This is used
  1267. to insure the same version of the referenced module
  1268. is loaded that was fixed up in this module and
  1269. therefore the fixups are still correct. This
  1270. requires the version number in a module to be
  1271. incremented anytime the entry point offsets change.
  1272.  
  1273. MOD # OBJ = DW Module # of Object Entries.
  1274. This field is used to identify the number of object
  1275. verify entries that follow for the referenced
  1276. module.
  1277.  
  1278. OBJECT # = DW Object # in Module.
  1279. This field specifies the object number in the
  1280. referenced module that is being verified.
  1281.  
  1282. BASE ADDR = DW Object load base address.
  1283. This is the address that the object was loaded at
  1284. when the fixups were performed.
  1285.  
  1286. VIRTUAL = DW Object virtual address size.
  1287. This field specifies the total amount of virtual
  1288. memory required for this object.
  1289.  
  1290.  
  1291.  
  1292.  
  1293.  
  1294. Per-Page Checksum
  1295.  
  1296.  
  1297. The Per-Page Checksum table provides space for a
  1298. cryptographic checksum for each physical page in the EXE
  1299. file.
  1300.  
  1301. The checksum table is arranged such that the first entry in
  1302. the table corresponds to the first logical page of code/data
  1303. in the EXE file (usually a preload page) and the last entry
  1304. corresponds to the last logical page in the EXE file
  1305. (usually a iterated data page).
  1306.  
  1307. +-----+-----+-----+-----+
  1308. Logical Page #1 | CHECKSUM |
  1309. +-----+-----+-----+-----+
  1310. Logical Page #2 | CHECKSUM |
  1311. +-----+-----+-----+-----+
  1312. . . .
  1313.  
  1314. +-----+-----+-----+-----+
  1315. Logical Page #n | CHECKSUM |
  1316. +-----+-----+-----+-----+
  1317.  
  1318.  
  1319. CHECKSUM = DD Cryptographic checksum.
  1320.  
  1321.  
  1322.  
  1323.  
  1324.  
  1325. Fixup Page Table
  1326.  
  1327.  
  1328. The Fixup Page Table provides a simple mapping of a logical
  1329. page number to an offset into the Fixup Record Table for
  1330. that page.
  1331.  
  1332. This table is parallel to the Object Page Table, except that
  1333. there is one additional entry in this table to indicate the
  1334. end of the Fixup Record Table.
  1335.  
  1336. The format of each entry is:
  1337.  
  1338. +-----+-----+-----+-----+
  1339. Logical Page #1 | OFFSET FOR PAGE #1 |
  1340. +-----+-----+-----+-----+
  1341. Logical Page #2 | OFFSET FOR PAGE #2 |
  1342. +-----+-----+-----+-----+
  1343. . . .
  1344. +-----+-----+-----+-----+
  1345. Logical Page #n | OFFSET FOR PAGE #n |
  1346. +-----+-----+-----+-----+
  1347. |OFF TO END OF FIXUP REC| This is equal to:
  1348. +-----+-----+-----+-----+ Offset for page #n + Size
  1349. of fixups for page #n
  1350.  
  1351.  
  1352. OFFSET FOR PAGE # = DD Offset for fixup record for this
  1353. page.
  1354. This field specifies the offset, from the beginning
  1355. of the fixup record table, to the first fixup record
  1356. for this page.
  1357.  
  1358. OFF TO END OF FIXUP REC = DD Offset to the end of the
  1359. fixup records.
  1360. This field specifies the offset following the last
  1361. fixup record in the fixup record table. This is the
  1362. last entry in the fixup page table.
  1363.  
  1364. The fixup records are kept in order by logical page
  1365. in the fixup record table. This allows the end of
  1366. each page's fixup records is defined by the offset
  1367. for the next logical page's fixup records. This
  1368. last entry provides support of this mechanism for
  1369. the last page in the fixup page table.
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375. Fixup Record Table
  1376.  
  1377.  
  1378. The Fixup Record Table contains entries for all fixups in
  1379. the linear EXE module. The fixup records for a logical page
  1380. are grouped together and kept in sorted order by logical
  1381. page number. The fixups for each page are further sorted
  1382. such that all external fixups and internal selector/pointer
  1383. fixups come before internal non-selector/non-pointer fixups.
  1384. This allows the loader to ignore internal fixups if the
  1385. loader is able to load all objects at the addresses
  1386. specified in the object table.
  1387.  
  1388. Each relocation record has the following format:
  1389.  
  1390. +-----+-----+-----+-----+
  1391. 00h | SRC |FLAGS|SRCOFF/CNT*|
  1392. +-----+-----+-----+-----+-----+-----+
  1393. 03h/04h | TARGET DATA * |
  1394. +-----+-----+-----+-----+-----+-----+
  1395. | SRCOFF1 @ | . . . | SRCOFFn @ |
  1396. +-----+-----+---- ----+-----+-----+
  1397.  
  1398. * These fields are variable size.
  1399. @ These fields are optional.
  1400.  
  1401.  
  1402. SRC = DB Source type.
  1403. The source type specifies the size and type of the
  1404. fixup to be performed on the fixup source. The
  1405. source type is defined as follows:
  1406.  
  1407. 0Fh = Source mask.
  1408. 00h = Byte fixup (8-bits).
  1409. 01h = (undefined).
  1410. 02h = 16-bit Selector fixup (16-bits).
  1411. 03h = 16:16 Pointer fixup (32-bits).
  1412. 04h = (undefined).
  1413. 05h = 16-bit Offset fixup (16-bits).
  1414. 06h = 16:32 Pointer fixup (48-bits).
  1415. 07h = 32-bit Offset fixup (32-bits).
  1416. 08h = 32-bit Self-relative offset fixup
  1417. (32-bits).
  1418. 10h = Fixup to Alias Flag.
  1419. When the 'Fixup to Alias' Flag is set, the
  1420. source fixup refers to the 16:16 alias for
  1421. the object. This is only valid for source
  1422. types of 2, 3, and 6. For fixups such as
  1423. this, the linker and loader will be required
  1424. to perform additional checks such as
  1425. ensuring that the target offset for this
  1426. fixup is less than 64K.
  1427.  
  1428. 20h = Source List Flag.
  1429.  
  1430. When the 'Source List' Flag is set, the
  1431. SRCOFF field is compressed to a byte and
  1432. contains the number of source offsets, and a
  1433. list of source offsets follows the end of
  1434. fixup record (after the optional additive
  1435. value).
  1436.  
  1437. FLAGS = DB Target Flags.
  1438. The target flags specify how the target information
  1439. is interpreted. The target flags are defined as
  1440. follows:
  1441.  
  1442. 03h = Fixup target type mask.
  1443. 00h = Internal reference.
  1444. 01h = Imported reference by ordinal.
  1445. 02h = Imported reference by name.
  1446. 03h = Internal reference via entry table.
  1447. 04h = Additive Fixup Flag.
  1448. When set, an additive value trails the fixup
  1449. record (before the optional source offset
  1450. list).
  1451.  
  1452. 08h = Reserved. Must be zero.
  1453. 10h = 32-bit Target Offset Flag.
  1454. When set, the target offset is 32-bits,
  1455. otherwise it is 16-bits.
  1456.  
  1457. 20h = 32-bit Additive Fixup Flag.
  1458. When set, the additive value is 32-bits,
  1459. otherwise it is 16-bits.
  1460.  
  1461. 40h = 16-bit Object Number/Module Ordinal Flag.
  1462. When set, the object number or module
  1463. ordinal number is 16-bits, otherwise it is
  1464. 8-bits.
  1465.  
  1466. 80h = 8-bit Ordinal Flag.
  1467. When set, the ordinal number is 8-bits,
  1468. otherwise it is 16-bits.
  1469.  
  1470. SRCOFF = DW/CNT = DB Source offset or source offset
  1471. list count.
  1472. This field contains either an offset or a count
  1473. depending on the Source List Flag. If the Source
  1474. List Flag is set, a list of source offsets follows
  1475. the additive field and this field contains the count
  1476. of the entries in the source offset list.
  1477. Otherwise, this is the single source offset for the
  1478. fixup. Source offsets are relative to the beginning
  1479. of the page where the fixup is to be made.
  1480.  
  1481. Note that for fixups that cross page boundaries, a
  1482. separate fixup record is specified for each page.
  1483. An offset is still used for the 2nd page but it now
  1484. becomes a negative offset since the fixup originated
  1485. on the preceding page. (For example, if only the
  1486. last one byte of a 32-bit address is on the page to
  1487. be fixed up, then the offset would have a value of
  1488. -3.)
  1489.  
  1490. TARGET DATA = Target data for fixup.
  1491. The format of the TARGET DATA is dependent upon
  1492. target flags.
  1493.  
  1494. SRCOFF1 - SRCOFFn = DW[] Source offset list.
  1495. This list is present if the Source List Flag is set
  1496. in the Target Flags field. The number of entries in
  1497. the source offset list is defined in the SRCOFF/CNT
  1498. field. The source offsets are relative to the
  1499. beginning of the page where the fixups are to be
  1500. made.
  1501.  
  1502. +-----+-----+-----+-----+
  1503. 00h | SRC |FLAGS|SRCOFF/CNT*|
  1504. +-----+-----+-----+-----+-----+-----+
  1505. 03h/04h | OBJECT * | TRGOFF * @ |
  1506. +-----+-----+-----+-----+-----+-----+
  1507. | SRCOFF1 @ | . . . | SRCOFFn @ |
  1508. +-----+-----+---- ----+-----+-----+
  1509.  
  1510. * These fields are variable size.
  1511. @ These fields are optional.
  1512.  
  1513.  
  1514. OBJECT = D[B|W] Target object number.
  1515. This field is an index into the current module's
  1516. Object Table to specify the target Object. It
  1517. is a Byte value when the '16-bit Object
  1518. Number/Module Ordinal Flag' bit in the target
  1519. flags field is clear and a Word value when the
  1520. bit is set.
  1521.  
  1522.  
  1523. TRGOFF = D[W|D] Target offset.
  1524. This field is an offset into the specified
  1525. target Object. It is not present when the
  1526. Source Type specifies a 16-bit Selector fixup.
  1527. It is a Word value when the '32-bit Target
  1528. Offset Flag' bit in the target flags field is
  1529. clear and a Dword value when the bit is set.
  1530.  
  1531. +-----+-----+-----+-----+
  1532. 00h | SRC |FLAGS|SRCOFF/CNT*|
  1533. +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
  1534. 03h/04h | MOD ORD# *| PROCEDURE NAME OFFSET*| ADDITIVE * @ |
  1535. +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
  1536. | SRCOFF1 @ | . . . | SRCOFFn @ |
  1537. +-----+-----+---- ----+-----+-----+
  1538.  
  1539. * These fields are variable size.
  1540. @ These fields are optional.
  1541.  
  1542.  
  1543. MOD ORD # = D[B|W] Ordinal index into the Import
  1544. Module Name Table.
  1545. This value is an ordered index in to the Import
  1546. Module Name Table for the module containing the
  1547. procedure entry point. It is a Byte value when
  1548. the '16-bit Object Number/Module Ordinal' Flag
  1549. bit in the target flags field is clear and a
  1550. Word value when the bit is set. The loader
  1551. creates a table of pointers with each pointer in
  1552. the table corresponds to the modules named in
  1553. the Import Module Name Table. This value is
  1554. used by the loader to index into this table
  1555. created by the loader to locate the referenced
  1556. module.
  1557.  
  1558. PROCEDURE NAME OFFSET = D[W|D] Offset into the
  1559. Import Procedure Name Table.
  1560. This field is an offset into the Import
  1561. Procedure Name Table. It is a Word value when
  1562. the '32-bit Target Offset Flag' bit in the
  1563. target flags field is clear and a Dword value
  1564. when the bit is set.
  1565.  
  1566. ADDITIVE = D[W|D] Additive fixup value.
  1567. This field exists in the fixup record only when
  1568. the 'Additive Fixup Flag' bit in the target
  1569. flags field is set. When the 'Additive Fixup
  1570. Flag' is clear the fixup record does not contain
  1571. this field and is immediately followed by the
  1572. next fixup record (or by the source offset list
  1573. for this fixup record).
  1574.  
  1575. This value is added to the address derived from
  1576. the target entry point. This field is a Word
  1577. value when the '32-bit Additive Flag' bit in the
  1578. target flags field is clear and a Dword value
  1579. when the bit is set.
  1580.  
  1581. +-----+-----+-----+-----+
  1582. 00h | SRC |FLAGS|SRCOFF/CNT*|
  1583. +-----+-----+-----+-----+-----+-----+-----+-----+
  1584. 03h/04h | MOD ORD# *|IMPORT ORD*| ADDITIVE * @ |
  1585. +-----+-----+-----+-----+-----+-----+-----+-----+
  1586. | SRCOFF1 @ | . . . | SRCOFFn @ |
  1587. +-----+-----+---- ----+-----+-----+
  1588.  
  1589. * These fields are variable size.
  1590. @ These fields are optional.
  1591.  
  1592.  
  1593. MOD ORD # = D[B|W] Ordinal index into the Import
  1594. Module Name Table.
  1595. This value is an ordered index in to the Import
  1596. Module Name Table for the module containing the
  1597. procedure entry point. It is a Byte value when
  1598. the '16-bit Object Number/Module Ordinal' Flag
  1599. bit in the target flags field is clear and a
  1600. Word value when the bit is set. The loader
  1601. creates a table of pointers with each pointer in
  1602. the table corresponds to the modules named in
  1603. the Import Module Name Table. This value is
  1604. used by the loader to index into this table
  1605. created by the loader to locate the referenced
  1606. module.
  1607.  
  1608. IMPORT ORD = D[B|W|D] Imported ordinal number.
  1609. This is the imported procedure's ordinal number.
  1610. It is a Byte value when the '8-bit Ordinal' bit
  1611. in the target flags field is set. Otherwise it
  1612. is a Word value when the '32-bit Target Offset
  1613. Flag' bit in the target flags field is clear and
  1614. a Dword value when the bit is set.
  1615.  
  1616. ADDITIVE = D[W|D] Additive fixup value.
  1617. This field exists in the fixup record only when
  1618. the 'Additive Fixup Flag' bit in the target
  1619. flags field is set. When the 'Additive Fixup
  1620. Flag' is clear the fixup record does not contain
  1621. this field and is immediately followed by the
  1622. next fixup record (or by the source offset list
  1623. for this fixup record).
  1624.  
  1625. This value is added to the address derived from
  1626. the target entry point. This field is a Word
  1627. value when the '32-bit Additive Flag' bit in the
  1628. target flags field is clear and a Dword value
  1629. when the bit is set.
  1630.  
  1631. +-----+-----+-----+-----+
  1632. 00h | SRC |FLAGS|SRCOFF/CNT*|
  1633. +-----+-----+-----+-----+-----+-----+
  1634. 03h/04h | ORD # * | ADDITIVE * @ |
  1635. +-----+-----+-----+-----+-----+-----+
  1636. | SRCOFF1 @ | . . . | SRCOFFn @ |
  1637. +-----+-----+---- ----+-----+-----+
  1638.  
  1639. * These fields are variable size.
  1640. @ These fields are optional.
  1641.  
  1642. ENTRY # = D[B|W] Ordinal index into the Entry
  1643. Table.
  1644. This field is an index into the current module's
  1645. Entry Table to specify the target Object and
  1646. offset. It is a Byte value when the '16-bit
  1647. Object Number/Module Ordinal' Flag bit in the
  1648. target flags field is clear and a Word value
  1649. when the bit is set.
  1650.  
  1651. ADDITIVE = D[W|D] Additive fixup value.
  1652. This field exists in the fixup record only when
  1653. the 'Additive Fixup Flag' bit in the target
  1654. flags field is set. When the 'Additive Fixup
  1655. Flag' is clear the fixup record does not contain
  1656. this field and is immediately followed by the
  1657. next fixup record (or by the source offset list
  1658. for this fixup record).
  1659.  
  1660. This value is added to the address derived from
  1661. the target entry point. This field is a Word
  1662. value when the '32-bit Additive Flag' bit in the
  1663. target flags field is clear and a Dword value
  1664. when the bit is set.
  1665.  
  1666.  
  1667.  
  1668.  
  1669.  
  1670. Import Module Name Table
  1671.  
  1672.  
  1673. The import module name table defines the module name strings
  1674. imported through dynamic link references. These strings are
  1675. referenced through the imported relocation fixups.
  1676.  
  1677. To determine the length of the import module name table
  1678. subtract the import module name table offset from the import
  1679. procedure name table offset. These values are located in
  1680. the linear EXE header. The end of the import module name
  1681. table is not terminated by a special character, it is
  1682. followed directly by the import procedure name table.
  1683.  
  1684. The strings are CASE SENSITIVE and NOT NULL TERMINATED.
  1685.  
  1686. Each name table entry has the following format:
  1687.  
  1688. +-----+-----+-----+-----+ +-----+
  1689. 00h | LEN | ASCII STRING . . . |
  1690. +-----+-----+-----+-----+ +-----+
  1691.  
  1692. LEN = DB String Length.
  1693. This defines the length of the string in bytes. The
  1694. length of each ascii name string is limited to 127
  1695. characters.
  1696.  
  1697. ASCII STRING = DB ASCII String.
  1698. This is a variable length string with it's length
  1699. defined in bytes by the LEN field. The string is
  1700. case sensitive and is not null terminated.
  1701.  
  1702.  
  1703.  
  1704.  
  1705.  
  1706. Import Procedure Name Table
  1707.  
  1708.  
  1709. The import procedure name table defines the procedure name
  1710. strings imported by this module through dynamic link
  1711. references. These strings are referenced through the
  1712. imported relocation fixups.
  1713.  
  1714. To determine the length of the import procedure name table
  1715. add the fixup section size to the fixup page table offset,
  1716. this computes the offset to the end of the fixup section,
  1717. then subtract the import procedure name table offset. These
  1718. values are located in the linear EXE header. The import
  1719. procedure name table is followed by the data pages section.
  1720. Since the data pages section is aligned on a 'page size'
  1721. boundary, padded space may exist between the last import
  1722. name string and the first page in the data pages section.
  1723. If this padded space exists it will be zero filled.
  1724.  
  1725. The strings are CASE SENSITIVE and NOT NULL TERMINATED.
  1726.  
  1727. Each name table entry has the following format:
  1728.  
  1729. +-----+-----+-----+-----+ +-----+
  1730. 00h | LEN | ASCII STRING . . . |
  1731. +-----+-----+-----+-----+ +-----+
  1732.  
  1733. LEN = DB String Length.
  1734. This defines the length of the string in bytes. The
  1735. length of each ascii name string is limited to 127
  1736. characters.
  1737.  
  1738. The high bit in the LEN field (bit 7) is defined as
  1739. an Overload bit. This bit signifies that additional
  1740. information is contained in the linear EXE module
  1741. and will be used in the future for parameter type
  1742. checking.
  1743.  
  1744. ASCII STRING = DB ASCII String.
  1745. This is a variable length string with it's length
  1746. defined in bytes by the LEN field. The string is
  1747. case sensitive and is not null terminated.
  1748.  
  1749.  
  1750.  
  1751.  
  1752.  
  1753. Preload Pages
  1754.  
  1755.  
  1756. The Preload Pages section is an optional section in the
  1757. linear EXE module that coalesces a 'preload page set' into a
  1758. contiguous section. The preload page set can be defined as
  1759. the set of first used pages in the module. The preload page
  1760. set can be specified by the application developer or can be
  1761. derived by a tool that analyzes the programs memory usage
  1762. while it is running. By grouping the preload page set
  1763. together, the preload pages can be read from the linear EXE
  1764. module with one disk read.
  1765.  
  1766. The structure of the preload pages is no different than if
  1767. they were demand loaded. They are non-iterated pages.
  1768. Their sizes are determined by the Object Page Table entries
  1769. that correspond. If the specified size is less than the
  1770. PAGE SIZE field given in the linear EXE module header the
  1771. remainder of the page is filled with zeros when loaded.
  1772.  
  1773. All pages begin on a PAGE OFFSET SHIFT boundary from the
  1774. base of the preload page section, as specified in the linear
  1775. EXE header. The pages are ordered by logical page number
  1776. within this section.
  1777.  
  1778. Note: OS/2 2.0 does not respect preload pages. Performance tests
  1779. showed that better system performance was obtained by not
  1780. respecting the preload request in the executable file.
  1781.  
  1782.  
  1783.  
  1784.  
  1785. Demand Load Pages
  1786.  
  1787.  
  1788. The Demand Loaded Pages section contains all the
  1789. non-iterated pages for a linear EXE module that are not
  1790. preloaded. When required, the whole page is loaded into
  1791. memory from the module. The characteristics of each of
  1792. these pages is specified in the Object Page Table. Every
  1793. page begins on a PAGE OFFSET SHIFT boundary aligned offset
  1794. from the demand loaded pages base specified in the linear
  1795. EXE header. Their sizes are determined by the Object Page
  1796. Table entries that correspond. If the specified size is
  1797. less than the PAGE SIZE field given in the linear EXE module
  1798. header the remainder of the page is filled with zeros when
  1799. loaded. The pages are ordered by logical page number within
  1800. this section.
  1801.  
  1802.  
  1803.  
  1804.  
  1805. Iterated Data Pages
  1806.  
  1807.  
  1808. The Iterated Data Pages section contains all the pages for a
  1809. linear EXE module that are iterated. When required, the set
  1810. of iteration records are loaded into memory from the module
  1811. and expanded to reconstitute the page. Every set of
  1812. iteration records begins on a PAGE OFFSET SHIFT offset from
  1813. the OBJECT ITER PAGES OFF specified in the linear EXE
  1814. header. Their sizes are determined by the Object Page Table
  1815. entries that correspond. The pages are ordered by logical
  1816. page number within this section.
  1817.  
  1818. This record structure is used to describe the iterated data
  1819. for an object on a per-page basis.
  1820.  
  1821. +-----+-----+-----+-----+
  1822. 00h |#ITERATIONS|DATA LENGTH|
  1823. +-----+-----+-----+-----+-----+
  1824. 04h |DATA BYTES | . . . | ... |
  1825. +-----+-----+-----+-----+-----+
  1826.  
  1827. Figure 19. Object Iterated Data Record (Iteration Record)
  1828.  
  1829. #ITERATIONS = DW Number of iterations.
  1830. This specifies the number of times that the data is
  1831. replicated.
  1832.  
  1833. DATA LENGTH = DW The size of the data pattern in bytes.
  1834. This specifies the number of bytes of data of which
  1835. the pattern consists. The maximum size is one half
  1836. of the PAGE SIZE (given in the module header). If a
  1837. pattern exceeds this value then the data page will
  1838. not be condensed into iterated data.
  1839.  
  1840. DATA = DB * DATA LENGTH The Data pattern to be
  1841. replicated.
  1842. The next iteration record will immediately follow
  1843. the last byte of the pattern. The offset of the
  1844. next iteration record is easily calculated from the
  1845. offset of this record by adding the DATA LENGTH
  1846. field and the sizes of the #ITERATIONS and DATA
  1847. LENGTH fields.
  1848.  
  1849.  
  1850.  
  1851.  
  1852.  
  1853. Debug Information
  1854.  
  1855.  
  1856. The debug information is defined by the debugger and is
  1857. not controlled by the linear EXE format or linker. The only
  1858. data defined by the linear EXE format relative to the debug
  1859. information is it's offset in the EXE file and length in
  1860. bytes as defined in the linear EXE header.
  1861.  
  1862. To support multiple debuggers the first word of the debug
  1863. information is a type field which determines the format of
  1864. the debug information.
  1865.  
  1866. 00h 01h 02h 03h 04h
  1867. +-----+-----+-----+-----+-----+-----+-----+-----+
  1868. | 'N' | 'B' | '0' | n | DEBUGGER DATA . . . .
  1869. +-----+-----+-----+-----+-----+-----+-----+-----+
  1870.  
  1871.  
  1872. TYPE = DB DUP 4 Format type.
  1873. This defines the type of debugger data that exists
  1874. in the remainder of the debug information. The
  1875. signature consists of a string of four (4) ASCII
  1876. characters: "NB0" followed by the ASCII
  1877. representation for 'n'. The values for 'n' are
  1878. defined as follows.
  1879.  
  1880. These format types are defined.
  1881.  
  1882. 00h = 32-bit CodeView debugger format.
  1883. 01h = AIX debugger format.
  1884. 02h = 16-bit CodeView debugger format.
  1885. 04h = 32-bit OS/2 PM debugger (IBM) format.
  1886.  
  1887. DEBUGGER DATA = Debugger specific data.
  1888. The format of the debugger data is defined by the
  1889. debugger that is being used.
  1890.  
  1891. The values defined for the type field are not
  1892. enforced by the system. It is the responsibility
  1893. of the linker or debugging tools to follow the
  1894. convention for the type field that is defined here.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!