.EXE File Format – The DOS and NE headers

The DOS header

The first 64 bytes are an MS-DOS header with the extended fields of Windows and OS/2 programs. DOS reads the first 28 bytes to run the stub; e_lfanew at the end leads to the NE header.

The fields are those of an MS-DOS header, but here they describe only the stub. Linkers often give the stub’s size as most of the file: in TEST1.EXE, below, e_cp and e_cblp come to 14,080 bytes of a 14,336-byte file. The explorer ends the stub where the NE header begins.

e_lfanew

The 32-bit word at 0x3C is the file offset of the NE header, which comes after the stub: 0x100 in TEST1.EXE, 0x400 in WINMINE.EXE. If the two bytes there are not NE, or the header’s tables do not fit in the file, the file is not taken as NE; see Telling it apart.

The DOS stub

The stub is the MS-DOS program after the DOS header. It usually prints “This program requires Microsoft Windows.” or “This program must be run under Microsoft Windows.” and exits with code 1. Stubs differ from linker to linker; this is TEST1.EXE’s:

BA 10 00     mov dx, 0x0010        ; the message, 16 bytes in
0E           push cs
1F           pop ds
B4 09        mov ah, 9             ; DOS: print a string ending in $
CD 21        int 21h
B8 01 4C     mov ax, 0x4C01        ; DOS: exit with code 1
CD 21        int 21h

The explorer shows the stub as a DOS program, with its message, and disassembles it in the Code section. It names the bytes between the end of the DOS header’s fields and the end of the header “Rest of the DOS header”, and any bytes between the end of the stub, as its header gives its size, and the NE header “After the DOS stub”. Some stubs run on past their stated size, so their message ends there. If e_crlc is not 0, the stub’s relocation table is shown too.

The NE header

The NE header is 64 bytes:

Signature

ne_magic is 4E 45, NE in ASCII.

Linker version

ne_ver and ne_rev are the major and minor version of the linker that wrote the file, as two bytes: 06 01 is 6.1. Values from 5.1 to 5.60 are the most common in the files examined for this site, with 6.1 and 7.1 as well; some files carry odd values such as 10.0 or 17.32, whose meaning is not known.

Table offsets

Six words give the offsets of the tables from the start of the NE header, and one double word gives the non-resident name table’s offset from the start of the file:

The tables normally follow the header in the order of this table. The explorer reads them wherever the offsets say, and notes on the header when they are in another order.

Checksum

ne_crc is a 32-bit checksum of the file. Many files have 0 here (fileformat.info says Borland’s Turbo Pascal for Windows leaves it 0). How the value is computed is not described here; the explorer shows it without checking it.

Module flags

ne_flags describes the module. The bits are those given by fileformat.info; Wine names bits 0, 1 and 15 the same way.

Automatic data segment

ne_autodata is the number, from 1, of the automatic data segment: the segment that holds the module’s static data, its local heap and, in a program, its stack. 0 means there is none.

Heap and stack

ne_heap and ne_stack are the initial sizes, in bytes, of the local heap and of the stack. Both are added to the automatic data segment when it is loaded. A library does not use ne_sssp: it runs on the stack of the program that calls it.

Entry point and stack

ne_csip gives where the module starts: the segment number, from 1, in the high word, and the offset in the low word. In a library it is the initialisation routine, or 0 when there is none. ne_sssp gives the initial stack in the same way; a segment number of 0 means the automatic data segment. Both refer to segment numbers, not addresses, since Windows chooses where each segment goes.

Counts

• ne_cseg: the entries in the segment table, resource segments included in OS/2 files;
• ne_cmod: the entries in the module reference table;
• ne_cbnrestab: the size in bytes of the non-resident name table;
• ne_cmovent: the number of entries in movable segments in the entry table.

Alignment shift

ne_align sets the unit, a power of two, in which the segment table gives where each segment’s data starts: a segment at sector n is at file offset n × 2^ne_align. 0 means 9, 512-byte units. WINMINE.EXE uses 4 (16 bytes) and TEST1.EXE 8 (256 bytes). A shift above 24 cannot be right, and the explorer does not take such a file as NE. The resource table has its own shift.

Resource segments

ne_cres is the number of resource segments. OS/2 1.x keeps each resource as a segment, the last ne_cres of the segment table; Windows files have 0 here and a resource table instead. See The resource table.

Target system

Files with 1, 2, 5 and 0 were among those examined for this site; most are Windows files.

Other flags

Fast-load area and thunks

The words at 0x38 and 0x3A mean different things to the two systems. In OS/2 files they are the offsets of the return thunks and of the segment reference thunks. In Windows files they give the fast-load (gangload) area: a run of the file that holds the segments and resources Windows loads at start, so that it can read them in one go. The first word is where the area starts and the second its length, both in sectors of 2^ne_align bytes. Bit 3 of ne_flagsothers says the area is there.

In WINMINE.EXE, Microsoft’s “Minesweeper v3.1”, the flag is set, the shift is 4, and the two words are 0x0060 and 0x037C: the area runs from 0x600 for 0x37C0 bytes, to 0x3DC0, and holds both of its segments. Its first resource starts at 0x3DC0.

Code swap area

ne_swaparea is the minimum size of the code swap area. It is 0 in both examples on this page.

Expected Windows version

ne_expver is the Windows version the program was built for, the major version in the high byte and the minor in the low one: stored 0A 03, it is 0x030A, Windows 3.10; 00 03 is 3.00.

Data after the module

Bytes after the last segment and resource are not loaded. Debuggers, installers and self-extracting archives keep data here. The explorer shows them as “Data after the module”, and names what they hold when it recognises the signature, in the same way as for an MS-DOS program’s overlay: a ZIP or CAB archive, CodeView or Turbo Debugger information, and so on. A run of zero bytes is reported as such.

Worked example

TEST1.EXE, a small Windows 3.0 program of 14,336 bytes. Its DOS header gives e_lfanew 0x100:

00000000  4D 5A 00 01 1C 00 00 00 08 00 00 00 FF FF 08 00  MZ..............
00000010  00 01 00 00 00 00 00 00 40 00 00 00 00 00 00 00  ........@.......
00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00  ................
…
00000080  BA 10 00 0E 1F B4 09 CD 21 B8 01 4C CD 21 90 90  ........!..L.!..
00000090  54 68 69 73 20 70 72 6F 67 72 61 6D 20 72 65 71  This program req
000000A0  75 69 72 65 73 20 4D 69 63 72 6F 73 6F 66 74 20  uires Microsoft 
000000B0  57 69 6E 64 6F 77 73 2E 0D 0A 24 20 20 20 20 20  Windows...$     

00000100  4E 45 06 01 9F 00 11 01 00 00 00 00 02 03 04 00  NE..............
00000110  00 20 00 20 5D 03 01 00 00 00 04 00 04 00 06 00  . . ]...........
00000120  05 00 40 00 60 00 64 00 6D 00 79 00 B0 02 00 00  ..@.`.d.m.y.....
00000130  2D 00 08 00 00 00 02 00 00 00 00 00 00 00 00 03  -...............