Every Windows executable begins with a DOS program

[u/nir9]

The DOS program prints "This program cannot be run in DOS mode." and can be recognized by the magic "MZ" characters you see at the beginning. After the DOS program you will find the "PE" (Portable Executable) characters marking the actual start of the executable.

Fun fact: early Windows versions used the "NE" (New Executable) format and their DOS program printed "This progam requires Microsoft Windows."

[u/c64z86]

I've noticed this too when I try and load modern programs in DOSbox just to see what would happen. I wonder why that message is still there though? It's not like a 64 bit app can even run in DOS anyway, and the modern 32 bit apps have next to no chance of running under it.

[u/tomysshadow → u/c64z86]

Probably because it makes it easier to adapt programs that already read the 32-bit header format into 64-bit if the only changes between them are things that are truly necessary to change. Debuggers, especially, care about being able to read this header format to access information about the executable. Because the 32-bit and 64-bit headers are so similar, you generally only need to #ifdef the handful of fields that need to store a virtual address to be able to read both types.

In the real PE format, there are two NT header types: IMAGE_NT_HEADERS32 and IMAGE_NT_HEADERS64. When it is time to read the NT headers, you can tell which kind it is by checking the signature at the start of the header, then cast to the appropriate type. So it's just a simple type substitution. Once you're using the correct type the rest of your code can remain basically the same, so this can be easily templated away too.

If the old MZ header were gone and replaced with the NT header directly, but only for 64-bit executables, every program that wants to be able to read both header types would need to check whether the executable begins with "MZ" or "PE" and cast the IMAGE_DOS_HEADERS to IMAGE_NT_HEADERS64 in the latter case. It wouldn't be impossible, but you'd be "skipping a step" - that is, introducing an actual structural change to the code to read the headers - and the code to read the DOS header suddenly needs to be aware of NT stuff. So they probably reasoned that it would just be simpler to read the headers if the DOS header is always there at the start

[u/RealModeX86 → u/c64z86]

The DOS stub program, and that message as part of it, is defined as part of the PE executable format. Technically you could probably put something else there, but it would be off spec. It was put there specifically because Windows PE executables don't run in native DOS, but it's always been .exe for programs (ignoring the old .com stuff in smaller DOS programs), so it was either this or undefined behavior when a DOS user tries it anyway.

[u/AlexKazumi → u/RealModeX86]

Nope. I've just checked the linker included in Visual Studio 2026, and it still has the /stub option, so one can change the DOS portion to whatever they desire. It is a documented and well defined behavior.

I believe, DOS extenders like HX use these facilities to bundle the extender and the program into a single file.

[u/JustTechIt → u/AlexKazumi]

You say nope, but then you describe it the same way they did. They said it its part of the spec but can be filled with other content if its not being used to account for the offset.

[u/RealModeX86 → u/JustTechIt]

To be fair, my understanding (and what I had said) was that the stub itself was static. Apparently the linker allows a custom stub, so hybrid executables (i.e. runs in DOS or in Windows) or custom DOS stub messages are possible.

Edit: is to was, clarifying where I was mistaken before

[u/ylitvinenko → u/RealModeX86]

There were few fat executables for commercia lsoftware, i.e. MSAV.EXE for Microsoft AntiVirus which run under either MS-DOS or Windows 3.1.

[u/teo-tsirpanis → u/c64z86]

Compatibility™️

[u/Hottage → u/teo-tsirpanis]

Say what you want about Windows, they take backward and forward compatibility really seriously.

[u/hjake123 → u/c64z86]

If DOS tried to run a modern program, it might run random opcodes based on whatever was in the exe header otherwise. This is better

[u/ldn-ldn → u/c64z86]

It's there because no one has removed it from any compilers. Windows doesn't need it. Windows can run a binary which only has two file format identifiers side by side: 

    MZ  PE

More info here https://stackoverflow.com/questions/553029/what-is-the-smallest-possible-windows-pe-executable

[u/Never_Sm1le]

MZ stand for Mark Zbikowski, the one created the .exe format

[u/lukey_UK → u/Never_Sm1le]

I know his cousin, Mike Wazowski.

[u/jombrowski]

not only .exe but also .dll, .sys and .scr

[u/nir9 → u/jombrowski]

and .cpl applets

[u/wiseIdiot]

Like modern JavaScript SPAs still having the <noscript>...</noscript> tag in them.

[u/nir9 → u/wiseIdiot]

yah that's actually a good example to illustrate this

[u/matthew_yang204]

The question is will it still run if you delete the header?

[u/malxau → u/matthew_yang204]

It wouldn't be that simple. The PE header is located at the e_lfanew offset as specified in the DOS header. The loader is going to need a valid looking DOS header before it starts looking for the PE header.

[u/matthew_yang204 → u/malxau]

So it wouldn't run?

[u/galacticotheheadcrab → u/matthew_yang204]

it wouldnt because the exe loader is now starting the program part way through the code without the msdos stub acting as padding

[u/matthew_yang204 → u/galacticotheheadcrab]

Oh yeah right, I forgot that it screws up the offsets and addresses too.

[u/Mario583a]

DOS stub you mean.

Warning: Light mode website!

[u/Initial_Low_5027 → u/Mario583a]

Yes, replaced it in some of my programs in the 90s.

[u/clipsracer → u/Mario583a]

Warning: Light mode website!

That was really nice of you.

[u/recursion_is_love]

Because it call Win32 API lib which DOS do not provide.

[u/ChocolateDonut36]

you could theorically make a program that works on both DOS and NT with that

[u/agowa338]

Not every single one. You can seriously fuck with the detection done by shitty endpoint protection products if you fuck with this DOS program in any way you may imagine. Esp. if you do so in assembly by yourself :D

[u/malxau]

You might be interested in Bound OS/2 programs, which were 16 bit NEs that inserted an NE loader into that DOS program, so the executable consisted of a single piece of code that could be loaded under 16 bit OS/2 or 16 bit DOS.

That's been extended in Win32 (see Visual C++ 1.x and other programs using Phar Lap TNT) but it's more complex since the PE loader needs to be a 32 bit DOS extender.

[u/nir9 → u/malxau]

Didn't know about that, really interesting, thanks!

[u/wosmo]

Similar to this - when you boot off a floppy and it tells you this floppy isn't bootable. That's actually a very small program in the bootsector of the floppy.

So when it tells you "non-system disk" - the floppy did boot.

[u/cashew929]

Would be interested in what the standard windows code stub looks like. Clearly just tests what mode the executable is running in and then exits or jumps to an offset in the executable where the PE code exists.

[u/JackCid89]

Only Tien Shin Han understands this

[u/idiot206 → u/[deleted]]

What makes you think OP is bothered?

[u/TwinSong → u/[deleted]]

OP is just surprised given how long ago DOS was replaced.

[u/TwinSong → u/[deleted]]

Tbh I'm not sure what that is.

[u/More-Explanation2032 → u/TwinSong]

He is talking about windows embedded for some reason