MZ: Difference between revisions

343 bytes removed ,  4 months ago
[unchecked revision][unchecked revision]
 
(3 intermediate revisions by 2 users not shown)
Line 1:
{{File formats}}
 
The MS-DOS EXE format, also known as MZ after its signature (the initials of Microsoft engineer Mark ZbykowskiZbikowski), was introduced with MSPC-DOS 21.0 (pre-release version 1.0.90 only sported the simple [[COM]] format; note in DOS 1.x the DOS kernel doesn't support EXEs and the EXE loader is in COMMAND.COM; in DOS 2.x and later it was moved into the DOS kernel). It is designed as a relocatable executable running under real mode. As such, only DOS and Windows 9x/Me can use this format natively, but there are several free DOS emulators (e.g., [http://www.dosbox.com/ DOSBox]) that support it and that run under various operating systems (e.g., Linux, Amiga, Windows NT, etc.). Although they can exist on their own, MZ executables are embedded in all [[NE]], [[LE]], and [[PE]] executables, usually as stubs so that when they are ran under DOS, they display:
 
This program cannot be run in MS-DOS mode.
Line 154:
 
With the advent of the [[PE]] executable, Microsoft added items to the MZ header, as defined in WinNT.h
 
(Actually, that's incorrect – this extension was originally added in the New Executable format, which was first released as part of Windows 1.0 in 1985, and the multitasking MS-DOS 4.0 in 1986. The "PE header start" is called "e_lfanew" in Microsoft's headers, since it was originally the pointer to the NE header, although later was also used for LE, LX and PE; in principle it can be used for *any* executable format which is defined as an extension of MZ.)
 
{| {{wikitable}}
Line 191 ⟶ 193:
| Starting address of the PE header
|}
 
== MZ in Protected Mode ==
 
Using the ia16-gcc toolchain, it is possible to generate 32-bit code with a compiler or assembler and convert it to an MZ (it will ''not'' run on DOS). The IA16 linker can be invoked with the argument `-m i386msdos` to generate an EXE. Static libraries can be importing by replacing unresolved symbols with those from another file that defines them as ordinals. This can be done by scanning the relocation table for each address in the program and replacing anything that includes a magic bit indicating that this symbol is to be resolved by the loader. Library imports could be defined in a non-standard structure if needed.
 
The assembly file with the ordinals has do make all symbols relative to the location counter ($ in NASM) so that relocations are generated and the ordinal is not just copied into the code.
 
The disadvantage of this approach is that importing can only be done with ordinals and that the program must fit in 1MB.
 
==See Also==
Anonymous user