View source for MS-DOS EXE

==== Extended Header ====
DOS executables don't always contain these additional fields, but Windows and OS/2 executables always do:

{| class="wikitable"
! Offset !! Type !! Name !! Description and remarks
|-
|28 || byte[8] || e_res || Reserved bytes
|-
|36 || uint16 || e_oemid || OEM identifier (rarely used)
|-
|38 || uint16 || e_oeminfo || OEM information (rarely used, meaning depends on OEM identifier)
|-
|40 || byte[20] || e_res2 || Reserved bytes
|-
|60 || uint32 || e_lfanew || File offset of new format executable header (NE, LE, LX or PE) 
|}

The extended header only exists if <code>e_lfarlc</code> is greater than 28 (0x1C); some MZ executables have the relocation table starting at offset 28 and the extended header is absent. Note however that some tools which handle newer executable formats (NE/LE/LX/PE/etc) ignore <code>e_lfarlc</code> and always test the validity of the <code>e_lfanew</code> offset. In particular, although NT-based Windows requires all executables and DLLs to start with an MZ header, it only actually checks the signature and the <code>e_lfanew</code> field, and the rest can all be zeroed. Such an executable obviously will not work under DOS.

There is some conflicting information on the purpose of the start of the <code>eres</code> field, offset 28 or 0x1C:
* [https://wiki.osdev.org/MZ OSDev Wiki] claims this is "Overlay information" and that "Files sometimes contain extra information for the main's program overlay management"
* The file [https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/DOSSYM.ASM#L585 DOSSYM.ASM] in the open sourced MS-DOS 2.0 source code claims this is a 4 byte field called "exe_sym_tab" with comment "offset of symbol table in file". It also contains a [https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/DOSSYM.ASM#L591 symbol_entry] structure definition which is likely the contents of the table. The same definitions occur in the open source MS-DOS 4.0 source code, moved to a different file ([https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/INC/EXE.INC#L67 EXE.INC]). However, this field is not used anywhere in the open source DOS source code; it is unknown whether any Microsoft tools stored a symbol table offset in this field or if any executables survive with one set. Later DOS era Microsoft tooling stored the symbol table in a "CodeView trailer" at end of the executable, so if this mechanism was ever used at all, it is likely to have only been in the early-to-mid 1980s.  
* [https://www.ctyme.com/intr/rb-2939.htm#Table1594 Ralf Brown Interrupt List Table 1594] reports various uses for this field, including signatures for EXE packers. Under New Executable format, it mentions a 16-bit field "behavior bits" at offset 0x20 but there is limited information available on what that means (possibly used by multitasking MS-DOS 4.0; speculatively, may have stored some of the information that later ended up in PIF files, until MS worked out there was too much config required to just add it to the EXE). It also reports that Borland TLINK puts the bytes 0x01 0x00 in the field at offset 0x1C; however, some executables shipped with MS-DOS have those bytes there as well, suggesting that whatever that means, it might not be unique to Borland, since that implies Microsoft tooling sometimes generates those bytes as well.