I have been wondering this question recently. Why does PE images have to be executable in MS-DOS? I've read on the topic and most of the answers I've seen simply explain it with compatibility. But what this compatibility actually means and targets?

If it was intended to allow a single executable both to run on DOS and Windows - what was the problem to include two executables for each OS instead?

Some of the answers I've read explaining it with compatibility states that if ".exe" files were purely formatted in the COFF format with the PE signature this would lead to a crash in the system when executed on DOS. But I was wondering if that's actually true. Wasn't the MS-DOS checking for "MZ" starting signature and if not would it have been so expensive to include such check and also perhaps another to print message similar to the DOS-stub if the image was starting with "PE" (and so it was a PE executable instead)?

  • I'm getting old and my memory is not what it once was but I seem to recall that if one tried to run a Windows application (like Word) in DOS then it would start up Windows and run. Maybe that was the reason - it was a convenience for users who spent most of their time in DOS. – Keith Miller Jan 26 '16 at 14:38
  • 2
    @KeithMiller - there were a handful of Windows apps that did that. Some others included a DOS version of the app that would run under those circumstances. But the vast majority just printed a message that said "This program must be run under Microsoft Windows" and exited. – Jules Jan 26 '16 at 17:50

Yes, MS-DOS included a check for the "MZ" signature.

I believe it (the stub) was originally included because the was a fair amount of time that Windows ran entirely as a "shell" around MS-DOS and early versions of Windows (before 3.0) were nearly unusable for running MS-DOS programs. As such, it was fairly routine for people to have Windows installed, and have Windows programs installed, but not run Windows most of the time--they'd only start up Windows when they ran the (few) particular programs they had that needed it (e.g., Excel).

I think Microsoft expected that to be the case (and were correct), and believed that under such circumstances it was probably more friendly to print out a readable error message than to just die with "not a valid executable", or something on that order.

There was also at least some idea of having actual hybrid executables--i.e., an executable that contained a real MS-DOS program, so if you invoked it from MS-DOS, it would run a DOS program to do what you'd asked, and if you ran it from Windows, it would run a native Windows program. Note that support for this was fairly limited though--the stub program couldn't be very large, so if you'd decided to use it this way in most cases the stub would probably have had to just spawn the program DOS program, rather than the DOS program really being contained in the stub itself.

I don't know of that happening commercially, but I do know of another variant that was sometimes used, and worked fairly well: an MS-DOS stub program that, instead of just printing an error message and exiting, actually executed Windows with itself (i.e., this executable) on the command line, so invoking the program from a DOS command prompt still executed it under Windows.

  • Phar Lap had a product back in the early 90s that was a DOS extender which included a subset of the Windows API (basically only text mode stuff) so you could write a program that would run under either. I also recall using an application circa 91 which when started from DOS would use os own GUI implementation but running from Windows used the standard Windows UI. Alas, I can't remember what it was. Think it was one of the ubiquitous database design applications that used to be all over the place. – Jules Jan 26 '16 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.