DOS MZ格式EXE文件介绍

mz exe format
intel byte order

information from file format list 2.0 by max maischein.
the old exe files are the exe files executed directly by ms-dos. they were a major improvement over the old 64k com files, since exe files can span multiple segments. an exe file consists of three different parts, the header, the relocation table and the binary code.
the header is expanded by a lot of programs to store their copyright information in the executable, some extensions are documented below.
the format of the header is as follows :

offset count type description
0000h 2 char id='mz' id='zm'
0002h 1 word number of bytes in last 512-byte page of executable
0004h 1 word total number of 512-byte pages in executable (including the last page)
0006h 1 word number of relocation entries
0008h 1 word header size in paragraphs
000ah 1 word minimum paragraphs of memory allocated in addition to the code size
000ch 1 word maximum number of paragraphs allocated in addition to the code size
000eh 1 word initial ss relative to start of executable
0010h 1 word initial sp
0012h 1 word checksum (or 0) of executable
0014h 1 dword cs:ip relative to start of executable (entry point)
0018h 1 word offset of relocation table; 40h for new-(ne,le,lx,w3,pe etc.) executable
001ah 1 word overlay number (0h = main program)

following are the header expansions by some other prorams like tlink, lzexe and other linkers, encryptors and compressors; all offsets are relative to the start of the whole header :

---new executable
offset count type description
001ch 4 byte ????
0020h 1 word behaviour bits ??
0022h 26 byte reserved (0)
003ch 1 dword offset of new executable header from start of file (or 0 if plain mz executable)

---borland tlink
offset count type description
001ch 2 byte ?? (apparently always 01h 00h)
001eh 1 byte id=0fbh
001fh 1 byte tlink version, major in high nybble
0020h 2 byte ??
---old arj self-extracting archive
offset count type description
001ch 4 char id='rjsx' (older versions)
new signature is 'arjsf'" in the first 1000 bytes of the file)
---lzexe compressed executable
offset count type description
001ch 2 char id='lz'
001eh 2 char version number : '09' - lzexe 0.90 '91' - lzexe 0.91
---pklite compressed executable
offset count type description
001ch 1 byte minor version number
001dh 1 byte bit mapped : 0-3 - major version 4 - extra compression 5 - multi-segment file
001eh 6 char id='pklite'
---lharc 1.x self-extracting archive
offset count type description
001ch 4 byte unused???
0020h 3 byte jump to start of extraction code
0023h 2 byte ???
0025h 12 char id='lharc's sfx '
--lha 2.x self-extracting archive
offset count type description
001ch 8 byte ???
0024h 10 char id='lha's sfx ' for version 2.10 id='lha's sfx ' (v2.13) for version 2.13
---lh self-extracting archive
offset count type description
001ch 8 byte ???
0024h 8 byte id='lh's sfx '
---topspeed c 3.0 crunch compressed file
offset count type description
001ch 1 dword id=018a0001h
0020h 1 word id=1565h
---pkarc 3.5 self-extracting archive
offset count type description
001ch 1 dword id=00020001h
0020h 1 word id=0700h
---bsa (soviet archiver) self-extracting archive
offset count type description
001ch 1 word id=000fh
001eh 1 byte id=a7h
---larc self-extracting archive
offset count type description
001ch 4 byte ???
0020h 11 byte id='sfx by larc '

after the header, there follow the relocation items, which are used to span multpile segments. the relocation items have the following format :

offset count type description
0000h 1 word offset within segment
0002h 1 word segment of relocation

to get the position of the relocation within the file, you have to compute the physical adress from the segment:offset pair, which is done by multiplying the segment by 16 and adding the offset and then adding the offset of the binary start. note that the raw binary code starts on a paragraph boundary within the executable file. all segments are relative to the start of the executable in memory, and this value must be added to every segment if relocation is done manually.