Why cannot edit.com (16 bit) on Windows XP or in Virtual PC on Windows 7 exit successfully by clicking the close button?

Question

Why cannot edit.com (16 bit, aka MS-DOS Editor) be terminated successfully by clicking the close button on Windows XP or in Virtual PC on Windows 7, but can be terminated successfully by clicking File → Exit?

Screenshot (not in English :-)):

The same error in English:

Answer 1

Why can edit.com be terminated successfully by clicking File → Exit, but not by clicking the close button ☒? Why does the close button cause a prompt to kill it?

TL;DR

Because Edit is a DOS program, so File → Exit has nothing to do with Windows or the ☒ button.

Subsystems

Windows has two primary subsystems (“frameworks” if you will) that a program can use to simplify things and avoid the programmer having to do everything manually and re-inventing the wheel. There is the standard Windows subsystem, and there is the console subsystem.

Windows programs are GUI (graphical user interface) programs, while console programs are CLI (command-line interface) programs. These are very different designs and what works for one does not work for the other.

Windows subsystem

The windows subsystem is the more common one, and programs that have graphical windows and controls will use that. The “heart” of the program is a Windows message loop. After the program has initialized and gotten ready to run, it will enter an infinite loop where it sits idle, patiently waiting for something to happen. This can include input from the user, a timer going off, network activity, etc. When Windows detects some change that the program must or may want to respond to, it will send that program a messages. At that point, if the message is about something that the program has an interest in, it will respond to it with a handler, which is just a function that does something.

(This is also how most games work. They will have a main game-loop which waits for input from gamepad buttons, timers, etc., then it updates the game world, renders a frame, outputs it to the screen, and starts over.)

Hung programs

Normally, when a program gets a message, it will either handle it or pass it on. This usually happens fast. Sometimes however, a program may hang for some reason, which will cause it to not process messages. Windows can detect when this happens, and if it takes too long, it will consider the program to be frozen and offer to let the user kill the unresponsive program instead of letting it shut down gracefully. This means that it will end abruptly and not only lose unsaved files, but potentially leave open files in an inconsistent state, thus corrupting them.

Console subsystem

Console programs are different from graphical Windows programs. They have evolved from their DOS ancestors, and while they have gained a lot of new functionality from the Windows command-prompt, underneath it all, they function a lot like old DOS programs, including how they start up, run, and shut down.

Closing a program

Let’s examine what happens when you click the ☒ button for both kinds of programs.

Closing a Windows program

When you click the ☒ button of a Windows program, Windows sends that program a WM_CLOSE message. The program’s loop detects the message and responds by calling a function that does goes through the standard routine of ending a Windows program (hopefully after first doing some clean up work like releasing allocated resources, saving files, and so on). Aside from any cleanup work, the actual shutdown routing happens pretty quickly, and Windows moves on to the next task.

Closing a console program

When you click the ☒ button of the command-prompt, you are telling the command-prompt to close. When it gets that message, it tries to close, and if you are sitting idly at the prompt, it can certainly do so without much hesitation. But what happens if you have some program open and running in the command-prompt? That program is a separate process altogether. The command-prompt can’t just kill that program, that would not be user-friendly and could corrupt data or lose unsaved files. Instead, it tries to pass the close message to the program. There are two scenarios that can play out at this point:

• If the program is a Windows console program, then sending it the close message will usually work immediately because it was compiled with the Windows console subsystem, and while you may lose some unsaved files, because it is using Windows-specific console code, there is no delay, and thus Windows doesn’t need to resort to killing it.

• If the program is a DOS program (like Edit) however, then it was compiled to run on DOS, and thus knows nothing about Windows and so does not respond, so Windows thinks it’s hung and offers to kill the program.

File → Exit

With a Windows program, the exit command (usually File → Exit) is just an alias for WM_CLOSE. When you exit the program, it gets the close message just as if you had clicked the close button.

With Edit, the exit command (also File → Exit) has nothing to do with Windows. It is a built-in function of that DOS program itself. So when you click the close button, it is a completely different thing than exiting from within Edit, so clicking ☒ does not tell the program the close.

Different results

But why is Kevin getting a different result from others (and myself)? This is likely due to a difference in the timeout period that Windows is configured to use for its routines that detect when a program is frozen. There are actually several different settings that affect this. Changing the setting(s) would cause Windows to wait for more or less time before showing the dialog.

^{I was going to list them all, but while looking them up, I ended up finding a post that I had made a while back that already listed them all, so if anyone’s interested in the details, you can find them there.}