DOS reads only the image that the header’s
e_cp and
e_cblp describe. Whatever follows it in the file stays on disk, and the
program can open its own file and read it when it wants. Programs keep many things
there: overlay code loaded on demand, debug information, a 32-bit program for a DOS
extender, or the archive a self-extractor unpacks. Together these bytes are called the
overlay. The format says nothing about them; each program has its own layout.
How the explorer reads an overlay
The explorer shows the bytes after the image as one block, named “Overlay”, and tries to say what it holds:
- It compares the first bytes with the signatures of the programs and debug data below, which count only at the very start.
- Otherwise it searches the first 64 KB for the signatures of the archives and installers below. When the signature is not at the start, the bytes before it are shown separately, as “Before the archive”.
- An overlay of zero bytes only is reported as such.
- Anything else is shown as bytes and links to this page. Among those seen in files
examined for this site are short runs of text and runs of the byte
0x1A, the old end-of-file mark.
The explorer does not open what it finds. Save the bytes and drop them on the page of their own format to look inside.
Programs and debug data
These signatures are looked for only at the first byte of the overlay.
| Signature | What it is |
|---|---|
MZ | Another MS-DOS program |
LE, LX | An LE or LX module |
BW | A DOS/16M protected-mode program |
4C 01, with 1C 00 at offset 16 | A COFF image for the i386, as DJGPP writes |
FBOV, or FB 52 | A Borland overlay, or Turbo Debugger information |
NB0x, NB1x | CodeView debug information |
60 EA | An ARJ archive |
Another MZ program
An overlay that starts with MZ is a second MS-DOS program image. Overlay
managers keep the parts of a large program this way, each with its own MZ header and
its number in e_ovno;
other files simply carry a second program after the first. Its header can be read
the same way as the first one, from the overlay’s start.
An LE or LX module
A DOS extender can be built as a small MS-DOS program with a 32-bit
LE or LX
module bound after it. Usually e_lfanew then points at the module, and
the file is shown as LE or LX. When it does not, the file is shown as an MS-DOS
program and the module as its overlay.
DOS/16M (BW)
BW starts a program for Rational Systems’ DOS/16M, a 16-bit
protected-mode DOS extender. Every DOS4GW.EXE examined for this site, the extender
that many Watcom-built games use, is a DOS loader followed by a BW program. Its
text includes “DOS/4G Copyright (C) Rational Systems, Inc. 1987 - 1993” and
“DOS/16M Protected Mode Run-Time”. The layout of the BW program was not
examined.
DJGPP’s COFF image
Programs built with DJGPP, the GNU
compilers for DOS, are a small MS-DOS stub (“The STUB.EXE stub loader is Copyright
(C) 1993-1995 DJ Delorie”) followed by the 32-bit program as a
COFF image, which the stub loads and runs in
32-bit protected mode. The explorer recognises the COFF file header for
the i386, machine 0x014C, with a 28-byte optional header.
00000800 4C 01 03 00 00 00 00 00 00 00 00 00 00 00 00 00 L...............
00000810 1C 00 0F 01 0B 01 00 00 58 61 02 00 00 2A 00 00 ........Xa...*..0x800 with machine 0x014C, 3 sections, a 28-byte (0x1C) optional header and flags 0x010F, then the optional header’s magic 0x010BBorland overlays and Turbo Debugger information
FBOV starts the overlay data of programs built with Borland’s overlay
manager. FB 52 starts Turbo Debugger’s debug information, which Borland’s
linker appends to the program; the bytes after it vary. Both were seen in files
examined for this site. Their layouts are not described here.
CodeView
NB and two digits, such as NB05 or NB09,
start Microsoft’s CodeView debug information. The explorer names the signature it
finds.
Archives and installers
A self-extracting archive is an MS-DOS program that opens its own file, finds the archive after the image and unpacks it. The explorer searches the first 64 KB of the overlay for these signatures, because some self-extractors put a few bytes of their own first.
| Signature | What it is |
|---|---|
50 4B 03 04 (PK, 3, 4) | A ZIP archive: its first local file header. PKSFX and other self-extractors; seen both at the start of the overlay and one byte in. |
4D 53 43 46 00 00 00 00 (MSCF and four zero bytes) | A Microsoft Cabinet. |
52 61 72 21 1A 07 00, or 52 61 72 21 1A 07 01 00 | A RAR archive: versions 1.5 to 4, or version 5. |
37 7A BC AF 27 1C | A 7z archive. |
A 4-byte flags value, then EF BE AD DE and NullsoftInst | The first header of an NSIS installer’s data. |
Inno Setup Setup Data (, or idska32 and 0x1A | Inno Setup installer data. |
A header size, a checksum, then -lh?- or -lz?- | An LHA archive, such as -lh5-; the archive starts at the size byte. |
60 EA, at the start only | An ARJ archive. |
NSIS and Inno Setup make Windows installers, so their data usually follows a PE program rather than an MS-DOS one; the check is the same. A short signature found by the search can be a coincidence in other data, so treat the name as a strong hint rather than proof.