{"id":1148,"date":"2023-12-30T20:40:35","date_gmt":"2023-12-31T01:40:35","guid":{"rendered":"https:\/\/www.ecsdump.net\/?page_id=1148"},"modified":"2023-12-30T20:40:35","modified_gmt":"2023-12-31T01:40:35","slug":"lx-linear-executable-module-format-description-2","status":"publish","type":"page","link":"https:\/\/www.ecsdump.net\/?page_id=1148","title":{"rendered":"LX – Linear eXecutable Module Format Description"},"content":{"rendered":"\n
\n
           LX - Linear eXecutable Module Format Description \n \n                            June 3, 1992 \n \n \n \n   Figure 1. 32-bit Linear EXE File Layout \n \n       00h +------------------+  <--+ \n           | DOS<\/a> 2 Compatible |     | \n           |    EXE Header    |     | \n       1Ch +------------------+     | \n           |      unused      |     | \n           +------------------+     | \n       24h |  OEM Identifier  |     | \n       26h |  OEM Info        |     | \n           |                  |     |-- DOS 2.0 Section \n       3Ch |  Offset to       |     |   (Discarded) \n           |  Linear EXE      |     | \n           |  Header          |     | \n       40h +------------------+     | \n           |   DOS 2.0 Stub   |     | \n           |   Program &      |     | \n           |   Reloc. Table   |     | \n           +------------------+  <--+ \n           |                  | \n       xxh +------------------+  <--+ \n           |    Executable    |     | \n           |       Info       |     | \n           +------------------+     | \n           |      Module      |     | \n           |       Info       |     | \n           +------------------+     |-- Linear Executable \n           |  Loader Section  |     |   Module Header \n           |       Info       |     |   (Resident) \n           +------------------+     | \n           |   Table Offset   |     | \n           |       Info       |     | \n           +------------------+  <--+ \n           |   Object Table   |     | \n           +------------------+     | \n           | Object Page Table|     | \n           +------------------+     | \n           |  Resource Table  |     | \n           +------------------+     | \n           |  Resident Name   |     | \n           |      Table       |     | \n           +------------------+     |-- Loader Section \n           |   Entry Table    |     |   (Resident) \n           +------------------+     | \n           |   Module Format  |     | \n           | Directives Table |     | \n           |    (Optional)    |     | \n           +------------------+     | \n           |     Resident     |     | \n           | Directives Data  |     | \n           |    (Optional)    |     | \n           |                  |     | \n           |  (Verify Record) |     | \n           +------------------+     | \n           |     Per-Page     |     | \n           |     Checksum     |     | \n           +------------------+  <--+ \n           | Fixup Page Table |     | \n           +------------------+     | \n           |   Fixup Record   |     | \n           |       Table      |     | \n           +------------------+     |-- Fixup Section \n           |   Import Module  |     |   (Optionally Resident) \n           |    Name Table    |     | \n           +------------------+     | \n           | Import Procedure |     | \n           |    Name Table    |     | \n           +------------------+  <--+ \n           |   Preload Pages  |     | \n           +------------------+     | \n           |    Demand Load   |     | \n           |       Pages      |     | \n           +------------------+     | \n           |  Iterated Pages  |     | \n           +------------------+     | \n           |   Non-Resident   |     |-- (Non-Resident) \n           |    Name Table    |     | \n           +------------------+     | \n           |   Non-Resident   |     | \n           | Directives Data  |     | \n           |    (Optional)    |     | \n           |                  |     | \n           |  (To be Defined) |     | \n           +------------------+  <--+ \n           |    Debug Info    |     |-- (Not used by Loader) \n           +------------------+  <--+ \n \n \n \n Figure 2. 32-bit Linear EXE Header \n \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       00h | \"L\"   \"X\" |B-ORD|W-ORD|     FORMAT LEVEL      | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       08h | CPU TYPE  |  OS TYPE  |    MODULE VERSION     | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       10h |     MODULE FLAGS      |   MODULE # OF PAGES   | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       18h |     EIP OBJECT #      |          EIP          | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       20h |     ESP OBJECT #      |          ESP          | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       28h |       PAGE SIZE       |   PAGE OFFSET SHIFT   | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       30h |  FIXUP SECTION SIZE   | FIXUP SECTION CHECKSUM| \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       38h |  LOADER SECTION SIZE  |LOADER SECTION CHECKSUM| \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       40h |    OBJECT TABLE OFF   |  # OBJECTS IN MODULE  | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       48h | OBJECT PAGE TABLE OFF | OBJECT ITER PAGES OFF | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       50h | RESOURCE TABLE OFFSET |#RESOURCE TABLE ENTRIES| \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       58h | RESIDENT NAME TBL OFF |   ENTRY TABLE OFFSET  | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       60h | MODULE DIRECTIVES OFF | # MODULE DIRECTIVES   | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       68h | FIXUP PAGE TABLE OFF  |FIXUP RECORD TABLE OFF | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       70h | IMPORT MODULE TBL OFF | # IMPORT MOD ENTRIES  | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       78h |  IMPORT PROC TBL OFF  | PER-PAGE CHECKSUM OFF | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       80h |   DATA PAGES OFFSET   |    #PRELOAD PAGES     | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       88h | NON-RES NAME TBL OFF  | NON-RES NAME TBL LEN  | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       90h | NON-RES NAME TBL CKSM |   AUTO DS OBJECT #    | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       98h |    DEBUG INFO OFF     |    DEBUG INFO LEN     | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       A0h |   #INSTANCE PRELOAD   |   #INSTANCE DEMAND    | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       A8h |       HEAPSIZE        | \n           +-----+-----+-----+-----+ \n \n Note: The OBJECT ITER PAGES OFF must either be 0 or set to the \n same value as DATA PAGES OFFSET in OS\/2 2.0. Ie., iterated pages are \n required to be in the same section of the file as regular pages. \n \n Note: Table offsets  in the Linear  EXE Header may be set to \n zero  to indicate that the table does not  exist in the  EXE \n file and it's size is zero. \n \n     \"L\" \"X\" = DW  Signature word. \n         The signature word is used by the loader to identify \n         the EXE file as  a valid  32-bit  Linear  Executable \n         Module  Format.  \"L\" is low order byte. \"X\"  is high \n         order byte. \n \n     B-ORD = DB  Byte Ordering. \n         This byte specifies the byte ordering for the linear \n         EXE format.  The values are: \n \n             00H - Little Endian Byte Ordering. \n             01H - Big Endian Byte Ordering. \n \n     W-ORD = DB  Word Ordering. \n         This byte specifies the Word ordering for the linear \n         EXE format.  The values are: \n \n             00H - Little Endian Word Ordering. \n             01H - Big Endian Word Ordering. \n \n     Format Level = DD  Linear EXE Format Level. \n         The  Linear EXE Format Level is set  to  0  for  the \n         initial version  of  the 32-bit linear  EXE  format. \n         Each  incompatible  change to the  linear EXE format \n         must increment this value.  This  allows the  system \n         to recognized future EXE file versions  so  that  an \n         appropriate  error message  may  be displayed  if an \n         attempt is made to load them. \n \n     CPU Type = DW  Module CPU Type. \n         This  field specifies the type  of  CPU required  by \n         this module to run.  The values are: \n \n             01H  -  80286  or  upwardly  compatible  CPU  is \n             required to execute this module. \n             02H  -  80386  or  upwardly  compatible  CPU  is \n             required to execute this module. \n             03H  -  80486  or  upwardly  compatible  CPU  is \n             required to execute this module. \n \n     OS Type = DW  Module OS Type. \n         This field specifies the type  of  Operating  system \n         required to run  this module.  The currently defined \n         values are: \n \n             00H - Unknown (any \"new-format\" OS) \n             01H - OS\/2 (default) \n             02H - Windows \n             03H - DOS 4.x \n             04H - Windows 386 \n \n     MODULE VERSION = DD  Version of the linear EXE module. \n         This is useful for differentiating between revisions \n         of dynamic linked modules.  This  value is specified \n         at link time by the user. \n \n     MODULE FLAGS = DD  Flag bits for the module. \n         The module flag bits have the following definitions. \n \n             00000001h = Reserved for system use. \n             00000002h = Reserved for system use. \n             00000004h = Per-Process Library Initialization. \n                 The setting  of this  bit  requires the  EIP \n                 Object  #  and  EIP  fields  to  have  valid \n                 values.  If the EIP Object # and EIP  fields \n                 are  valid  and this  bit is  NOT  set, then \n                 Global Library  Initialization  is  assumed. \n                 Setting this bit for an EXE file is invalid. \n \n             00000008h = Reserved for system use. \n             00000010h = Internal fixups for the  module have \n             been applied. \n                 The  setting   of  this  bit  in  a   Linear \n                 Executable Module indicates that each object \n                 of  the module  has a preferred load address \n                 specified  in  the Object  Table  Reloc Base \n                 Addr.  If the module's  objects  can  not be \n                 loaded at  these  preferred  addresses, then \n                 the   relocation  records  that  have   been \n                 retained in the file data will be applied. \n \n             00000020h = External fixups for  the module have \n             been applied. \n             00000040h = Reserved for system use. \n             00000080h = Reserved for system use. \n             00000100h = Incompatible with PM windowing. \n             00000200h = Compatible with PM windowing. \n             00000300h = Uses PM windowing API. \n             00000400h = Reserved for system use. \n             00000800h = Reserved for system use. \n             00001000h = Reserved for system use. \n             00002000h = Module is not loadable. \n                 When  the 'Module is  not loadable' flag  is \n                 set, it indicates that  either  errors  were \n                 detected at link  time or that the module is \n                 being  incrementally  linked  and  therefore \n                 can't be loaded. \n \n             00004000h = Reserved for system use. \n             00038000h = Module type mask. \n             00000000h = Program module. \n                 A module  can not  contain  dynamic links to \n                 other modules that have the 'program module' \n                 type. \n \n             00008000h = Library module. \n             00018000h = Protected Memory Library module. \n             00020000h = Physical Device Driver module. \n             00028000h = Virtual Device Driver module. \n             40000000h = Per-process Library Termination. \n                 The  setting of this bit  requires  the  EIP \n                 Object  #  and  EIP  fields  to  have  valid \n                 values.  If the EIP Object  # and EIP fields \n                 are  valid  and  this bit  is NOT  set, then \n                 Global  Library   Termination   is  assumed. \n                 Setting this bit for an EXE file is invalid. \n \n     MODULE # PAGES = DD  Number of pages in module. \n \n         This field specifies the number of  pages physically \n         contained in  this module.  In  other  words,  pages \n         containing  either enumerated or  iterated data,  or \n         zero-fill pages  that have relocations,  not invalid \n         or zero-fill  pages implied by  the  Virtual Size in \n         the Object  Table being  larger  than  the number of \n         pages actually in  the linear EXE file.  These pages \n         are  contained in the  'preload pages', 'demand load \n         pages'  and  'iterated  data pages' sections of  the \n         linear EXE module.  This  is  used  to determine the \n         size  of the page information tables  in  the linear \n         EXE module. \n \n     EIP OBJECT #  = DD The Object number to which  the Entry \n     Address is relative. \n         This specifies the object to which the Entry Address \n         is  relative.  This must be a  nonzero  value  for a \n         program module to be correctly loaded.  A zero value \n         for a library module indicates that no library entry \n         routine exists.  If  this  value  is zero, then both \n         the  Per-process Library Initialization bit and  the \n         Per-process Library Termination bit must be clear in \n         the module flags,  or  else the loader will fail  to \n         load   the  module.  Further,  if  the   Per-process \n         Library Termination  bit is set, then the  object to \n         which  this field  refers  must  be a 32-bit  object \n         (i.e., the Big\/Default bit must be set in the object \n         flags; see below). \n \n     EIP = DD  Entry Address of module. \n         The  Entry  Address  is  the  starting  address  for \n         program modules and  the  library initialization and \n         Library termination address for library modules. \n \n     ESP OBJECT # = DD The Object number to  which the ESP is \n     relative. \n         This  specifies the object to which the starting ESP \n         is relative.  This  must be  a  nonzero  value for a \n         program  module to be correctly  loaded.  This field \n         is ignored for a library module. \n \n     ESP = DD  Starting stack address of module. \n         The  ESP defines the starting stack  pointer address \n         for program modules.  A zero  value  in  this  field \n         indicates   that   the  stack  pointer   is  to   be \n         initialized  to the  highest  address\/offset in  the \n         object.  This field is ignored for a library module. \n \n     PAGE SIZE = DD  The size of one page for this system. \n         This  field  specifies  the  page size  used  by the \n         linear EXE  format and the  system.  For the initial \n         version of this linear  EXE format the page  size is \n         4Kbytes.  (The 4K page size  is specified by a value \n         of 4096 in this field.) \n \n     PAGE OFFSET  SHIFT = DD  The shift left  bits  for  page \n     offsets. \n         This  field  gives the number  of bit  positions  to \n         shift left when interpreting  the  Object Page Table \n         entries' page  offset  field.  This  determines  the \n         alignment  of the page information in the file.  For \n         example, a value of  4 in this field would align all \n         pages in the  Data Pages and Iterated Pages sections \n         on 16  byte  (paragraph)  boundaries.  A Page Offset \n         Shift of 9 would align all pages on a 512 byte (disk \n         sector) basis.  The default  value for this field is \n         12 (decimal), which give a 4096 byte alignment.  All \n         other offsets are byte aligned. \n \n     FIXUP  SECTION  SIZE  =  DD  Total  size  of  the  fixup \n     information in bytes. \n         This includes the following 4 tables: \n \n             - Fixup Page Table \n             - Fixup Record Table \n             - Import Module name Table \n             - Import Procedure Name Table \n \n     FIXUP  SECTION  CHECKSUM   =   DD   Checksum  for  fixup \n     information. \n         This is a cryptographic checksum covering all of the \n         fixup  information.  The  checksum   for  the  fixup \n         information  is kept separate because the fixup data \n         is  not  always loaded into  main  memory  with  the \n         'loader  section'.  If  the  checksum feature is not \n         implemented, then the  linker will set  these fields \n         to zero. \n \n     LOADER  SECTION  SIZE  =  DD  Size  of  memory  resident \n     tables. \n         This  is  the  total  size  in bytes of  the  tables \n         required to be memory resident for the module, while \n         the module is in use.  This total size  includes all \n         tables from the Object  Table down to  and including \n         the Per-Page Checksum Table. \n \n     LOADER  SECTION  CHECKSUM  =  DD  Checksum   for  loader \n     section. \n         This is a cryptographic checksum covering all of the \n         loader section information.  If the checksum feature \n         is not implemented,  then the linker  will set these \n         fields to zero. \n \n     OBJECT TABLE OFF = DD  Object Table offset. \n         This offset  is  relative  to  the  beginning of the \n         linear EXE header. \n \n     # OBJECTS IN MODULE = DD  Object Table Count. \n         This defines the number of entries in Object Table. \n \n     OBJECT PAGE TABLE OFFSET = DD  Object Page Table offset \n         This offset is  relative  to  the beginning  of  the \n         linear EXE header. \n \n     OBJECT  ITER  PAGES  OFF  =  DD  Object  Iterated  Pages \n     offset. \n         This offset is relative to the beginning of  the EXE \n         file. \n \n     RESOURCE TABLE OFF = DD  Resource Table offset. \n         This offset is relative  to  the  beginning  of  the \n         linear EXE header. \n \n     # RESOURCE  TABLE  ENTRIES  = DD  Number  of entries  in \n     Resource Table. \n \n     RESIDENT NAME TBL OFF = DD  Resident Name Table offset. \n         This offset is  relative  to  the  beginning  of the \n         linear EXE header. \n \n     ENTRY TBL OFF = DD  Entry Table offset. \n         This  offset  is  relative  to the beginning of  the \n         linear EXE header. \n \n     MODULE DIRECTIVES  OFF  =  DD  Module  Format Directives \n     Table offset. \n         This  offset  is  relative  to  the beginning of the \n         linear EXE header. \n \n     #  MODULE  DIRECTIVES  =  DD  Number  of  Module  Format \n     Directives in the Table. \n         This field specifies the number  of  entries in  the \n         Module Format Directives Table. \n \n     FIXUP PAGE TABLE OFF = DD  Fixup Page Table offset. \n         This  offset  is  relative to the  beginning of  the \n         linear EXE header. \n \n     FIXUP RECORD TABLE OFF = DD  Fixup Record Table Offset \n         This  offset is relative to  the  beginning  of  the \n         linear EXE header. \n \n     IMPORT  MODULE  TBL  OFF = DD  Import  Module Name Table \n     offset. \n         This  offset is relative  to  the  beginning of  the \n         linear EXE header. \n \n     # IMPORT MOD ENTRIES = DD  The  number of entries in the \n     Import Module Name Table. \n \n     IMPORT PROC TBL OFF  =  DD  Import Procedure  Name Table \n     offset. \n         This offset  is relative  to  the  beginning of  the \n         linear EXE header. \n \n     PER-PAGE CHECKSUM  OFF  =  DD  Per-Page  Checksum  Table \n     offset. \n         This  offset is  relative  to  the beginning of  the \n         linear EXE header. \n \n     DATA PAGES OFFSET = DD   Data Pages Offset. \n         This offset is  relative to the beginning of the EXE \n         file. \n \n     # PRELOAD PAGES = DD  Number  of  Preload pages for this \n     module. Note that OS\/2 2.0 does not respect the preload \n     of pages as specified in the executable file for performance \n     reasons. \n \n     NON-RES NAME  TBL  OFF  =  DD  Non-Resident  Name  Table \n     offset. \n         This offset is relative to the beginning of  the EXE \n         file. \n \n     NON-RES  NAME  TBL  LEN = DD  Number  of  bytes  in  the \n     Non-resident name table. \n \n     NON-RES  NAME TBL CKSM  =  DD  Non-Resident  Name  Table \n     Checksum. \n         This is a cryptographic checksum of the Non-Resident \n         Name Table. \n \n     AUTO  DS OBJECT  #  =  DD  The Auto Data  Segment Object \n     number. \n         This is the object number for  the Auto Data Segment \n         used by 16-bit modules.  This field is supported for \n         16-bit compatibility only and is not used by  32-bit \n         modules. \n \n     DEBUG INFO OFF = DD  Debug Information offset. \n         This offset  is relative  to  the  beginning  of the \n         linear EXE header. \n \n     DEBUG INFO LEN = DD  Debug Information length. \n         The length of the debug information in bytes. \n \n      #  INSTANCE  PRELOAD  = DD Instance  pages  in  preload \n     section. \n         The  number  of instance  data pages  found  in  the \n         preload section. \n \n      #  INSTANCE  DEMAND  =  DD  Instance  pages  in  demand \n     section. \n         The  number  of instance  data pages  found  in  the \n         demand section. \n \n      HEAPSIZE = DD Heap size added to the Auto DS Object. \n         The heap size is the  number  of  bytes added to the \n         Auto  Data  Segment  by the loader.  This  field  is \n         supported for  16-bit compatibility only and is  not \n         used by 32-bit modules. \n \n \n \n \n \n     Program (EXE) startup registers and Library entry registers \n \n \n     Program startup registers are defined as follows. \n \n         EIP = Starting program entry address. \n \n         ESP = Top of stack address. \n \n         CS = Code selector for base of linear address space. \n \n         DS =  ES  = SS = Data  selector  for  base of linear \n         address space. \n \n         FS =  Data selector  of  base of Thread  Information \n         Block (TIB). \n \n         GS = 0. \n \n         EAX = EBX = 0. \n \n         ECX = EDX = 0. \n \n         ESI = EDI = 0. \n \n         EBP = 0. \n \n         [ESP+0] =  Return  address to  routine  which  calls \n         DosExit(1,EAX). \n \n         [ESP+4] = Module handle for program module. \n \n         [ESP+8] = Reserved. \n \n         [ESP+12] = Environment data object address. \n \n         [ESP+16]   =   Command  line   linear   address   in \n         environment data object. \n \n \n     Library initialization registers are defined as follows. \n \n         EIP = Library entry address. \n \n         ESP = User program stack. \n \n         CS = Code selector for base of linear address space. \n \n         DS  = ES = SS = Data  selector  for  base  of linear \n         address space. \n \n         Note that a  32-bit Protected Memory Library  module \n         will be  given  a  GDT  selector in  the  DS  and ES \n         registers (PROTDS)  that  addresses the  full linear \n         address  space  available  to  a  application.  This \n         selector  should  be  saved  by  the  initialization \n         routine.  Non-Protected  Memory Library modules will \n         receive a selector (FLATDS) that  addresses the same \n         amount of linear  address  space as an application's \n         .EXE can. \n \n         FS  = Data selector  of base  of  Thread Information \n         Block (TIB). \n \n         GS = 0. \n \n         EAX = EBX = 0. \n \n         ECX = EDX = 0. \n \n         ESI = EDI = 0. \n \n         EBP = 0. \n \n         [ESP+0] = Return address to system, (EAX)  =  return \n         code. \n \n         [ESP+4] = Module handle for library module. \n \n         [ESP+8] = 0 (Initialization) \n \n     Note that a  32-bit  library may specify  that its entry \n     address is  in  a 16-bit code object.  In this case, the \n     entry registers are the same  as for  entry to a library \n     using the Segmented  EXE format.  These  are  documented \n     elsewhere.  This  means  that  a  16-bit  library may be \n     relinked to take advantage of the benefits of the Linear \n     EXE format (notably, efficient paging). \n \n \n     Library termination registers are defined as follows. \n \n         EIP = Library entry address. \n \n         ESP = User program stack. \n \n         CS = Code selector for base of linear address space. \n \n         DS  =  ES  = SS  = Data  selector for base of linear \n         address space. \n \n         FS  =  Data  selector of base of  Thread Information \n         Block (TIB). \n \n         GS = 0. \n \n         EAX = EBX = 0. \n \n         ECX = EDX = 0. \n \n         ESI = EDI = 0. \n \n         EBP = 0. \n \n         [ESP+0] = Return address to system. \n \n         [ESP+4] = Module handle for library module. \n \n         [ESP+8] = 1 (Termination) \n \n     Note  that  Library  termination  is  not  allowed   for \n     libraries with 16-bit entries. \n \n \n \n \n \n     Object Table \n \n \n The number of entries in the Object Table  is given by the # \n Objects in Module  field  in the linear EXE header.  Entries \n in the Object Table are numbered starting from one. \n \n Each Object Table entry has the following format: \n \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       00h |     VIRTUAL SIZE      |    RELOC BASE ADDR    | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       08h |     OBJECT FLAGS      |    PAGE TABLE INDEX   | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       10h |  # PAGE TABLE ENTRIES |       RESERVED        | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n \n     VIRTUAL SIZE = DD  Virtual memory size. \n         This  is  the  size  of  the  object  that  will  be \n         allocated  when the object is loaded.  The  object's \n         virtual  size (rounded  up to  the page  size value) \n         must be  greater than or equal to the total  size of \n         the  pages  in the  EXE  file  for the object.  This \n         memory size must also be large enough to contain all \n         of the iterated data and uninitialized  data in  the \n         EXE file. \n \n     RELOC BASE ADDR = DD Relocation Base Address. \n         The relocation base  address the object is currently \n         relocated to.  If the internal relocation fixups for \n         the  module have been  removed, this is  the address \n         the object will be allocated at by the loader. \n \n     OBJECT FLAGS = DW  Flag bits for the object. \n         The object flag bits have the following definitions. \n \n             0001h = Readable Object. \n             0002h = Writable Object. \n             0004h = Executable Object. \n                 The readable,  writable and executable flags \n                 provide    support    for    all    possible \n                 protections.  In systems where  all of these \n                 protections are not  supported,  the  loader \n                 will   be   responsible   for   making   the \n                 appropriate protection match for the system. \n \n             0008h = Resource Object. \n             0010h = Discardable Object. \n             0020h = Object is Shared. \n             0040h = Object has Preload Pages. \n             0080h = Object has Invalid Pages. \n             0100h = Object has Zero Filled Pages. \n             0200h = Object is Resident (valid for VDDs, PDDs \n             only). \n             0300h = Object is Resident  &  Contiguous (VDDs, \n             PDDs only). \n             0400h  =  Object is  Resident  & 'long-lockable' \n             (VDDs, PDDs only). \n             0800h = Reserved for system use. \n             1000h = 16:16 Alias Required (80x86 Specific). \n             2000h   =   Big\/Default   Bit   Setting   (80x86 \n             Specific). \n                 The 'big\/default'  bit , for data  segments, \n                 controls the setting of the Big  bit  in the \n                 segment descriptor.  (The Big bit, or B-bit, \n                 determines whether ESP or SP is used  as the \n                 stack pointer.)  For code segments, this bit \n                 controls the setting of the  Default  bit in \n                 the segment descriptor.  (The  Default  bit, \n                 or  D-bit, determines  whether  the  default \n                 word  size  is 32-bits or 16-bits.  It  also \n                 affects   the    interpretation    of    the \n                 instruction stream.) \n \n             4000h =  Object is  conforming  for  code (80x86 \n             Specific). \n             8000h  =  Object  I\/O  privilege   level  (80x86 \n             Specific). \n                 Only used for 16:16 Alias Objects. \n \n     PAGE TABLE INDEX = DD  Object Page Table Index. \n         This specifies the number of  the first  object page \n         table  entry for this object.  The object page table \n         specifies where in the EXE file a page  can be found \n         for   a   given   object   and   specifies  per-page \n         attributes. \n \n         The object table entries are ordered by logical page \n         in the  object  table.  In  other  words  the object \n         table entries  are sorted based  on  the object page \n         table index value. \n \n     #  PAGE TABLE ENTRIES  =  DD  #  of  object  page  table \n     entries for this object. \n         Any logical pages at the  end  of an  object that do \n         not  have  an   entry   in  the  object  page  table \n         associated  with them are handled as zero  filled or \n         invalid pages by the loader. \n \n         When the last  logical pages  of an  object  are not \n         specified with an object page table entry,  they are \n         treated as either zero filled pages or invalid pages \n         based on the last entry in the object page table for \n         that object.  If  the last entry was  neither a zero \n         filled  or invalid  page, then the additional  pages \n         are treated as zero filled pages. \n \n     RESERVED = DD  Reserved for future use.  Must  be set to \n     zero. \n \n \n \n     Object Page Table \n \n \n The  Object  page table provides information about a logical \n page in  an object.  A  logical  page  may be  an enumerated \n page, a pseudo page or an iterated  page.  The  structure of \n the  object page table in conjunction with the  structure of \n the  object table allows for efficient access of a page when \n a page fault occurs, while  still allowing the physical page \n data to be located  in the preload page, demand load page or \n iterated data  page sections in the linear  EXE  module. The \n logical page entries  in the Object Page Table  are numbered \n starting from one.  The Object Page Table is parallel to the \n Fixup  Page Table  as  they are both indexed by the  logical \n page number. \n \n Each Object Page Table entry has the following format: \n \n          63                     32 31       16 15         0 \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n       00h |    PAGE DATA OFFSET   | DATA SIZE |   FLAGS   | \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n \n     PAGE DATA OFFSET = DD  Offset  to  the page  data in the \n     EXE file. \n         This field, when bit shifted left by the PAGE OFFSET \n         SHIFT from the  module header, specifies  the offset \n         from  the beginning of  the Preload Page section  of \n         the  physical  page  data  in   the  EXE  file  that \n         corresponds to this logical  page  entry.  The  page \n         data  may  reside in the  Preload Pages, Demand Load \n         Pages or the Iterated Data Pages sections. \n \n         If  the  FLAGS  field  specifies  that  this  is   a \n         zero-Filled page  then the  PAGE DATA  OFFSET  field \n         will contain a 0. \n \n         If the logical page is specified as an iterated data \n         page,  as  indicated  by the FLAGS field, then  this \n         field specifies the  offset into the  Iterated  Data \n         Pages section. \n \n         The logical page number  (Object Page  Table index), \n         is  used  to index  the Fixup Page Table to find any \n         fixups associated with the logical page. \n \n \n     DATA SIZE = DW  Number of bytes of data for this page. \n         This field specifies the actual number of bytes that \n         represent the page in  the  file.  If  the PAGE SIZE \n         field  from the  module header is greater  than  the \n         value of this  field and the FLAGS field indicates a \n         Legal Physical  Page,  the remaining bytes are to be \n         filled with zeros.  If  the FLAGS field indicates an \n         Iterated  Data Page,  the iterated data records will \n         completely fill out the remainder. \n \n \n     FLAGS =  DW  Attributes  specifying  characteristics  of \n     this logical page. \n         The bit definitions for this word field follow, \n \n             00h = Legal Physical Page  in the module (Offset \n             from Preload Page Section). \n             01h  = Iterated Data Page (Offset from  Iterated \n             Data Pages Section). \n             02h = Invalid Page (zero). \n             03h = Zero Filled Page (zero). \n             04h = Range of Pages. \n \n \n \n \n     Resource Table \n \n \n The resource table is  an array of  resource  table entries. \n Each resource  table entry  contains  a type ID and name ID. \n These entries  are used to locate resource objects contained \n in the Object table.  The number  of entries in the resource \n table is defined by the  Resource Table Count located in the \n linear EXE  header.  More than one resource may be contained \n within  a  single  object.  Resource table entries are in  a \n sorted  order,  (ascending,  by Resource Name ID  within the \n Resource  Type  ID).  This  allows  the  DosGetResource  API \n function to use a binary search when looking  up  a resource \n in  a 32-bit module instead of the linear  search being used \n in the current 16-bit module. \n \n Each resource entry has the following format: \n \n           +-----+-----+-----+-----+ \n       00h |  TYPE ID  |  NAME ID  | \n           +-----+-----+-----+-----+ \n       04h |     RESOURCE SIZE     | \n           +-----+-----+-----+-----+-----+-----+ \n       08h |   OBJECT  |        OFFSET         | \n           +-----+-----+-----+-----+-----+-----+ \n \n \n     TYPE ID = DW  Resource type ID. \n         The type of resources are: \n \n             BTMP = Bitmap \n             EMSG = Error message string \n             FONT = Fonts \n \n     NAME ID = DW  An ID used as a name for the resource when \n     referred to. \n \n     RESOURCE SIZE =  DD  The  number of  bytes the  resource \n     consists of. \n \n     OBJECT = DW  The number of the object which contains the \n     resource. \n \n     OFFSET  = DD  The  offset  within the  specified  object \n     where the resource begins. \n \n \n \n \n \n     Resident or Non-resident Name Table Entry \n \n \n The  resident and  non-resident name tables define the ASCII \n names  and  ordinal  numbers  for  exported  entries  in the \n module.  In  addition the first  entry in the resident  name \n table contains  the  module name. These tables  are  used to \n translate a procedure name  string into an ordinal number by \n searching for a matching name string.  The ordinal number is \n used  to  locate the  entry  point information in the  entry \n table. \n \n The resident name  table is kept  resident  in system memory \n while the  module is loaded.  It is intended to contain  the \n exported  entry point names  that  are frequently dynamicaly \n linked to  by  name.  Non-resident  names  are  not  kept in \n memory and are read from the  EXE file when a  dynamic  link \n reference  is made.  Exported  entry  point  names  that are \n infrequently dynamicaly linked to by  name  or are  commonly \n referenced  by  ordinal  number  should  be  placed  in  the \n non-resident name  table.  The trade off made for references \n by name is performance vs memory usage. \n \n Import  references  by  name  require  these  tables  to  be \n searched  to  obtain the entry point ordinal number.  Import \n references  by  ordinal  number  provide the fastest  lookup \n since the search of these tables is not required. \n \n The strings are CASE SENSITIVE and are NOT NULL TERMINATED. \n \n Each name table entry has the following format: \n \n           +-----+-----+-----+-----+     +-----+-----+-----+ \n       00h | LEN |    ASCII STRING  . . .      | ORDINAL # | \n           +-----+-----+-----+-----+     +-----+-----+-----+ \n \n \n     LEN = DB  String Length. \n         This  defines the length  of the string in bytes.  A \n         zero length indicates there  are no more  entries in \n         table.  The length of  each  ascii  name  string  is \n         limited to 127 characters. \n \n         The high bit in  the LEN field (bit 7) is defined as \n         an Overload bit.  This bit signifies that additional \n         information is contained in  the  linear  EXE module \n         and will be  used in the  future  for parameter type \n         checking. \n \n     ASCII STRING = DB  ASCII String. \n         This is a variable length string  with  it's  length \n         defined  in  bytes by the LEN field.  The string  is \n         case case sensitive and is not null terminated. \n \n     ORDINAL # = DW  Ordinal number. \n         The ordinal number  in  an  ordered  index  into the \n         entry table for this entry point. \n \n \n \n \n \n     Entry Table \n \n \n The entry table contains object  and offset information that \n is used to resolve fixup  references  to  the  entry  points \n within this module.  Not all entry points in the entry table \n will be exported, some entry points will only be used within \n the module.  An  ordinal number is  used to  index  into the \n entry table.  The entry table entries  are numbered starting \n from one. \n \n The  list  of  entries  are compressed into 'bundles', where \n possible.  The entries within  each bundle are all the  same \n size.  A bundle starts with  a  count field  which indicates \n the number of entries in the bundle.  The  count is followed \n by a  type field  which identifies the  bundle format.  This \n provides  both  a  means  for  saving  space as  well  as  a \n mechanism for extending the bundle types. \n \n The type field  allows  the  definition of 256 bundle types. \n The following bundle types will initially be defined: \n \n     Unused Entry. \n     16-bit Entry. \n     286 Call Gate Entry. \n     32-bit Entry. \n     Forwarder Entry. \n \n The bundled entry table has the following format: \n \n           +-----+-----+-----+-----+-----+ \n       00h | CNT |TYPE | BUNDLE INFO . . . \n           +-----+-----+-----+-----+-----+ \n \n \n     CNT = DB  Number of entries. \n         This is the number of entries in this bundle. \n \n         A  zero value for  the number of entries  identifies \n         the  end of the entry  table.  There  is no  further \n         bundle  information when  the number  of entries  is \n         zero.  In other words the entry  table is terminated \n         by a single zero byte. \n \n     TYPE = DB  Bundle type. \n         This  defines the  bundle type  which determines the \n         contents of the BUNDLE INFO. \n \n             The follow types are defined: \n \n                 00h = Unused Entry. \n                 01h = 16-bit Entry. \n                 02h = 286 Call Gate Entry. \n                 03h = 32-bit Entry. \n                 04h = Forwarder Entry. \n                 80h = Parameter Typing Information Present. \n                     This   bit  signifies   that  additional \n                     information  is contained in the  linear \n                     EXE module  and  will  be  used  in  the \n                     future for parameter type checking. \n \n \n     The following is the format for each bundle type: \n \n               +-----+-----+ \n           00h | CNT |TYPE | \n               +-----+-----+ \n \n         CNT = DB  Number of entries. \n             This is the number of unused entries to skip. \n \n         TYPE = DB  0 (Unused Entry) \n \n               +-----+-----+-----+-----+ \n           00h | CNT |TYPE |   OBJECT  | \n               +-----+-----+-----+-----+ \n           04h |FLAGS|  OFFSET   | \n               +-----+-----+-----+ \n           07h | ... |   . . .   | \n               +     +     +     + \n \n \n         CNT = DB  Number of entries. \n             This is the  number of 16-bit  entries  in  this \n             bundle.  The flags and offset value are repeated \n             this number of times. \n \n         TYPE = DB  1 (16-bit Entry) \n \n             OBJECT = DW  Object number. \n                 This is the object number for the entries in \n                 this bundle. \n \n             FLAGS = DB  Entry flags. \n                 These  are the  flags for this entry  point. \n                 They have the following definition. \n \n                     01h = Exported entry flag. \n                     F8h = Parameter word count mask. \n \n             OFFSET = DW  Offset in object. \n                 This is the  offset  in the  object for  the \n                 entry point defined at this ordinal number. \n \n \n               +-----+-----+-----+-----+ \n           00h | CNT |TYPE |   OBJECT  | \n               +-----+-----+-----+-----+-----+ \n           04h |FLAGS|  OFFSET   | CALLGATE  | \n               +-----+-----+-----+-----+-----+ \n           09h | ... |   . . .   |   . . .   | \n               +     +     +     +     +     + \n \n \n         CNT = DB  Number of entries. \n             This is  the number of 286  call gate entries in \n             this  bundle.  The  flags,  callgate, and offset \n             value are repeated this number of times. \n \n         TYPE = DB  2 (286 Call Gate Entry) \n             The 286 Call Gate Entry  Point type is needed by \n             the loader only  if ring  2 segments  are to  be \n             supported.  286  Call  Gate  entries  contain  2 \n             extra bytes  which  are  used by  the  loader to \n             store an LDT callgate selector value. \n \n         OBJECT = DW  Object number. \n             This is the  object  number  for the  entries in \n             this bundle. \n \n         FLAGS = DB  Entry flags. \n             These are the flags  for this entry point.  They \n             have the following definition. \n \n                 01h = Exported entry flag. \n                 F8h = Parameter word count mask. \n \n         OFFSET = DW  Offset in object. \n             This is the offset in the object  for  the entry \n             point defined at this ordinal number. \n \n         CALLGATE = DW  Callgate selector. \n             The callgate  selector is a  reserved field used \n             by the  loader  to store a  call  gate  selector \n             value for references  to  ring  2  entry points. \n             When a  ring 3 reference to a ring 2 entry point \n             is  made,  the  callgate  selector with  a  zero \n             offset is place in the relocation fixup address. \n             The  segment  number  and  offset  in segment is \n             placed in the LDT callgate. \n \n \n               +-----+-----+-----+-----+ \n           00h | CNT |TYPE |   OBJECT  | \n               +-----+-----+-----+-----+-----+ \n           04h |FLAGS|        OFFSET         | \n               +-----+-----+-----+-----+-----+ \n           09h | ... |         . . .         | \n               +     +     +     +     +     + \n \n         CNT = DB  Number of entries. \n             This is  the  number  of  32-bit entries in this \n             bundle.  The flags and offset value are repeated \n             this number of times. \n \n         TYPE = DB  3 (32-bit Entry) \n             The 32-bit Entry type will  only be  defined  by \n             the linker when the offset in the object can not \n             be specified by a 16-bit offset. \n \n         OBJECT = DW  Object number. \n             This  is  the object  number for the  entries in \n             this bundle. \n \n         FLAGS = DB  Entry flags. \n             These are the  flags for this entry point.  They \n             have the following definition. \n \n                 01h = Exported entry flag. \n                 F8h = Parameter dword count mask. \n \n         OFFSET = DD  Offset in object. \n             This is  the  offset in the object for the entry \n             point defined at this ordinal number. \n \n           +-----+-----+-----+-----+ \n       00h | CNT |TYPE | RESERVED  | \n           +-----+-----+-----+-----+-----+-----+-----+ \n       04h |FLAGS| MOD ORD#  | OFFSET \/ ORDNUM       | \n           +-----+-----+-----+-----+-----+-----+-----+ \n       09h | ... |    ...    |          ...          | \n           +     +     +     +     +     +     +     + \n \n     CNT = DB  Number of entries. \n         This  is  the number  of forwarder  entries in  this \n         bundle.  The  FLAGS,  MOD  ORD#,  and  OFFSET\/ORDNUM \n         values are repeated this number of times. \n \n     TYPE = DB  4 (Forwarder Entry) \n \n     RESERVED = DW 0 \n         This field is reserved for future use. \n \n     FLAGS = DB  Forwarder flags. \n         These  are the flags  for  this  entry  point.  They \n         have the following definition. \n \n             01h = Import by ordinal. \n             F7h = Reserved for future use; should be zero. \n \n     MOD ORD# = DW Module Ordinal Number \n         This  is the index into the Import Module Name Table \n         for this forwarder. \n \n     OFFSET  \/  ORDNUM = DD Procedure  Name Offset  or Import \n     Ordinal Number \n         If the FLAGS field indicates import by ordinal, then \n         this field  is  the  ordinal number  into  the Entry \n         Table of the target module, otherwise this  field is \n         the  offset  into the Procedure Names Table  of  the \n         target module. \n \n A Forwarder entry (type  = 4) is  an entry point whose value \n is an imported  reference.  When  a load  time  fixup occurs \n whose target is a forwarder, the  loader obtains the address \n imported by the forwarder and  uses that imported address to \n resolve the fixup. \n \n A forwarder  may refer  to an entry point  in another module \n which  is itself a  forwarder, so there  can be a  chain  of \n forwarders.  The  loader  will traverse the chain  until  it \n finds a non-forwarded entry point which terminates the chain \n ,  and  use  this to  resolve  the original fixup.  Circular \n chains are detected by the loader  and result in a load time \n error.  A  maximum of 1024 forwarders is allowed in a chain; \n more than this results in a load time error. \n \n Forwarders  are useful for merging and recombining API calls \n into  different  sets   of   libraries,   while  maintaining \n compatibility with applications.  For example, if one wanted \n to  combine MONCALLS,  MOUCALLS,  and VIOCALLS into a single \n libraries, one  could  provide entry  points  for  the three \n libraries  that   are  forwarders  pointing  to  the  common \n implementation. \n \n \n \n     Module Format Directives Table \n \n \n The Module Format Directives Table is an optional table that \n allows additional options to  be specified.  It also  allows \n for  the extension of the  linear  EXE  format  by  allowing \n additional tables  of  information to be added to the linear \n EXE  module  without affecting the format  of the linear EXE \n header.  Likewise,  module format directives provide a place \n in   the   linear  EXE  module  for  'temporary  tables'  of \n information,  such as  incremental linking  information  and \n statistic information  gathered  on the module.  When  there \n are no module format directives for a linear EXE module, the \n fields  in  the linear EXE  header  referencing  the  module \n format directives table are zero. \n \n Each Module  Format Directive Table entry  has the following \n format: \n \n           +-----+-----+-----+-----+-----+-----+----+----+ \n       00h | DIRECT #  | DATA LEN  |     DATA OFFSET     | \n           +-----+-----+-----+-----+-----+-----+----+----+ \n \n     DIRECT # = DW  Directive number. \n         The directive number specifies the type of directive \n         defined.  This  can be used to  determine the format \n         of  the  information  in  the  directive  data.  The \n         following directive numbers have been defined: \n \n             8000h = Resident Flag Mask. \n                 Directive numbers with this bit set indicate \n                 that the directive data is in  the  resident \n                 area and will  be kept  resident  in  memory \n                 when the module is loaded. \n \n             8001h = Verify Record Directive. (Verify  record \n             is a resident table.) \n             0002h = Language Information Directive. (This is \n             a non-resident table.) \n             0003h = Co-Processor Required Support Table. \n             0004h = Thread State Initialization Directive. \n \n         Additional directives can be  added as needed in the \n         future, as long as  they  do  not overlap previously \n         defined directive numbers. \n \n     DATA LEN = DW  Directive data length. \n         This specifies the length in  byte of  the directive \n         data for this directive number. \n \n     DIRECTIVE OFFSET = DD  Directive data offset. \n         This  is the offset to  the directive data for  this \n         directive number.  It  is  relative to beginning  of \n         linear EXE header for a resident table, and relative \n         to  the  beginning of the EXE  file for non-resident \n         tables. \n \n \n \n \n \n     Verify Record Directive Table \n \n \n The Verify Record Directive Table  is an optional table.  It \n maintains a record  of  the pages in  the EXE file that have \n been  fixed up  and written back to the  original linear EXE \n module, along with the  module  dependencies used to perform \n these fixups.  This table  provides  an  efficient means for \n verifying the  virtual  addresses  required for the fixed up \n pages when the module is loaded. \n \n Each Verify Record entry has the following format: \n \n           +-----+-----+ \n       00h |# OF ENTRY | \n           +-----+-----+-----+-----+-----+-----+ \n       02h | MOD ORD # |  VERSION  | MOD # OBJ | \n           +-----+-----+-----+-----+-----+-----+ \n       08h | OBJECT #  | BASE ADDR |  VIRTUAL  | \n           +-----+-----+-----+-----+-----+-----+ \n       0Eh |   . . .   |   . . .   |   . . .   | \n           +     +     +     +     +     +     + \n \n     # OF ENTRY = DW  Number of module dependencies. \n         This field specifies how many  entries there  are in \n         the verify record directive table.  This is equal to \n         the number of modules referenced by this module. \n \n     MOD  ORD # = DW  Ordinal index  into  the  Import Module \n     Name Table. \n         This value is an ordered  index  in  to  the  Import \n         Module Name Table for the referenced module. \n \n     VERSION = DW  Module Version. \n \n         This  is the version of  the  referenced module that \n         the fixups  were originally performed.  This is used \n         to insure the same version  of the referenced module \n         is  loaded  that  was  fixed up  in this module  and \n         therefore   the   fixups  are  still  correct.  This \n         requires  the  version number  in  a  module  to  be \n         incremented anytime the entry point offsets change. \n \n     MOD # OBJ = DW  Module # of Object Entries. \n         This field is used to  identify the number of object \n         verify  entries  that   follow  for  the  referenced \n         module. \n \n     OBJECT # = DW  Object # in Module. \n         This  field  specifies  the  object  number  in  the \n         referenced module that is being verified. \n \n     BASE ADDR = DW  Object load base address. \n         This is  the  address that the object was  loaded at \n         when the fixups were performed. \n \n     VIRTUAL = DW  Object virtual address size. \n         This field specifies the  total  amount  of  virtual \n         memory required for this object. \n \n \n \n \n \n     Per-Page Checksum \n \n \n The  Per-Page   Checksum   table   provides   space   for  a \n cryptographic  checksum for each  physical  page  in the EXE \n file. \n \n The checksum table is arranged such that the first entry  in \n the table corresponds to the first logical page of code\/data \n in the EXE file (usually a preload page) and the  last entry \n corresponds to  the  last  logical  page  in  the  EXE  file \n (usually a iterated data page). \n \n                     +-----+-----+-----+-----+ \n    Logical Page #1  |        CHECKSUM       | \n                     +-----+-----+-----+-----+ \n    Logical Page #2  |        CHECKSUM       | \n                     +-----+-----+-----+-----+ \n                               . . . \n \n                     +-----+-----+-----+-----+ \n    Logical Page #n  |        CHECKSUM       | \n                     +-----+-----+-----+-----+ \n \n \n     CHECKSUM = DD  Cryptographic checksum. \n \n \n \n \n \n     Fixup Page Table \n \n \n The Fixup Page Table provides a simple  mapping of a logical \n page number to an  offset  into  the Fixup Record  Table for \n that page. \n \n This table is parallel to the Object Page Table, except that \n there is one  additional entry in this table to indicate the \n end of the Fixup Record Table. \n \n The format of each entry is: \n \n                   +-----+-----+-----+-----+ \n  Logical Page #1  |  OFFSET FOR PAGE #1   | \n                   +-----+-----+-----+-----+ \n  Logical Page #2  |  OFFSET FOR PAGE #2   | \n                   +-----+-----+-----+-----+ \n                             . . . \n                   +-----+-----+-----+-----+ \n  Logical Page #n  |  OFFSET FOR PAGE #n   | \n                   +-----+-----+-----+-----+ \n                   |OFF TO END OF FIXUP REC|   This is equal to: \n                   +-----+-----+-----+-----+   Offset for page #n + Size \n                                               of fixups for page #n \n \n \n     OFFSET FOR PAGE # = DD  Offset for fixup record for this \n     page. \n         This  field specifies the offset, from the beginning \n         of the fixup record table, to the first fixup record \n         for this page. \n \n     OFF TO  END  OF FIXUP REC = DD  Offset to the end of the \n     fixup records. \n         This field specifies  the offset  following the last \n         fixup record in the fixup record table.  This is the \n         last entry in the fixup page table. \n \n         The fixup records are kept in order by logical  page \n         in the fixup record table.  This  allows the end  of \n         each page's fixup records  is defined by  the offset \n         for  the  next logical  page's fixup  records.  This \n         last  entry provides  support of this mechanism  for \n         the last page in the fixup page table. \n \n \n \n \n \n     Fixup Record Table \n \n \n The  Fixup  Record Table contains entries  for all fixups in \n the linear EXE module.  The fixup records for a logical page \n are  grouped together and kept  in  sorted order by  logical \n page number.  The  fixups for  each page are  further sorted \n such that all external fixups  and internal selector\/pointer \n fixups come before internal non-selector\/non-pointer fixups. \n This allows  the  loader  to  ignore internal fixups  if the \n loader  is  able  to  load  all  objects  at  the  addresses \n specified in the object table. \n \n Each relocation record has the following format: \n \n           +-----+-----+-----+-----+ \n       00h | SRC |FLAGS|SRCOFF\/CNT*| \n           +-----+-----+-----+-----+-----+-----+ \n   03h\/04h |           TARGET DATA *           | \n           +-----+-----+-----+-----+-----+-----+ \n           | SRCOFF1 @ |   . . .   | SRCOFFn @ | \n           +-----+-----+----   ----+-----+-----+ \n \n         * These fields are variable size. \n         @ These fields are optional. \n \n \n     SRC = DB  Source type. \n         The source type specifies the  size  and type of the \n         fixup to  be  performed  on  the  fixup source.  The \n         source type is defined as follows: \n \n             0Fh = Source mask. \n             00h = Byte fixup (8-bits). \n             01h = (undefined). \n             02h = 16-bit Selector fixup (16-bits). \n             03h = 16:16 Pointer fixup (32-bits). \n             04h = (undefined). \n             05h = 16-bit Offset fixup (16-bits). \n             06h = 16:32 Pointer fixup (48-bits). \n             07h = 32-bit Offset fixup (32-bits). \n             08h   =   32-bit  Self-relative   offset   fixup \n             (32-bits). \n             10h = Fixup to Alias Flag. \n                 When the 'Fixup to Alias' Flag is  set,  the \n                 source fixup refers to  the 16:16  alias for \n                 the  object.  This is only  valid for source \n                 types  of 2, 3, and 6.  For  fixups such  as \n                 this, the linker and loader will be required \n                 to   perform   additional   checks  such  as \n                 ensuring that the  target  offset  for  this \n                 fixup is less than 64K. \n \n             20h = Source List Flag. \n \n                 When  the  'Source  List'  Flag is set,  the \n                 SRCOFF field  is compressed  to  a byte  and \n                 contains the number of source offsets, and a \n                 list  of source  offsets  follows the end of \n                 fixup  record (after  the  optional additive \n                 value). \n \n     FLAGS = DB  Target Flags. \n         The target flags specify how the target  information \n         is interpreted.  The  target flags  are  defined  as \n         follows: \n \n             03h = Fixup target type mask. \n             00h = Internal reference. \n             01h = Imported reference by ordinal. \n             02h = Imported reference by name. \n             03h = Internal reference via entry table. \n             04h = Additive Fixup Flag. \n                 When set, an additive value trails the fixup \n                 record (before the  optional  source  offset \n                 list). \n \n             08h = Reserved.  Must be zero. \n             10h = 32-bit Target Offset Flag. \n                 When  set, the  target  offset  is  32-bits, \n                 otherwise it is 16-bits. \n \n             20h = 32-bit Additive Fixup Flag. \n                 When set,  the  additive value  is  32-bits, \n                 otherwise it is 16-bits. \n \n             40h = 16-bit Object Number\/Module Ordinal Flag. \n                 When  set,  the   object  number  or  module \n                 ordinal number  is 16-bits, otherwise  it is \n                 8-bits. \n \n             80h = 8-bit Ordinal Flag. \n                 When  set,  the  ordinal number  is  8-bits, \n                 otherwise it is 16-bits. \n \n     SRCOFF =  DW\/CNT  = DB  Source  offset  or source offset \n     list count. \n         This field contains  either  an  offset  or  a count \n         depending on the  Source  List Flag.  If the  Source \n         List Flag is  set,  a list of source offsets follows \n         the additive field and this field contains the count \n         of  the  entries   in   the   source   offset  list. \n         Otherwise, this is the single source offset for  the \n         fixup.  Source offsets are relative to the beginning \n         of the page where the fixup is to be made. \n \n         Note that for fixups that  cross page  boundaries, a \n         separate  fixup  record is  specified for each page. \n         An offset is still used for the 2nd  page but it now \n         becomes a negative offset since the fixup originated \n         on  the  preceding page.  (For  example, if only the \n         last one byte of a 32-bit address is on the page  to \n         be fixed up, then the offset would  have  a value of \n         -3.) \n \n     TARGET DATA = Target data for fixup. \n         The  format of the  TARGET  DATA  is  dependent upon \n         target flags. \n \n     SRCOFF1 - SRCOFFn = DW[]  Source offset list. \n         This list is present if the  Source List Flag is set \n         in the Target Flags field.  The number of entries in \n         the  source offset list is defined in the SRCOFF\/CNT \n         field.  The  source  offsets  are  relative  to  the \n         beginning of the  page where  the fixups are  to  be \n         made. \n \n               +-----+-----+-----+-----+ \n           00h | SRC |FLAGS|SRCOFF\/CNT*| \n               +-----+-----+-----+-----+-----+-----+ \n       03h\/04h |  OBJECT * |        TRGOFF * @     | \n               +-----+-----+-----+-----+-----+-----+ \n               | SRCOFF1 @ |   . . .   | SRCOFFn @ | \n               +-----+-----+----   ----+-----+-----+ \n \n             * These fields are variable size. \n             @ These fields are optional. \n \n \n         OBJECT = D[B|W]  Target object number. \n             This field is an index into the current module's \n             Object Table to  specify  the target Object.  It \n             is  a  Byte  value  when   the   '16-bit  Object \n             Number\/Module Ordinal  Flag' bit  in  the target \n             flags field is clear and  a Word  value when the \n             bit is set. \n \n \n         TRGOFF = D[W|D]  Target offset. \n             This  field  is  an  offset  into  the specified \n             target  Object.  It  is  not  present  when  the \n             Source Type  specifies a  16-bit Selector fixup. \n             It  is  a  Word value when  the  '32-bit  Target \n             Offset Flag'  bit  in the target flags field  is \n             clear and a Dword value when the bit is set. \n \n               +-----+-----+-----+-----+ \n           00h | SRC |FLAGS|SRCOFF\/CNT*| \n               +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ \n       03h\/04h | MOD ORD# *| PROCEDURE NAME OFFSET*|     ADDITIVE * @      | \n               +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ \n               | SRCOFF1 @ |   . . .   | SRCOFFn @ | \n               +-----+-----+----   ----+-----+-----+ \n \n             * These fields are variable size. \n             @ These fields are optional. \n \n \n         MOD ORD # =  D[B|W]  Ordinal  index into the  Import \n         Module Name Table. \n             This value  is an ordered index in to the Import \n             Module Name Table  for the module containing the \n             procedure entry point.  It is a Byte value  when \n             the '16-bit  Object Number\/Module  Ordinal' Flag \n             bit  in the target flags  field is  clear  and a \n             Word  value  when  the  bit  is set.  The loader \n             creates a table of pointers with each pointer in \n             the  table  corresponds to the  modules named in \n             the  Import  Module Name Table.  This  value  is \n             used  by  the loader  to  index into  this table \n             created by the  loader  to locate the referenced \n             module. \n \n         PROCEDURE NAME  OFFSET  =  D[W|D]  Offset  into  the \n         Import Procedure Name Table. \n             This   field   is  an  offset  into  the  Import \n             Procedure Name Table.  It  is a Word  value when \n             the  '32-bit  Target Offset  Flag'  bit  in  the \n             target flags field  is clear and  a Dword  value \n             when the bit is set. \n \n         ADDITIVE = D[W|D]  Additive fixup value. \n             This field exists in the fixup  record only when \n             the 'Additive  Fixup  Flag'  bit  in  the target \n             flags field is set.  When  the  'Additive  Fixup \n             Flag' is clear the fixup record does not contain \n             this  field  and is immediately followed by  the \n             next fixup record (or  by the source offset list \n             for this fixup record). \n \n             This value is added to the address  derived from \n             the  target entry point.  This field  is  a Word \n             value when the '32-bit Additive Flag' bit in the \n             target flags field is  clear  and a  Dword value \n             when the bit is set. \n \n               +-----+-----+-----+-----+ \n           00h | SRC |FLAGS|SRCOFF\/CNT*| \n               +-----+-----+-----+-----+-----+-----+-----+-----+ \n       03h\/04h | MOD ORD# *|IMPORT ORD*|     ADDITIVE * @      | \n               +-----+-----+-----+-----+-----+-----+-----+-----+ \n               | SRCOFF1 @ |   . . .   | SRCOFFn @ | \n               +-----+-----+----   ----+-----+-----+ \n \n             * These fields are variable size. \n             @ These fields are optional. \n \n \n         MOD ORD  # = D[B|W]  Ordinal index  into  the Import \n         Module Name Table. \n             This value is an ordered index  in to the Import \n             Module  Name Table for the module containing the \n             procedure  entry point.  It is a Byte value when \n             the '16-bit Object Number\/Module  Ordinal'  Flag \n             bit in the target flags  field is  clear  and  a \n             Word  value  when  the  bit  is set.  The loader \n             creates a table of pointers with each pointer in \n             the table  corresponds  to the  modules named in \n             the  Import Module  Name Table.  This  value  is \n             used by the loader  to  index  into  this  table \n             created  by the loader to locate the  referenced \n             module. \n \n         IMPORT ORD = D[B|W|D]  Imported ordinal number. \n             This is the imported procedure's ordinal number. \n             It is a Byte value when  the '8-bit Ordinal' bit \n             in the target flags  field is set.  Otherwise it \n             is  a Word value when the '32-bit Target  Offset \n             Flag' bit in the target flags field is clear and \n             a Dword value when the bit is set. \n \n         ADDITIVE = D[W|D]  Additive fixup value. \n             This field exists in the fixup  record only when \n             the  'Additive Fixup Flag'  bit  in  the  target \n             flags field is set.  When  the  'Additive  Fixup \n             Flag' is clear the fixup record does not contain \n             this field  and  is  immediately followed by the \n             next fixup record (or  by the source offset list \n             for this fixup record). \n \n             This value is  added to the address derived from \n             the  target entry point.  This field is  a  Word \n             value when the '32-bit Additive Flag' bit in the \n             target flags field  is  clear and a Dword  value \n             when the bit is set. \n \n               +-----+-----+-----+-----+ \n           00h | SRC |FLAGS|SRCOFF\/CNT*| \n               +-----+-----+-----+-----+-----+-----+ \n       03h\/04h |  ORD # *  |     ADDITIVE * @      | \n               +-----+-----+-----+-----+-----+-----+ \n               | SRCOFF1 @ |   . . .   | SRCOFFn @ | \n               +-----+-----+----   ----+-----+-----+ \n \n             * These fields are variable size. \n             @ These fields are optional. \n \n         ENTRY #  =  D[B|W]  Ordinal  index  into  the  Entry \n         Table. \n             This field is an index into the current module's \n             Entry  Table  to  specify the target Object  and \n             offset.  It  is a Byte  value when  the  '16-bit \n             Object Number\/Module  Ordinal' Flag bit  in  the \n             target flags field is  clear  and  a  Word value \n             when the bit is set. \n \n         ADDITIVE = D[W|D]  Additive fixup value. \n             This field exists in the  fixup record only when \n             the  'Additive Fixup  Flag'  bit  in the  target \n             flags  field is set.  When the  'Additive  Fixup \n             Flag' is clear the fixup record does not contain \n             this  field and is  immediately followed  by the \n             next fixup record (or by the source  offset list \n             for this fixup record). \n \n             This value  is added to the address derived from \n             the  target  entry point.  This field is a  Word \n             value when the '32-bit Additive Flag' bit in the \n             target  flags  field  is clear and a Dword value \n             when the bit is set. \n \n \n \n \n \n  Import Module Name Table \n \n \n The import module name table defines the module name strings \n imported through dynamic link references.  These strings are \n referenced through the imported relocation fixups. \n \n To determine the  length  of the  import  module  name table \n subtract the import module name table offset from the import \n procedure  name  table offset.  These values are located  in \n the  linear EXE header.  The end  of the import module  name \n table  is  not  terminated by  a special  character,  it  is \n followed directly by the import procedure name table. \n \n The strings are CASE SENSITIVE and NOT NULL TERMINATED. \n \n Each name table entry has the following format: \n \n           +-----+-----+-----+-----+     +-----+ \n       00h | LEN |    ASCII STRING  . . .      | \n           +-----+-----+-----+-----+     +-----+ \n \n     LEN = DB  String Length. \n         This defines the length of the string in bytes.  The \n         length of each ascii name string is  limited  to 127 \n         characters. \n \n     ASCII STRING = DB  ASCII String. \n         This is a  variable  length string with it's  length \n         defined in bytes by the  LEN  field.  The  string is \n         case sensitive and is not null terminated. \n \n \n \n \n \n     Import Procedure Name Table \n \n \n The import procedure name table defines  the  procedure name \n strings  imported  by  this  module   through  dynamic  link \n references.   These   strings  are  referenced  through  the \n imported relocation fixups. \n \n To determine the length  of the import procedure  name table \n add the fixup section size  to the  fixup page table offset, \n this computes the  offset to  the end of the  fixup section, \n then subtract the import procedure name table offset.  These \n values are located  in  the linear  EXE header.  The  import \n procedure name table is followed by the data pages  section. \n Since the  data pages  section is aligned  on a 'page  size' \n boundary, padded space  may  exist  between the  last import \n name  string  and the first page in  the data pages section. \n If this padded space exists it will be zero filled. \n \n The strings are CASE SENSITIVE and NOT NULL TERMINATED. \n \n Each name table entry has the following format: \n \n           +-----+-----+-----+-----+     +-----+ \n       00h | LEN |    ASCII STRING  . . .      | \n           +-----+-----+-----+-----+     +-----+ \n \n     LEN = DB  String Length. \n         This defines the length of the string in bytes.  The \n         length of each ascii  name  string is limited to 127 \n         characters. \n \n         The high bit  in the LEN field (bit 7) is defined as \n         an Overload bit.  This bit signifies that additional \n         information  is  contained in the  linear EXE module \n         and will  be  used in the future for  parameter type \n         checking. \n \n     ASCII STRING = DB  ASCII String. \n         This is  a variable  length string  with it's length \n         defined in bytes by the LEN  field.  The  string  is \n         case sensitive and is not null terminated. \n \n \n \n \n \n     Preload Pages \n \n \n The  Preload Pages section  is an  optional section  in  the \n linear EXE module that coalesces a 'preload page set' into a \n contiguous section.  The  preload page set can be defined as \n the set of first used pages in the module.  The preload page \n set can be specified by the application developer or can  be \n derived by a  tool that  analyzes the programs memory  usage \n while  it  is  running.  By grouping the  preload  page  set \n together, the preload pages can be read  from the linear EXE \n module with one disk read. \n \n The structure of  the preload pages is no different than  if \n they  were  demand  loaded.  They  are  non-iterated  pages. \n Their sizes are determined  by the Object Page Table entries \n that  correspond.  If  the  specified size is less than  the \n PAGE SIZE field given in the linear  EXE  module  header the \n remainder of the page is filled with zeros when loaded. \n \n All pages  begin on a  PAGE  OFFSET  SHIFT boundary from the \n base of the preload page section, as specified in the linear \n EXE  header.  The  pages are ordered by logical  page number \n within this section. \n \nNote: OS\/2 2.0 does not respect preload pages. Performance tests \nshowed that better system performance was obtained by not \nrespecting the preload request in the executable file. \n \n \n \n \n     Demand Load Pages \n \n \n The   Demand   Loaded   Pages  section   contains   all  the \n non-iterated  pages  for a linear  EXE  module that are  not \n preloaded.  When  required,  the whole  page is loaded  into \n memory  from  the module.  The characteristics  of  each  of \n these pages is specified  in the  Object Page  Table.  Every \n page begins on a PAGE OFFSET SHIFT  boundary  aligned offset \n from the demand  loaded pages base specified  in the  linear \n EXE header.  Their  sizes are determined by the  Object Page \n Table  entries that correspond.  If  the  specified size  is \n less than the PAGE SIZE field given in the linear EXE module \n header the  remainder  of the page is filled with zeros when \n loaded.  The pages are ordered by logical page number within \n this section. \n \n \n \n \n     Iterated Data Pages \n \n \n The Iterated Data Pages section contains all the pages for a \n linear EXE module that are iterated.  When required, the set \n of iteration records are loaded into  memory from the module \n and  expanded  to  reconstitute  the  page.  Every   set  of \n iteration records begins on  a PAGE OFFSET SHIFT offset from \n the  OBJECT ITER  PAGES  OFF  specified  in  the linear  EXE \n header.  Their sizes are determined by the Object Page Table \n entries  that correspond.  The  pages are ordered by logical \n page number within this section. \n \n This  record structure is used to describe the iterated data \n for an object on a per-page basis. \n \n           +-----+-----+-----+-----+ \n       00h |#ITERATIONS|DATA LENGTH| \n           +-----+-----+-----+-----+-----+ \n       04h |DATA BYTES |   . . .   | ... | \n           +-----+-----+-----+-----+-----+ \n \n Figure 19. Object Iterated Data Record (Iteration Record) \n \n     #ITERATIONS = DW  Number of iterations. \n         This specifies the number of  times that the data is \n         replicated. \n \n     DATA LENGTH = DW  The size of the data pattern in bytes. \n         This specifies the number of bytes of  data of which \n         the pattern consists.  The maximum size is  one half \n         of the PAGE SIZE (given in the module header).  If a \n         pattern exceeds  this value then the data page  will \n         not be condensed into iterated data. \n \n     DATA  =  DB  *  DATA  LENGTH  The  Data  pattern  to  be \n     replicated. \n         The next iteration record  will  immediately  follow \n         the  last  byte of the  pattern.  The  offset of the \n         next iteration record is easily calculated from  the \n         offset  of  this record  by adding  the  DATA LENGTH \n         field  and  the sizes  of the  #ITERATIONS  and DATA \n         LENGTH fields. \n \n \n \n \n \n     Debug Information \n \n \n The debug information  is  defined by  the debugger  and  is \n not controlled by the linear EXE format or linker.  The only \n data defined by the linear EXE format relative  to the debug \n information is  it's offset  in  the  EXE file and length in \n bytes as defined in the linear EXE header. \n \n To  support multiple debuggers the first word of  the  debug \n information is  a type  field which determines the format of \n the debug information. \n \n           00h   01h   02h   03h   04h \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n           | 'N' | 'B' | '0' |  n  |   DEBUGGER DATA  . . . . \n           +-----+-----+-----+-----+-----+-----+-----+-----+ \n \n \n     TYPE = DB DUP 4 Format type. \n         This defines  the type of debugger data  that exists \n         in  the  remainder of  the  debug  information.  The \n         signature consists  of  a  string  of four (4) ASCII \n         characters:   \"NB0\"    followed    by   the    ASCII \n         representation  for 'n'.  The  values  for  'n'  are \n         defined as follows. \n \n         These format types are defined. \n \n             00h = 32-bit CodeView debugger format. \n             01h = AIX debugger format. \n             02h = 16-bit CodeView debugger format. \n             04h = 32-bit OS\/2 PM debugger (IBM) format. \n \n     DEBUGGER DATA = Debugger specific data. \n         The  format  of the debugger data  is defined by the \n         debugger that is being used. \n \n         The  values  defined  for  the  type  field are  not \n         enforced by the  system.  It is  the  responsibility \n         of  the  linker  or  debugging tools to  follow  the \n         convention for the type field that is defined here. <\/pre>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"
LX – Linear eXecutable Module Format Description June 3, 1992 Figure 1. 32-bit Linear EXE File Layout 00h +——————+ <–+ | DOS 2 Compatible | | | EXE Header | | 1Ch +——————+ | | unused | | +——————+ | 24h | OEM Identifier | | 26h | OEM Info | | | | |–…<\/p>\n
Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"page-templates\/full-width.php","meta":{"footnotes":""},"categories":[],"tags":[],"wf_page_folders":[],"class_list":["post-1148","page","type-page","status-publish","hentry"],"jetpack_sharing_enabled":true,"jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/www.ecsdump.net\/index.php?rest_route=\/wp\/v2\/pages\/1148","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ecsdump.net\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.ecsdump.net\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.ecsdump.net\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ecsdump.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1148"}],"version-history":[{"count":2,"href":"https:\/\/www.ecsdump.net\/index.php?rest_route=\/wp\/v2\/pages\/1148\/revisions"}],"predecessor-version":[{"id":1150,"href":"https:\/\/www.ecsdump.net\/index.php?rest_route=\/wp\/v2\/pages\/1148\/revisions\/1150"}],"wp:attachment":[{"href":"https:\/\/www.ecsdump.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1148"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ecsdump.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1148"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ecsdump.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1148"},{"taxonomy":"wf_page_folders","embeddable":true,"href":"https:\/\/www.ecsdump.net\/index.php?rest_route=%2Fwp%2Fv2%2Fwf_page_folders&post=1148"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}