Commenter Otul Osan wondered what was happening when the user held the Shift key when restarting Windows. Windows displays the message “Windows is restarting” rather than doing a full cold restart of the system.

The behavior you’re seeing is the result of passing the EW_RESTART­WINDOWS flag to the old 16-bit Exit­Windows function.

What happens is that the 16-bit Windows kernel shuts down, and then the 32-bit virtual memory manager shuts down, and the CPU is put back into real mode, and control returns to win.com with a special signal that means “Can you start protected mode Windows again for me?”

The code in win.com prints the “Please wait while Windows restarts…” message, and then tries to get the system back into the same state that it was in back when win.com had been freshly-launched.

One of the things it has to do is to reset any command line options that had been passed to win.com. This is largely clerical work, but it is rather cumbersome because win.com was written in assembly language. And some global variables need to be reset back to the original values.

You might recall that .com files are implicitly given all of the remaining available convention memory when they launch. Programs can release that memory back to the system if they want to make it available to other programs. In win.com‘s case, it releases all the memory beyond its own image back to the system so that there is a single large contiguous block of memory for loading protected-mode Windows.

If somebody had allocated memory in the space that win.com had given up for protected-mode Windows, then convention memory will be fragmented, and the “try to get the system back into the same state that it was in back when win.com had been freshly-launched” is not successful because the expected memory layout was “one giant contiguous block of memory”. In that case, win.com says, “Sorry, I can’t do what you asked” and falls back to a full reboot.

Otherwise, everything looks good, and win.com jumps back to the code that starts protected-mode Windows, and that re-creates the virtual machine manager, and then the graphical user interface launches, and the user sees that Windows has restarted.

Bonus chatter: A common trick in assembly language back in this era when you counted every byte was to take the memory that holds functions that will no longer be called and reuse them as uninitialized data. It’s free memory!

In the case of win.com, the original code reused the first bytes of the entry point as a global variable since the entry point executes only once. Once you get past the entry point, it’s dead code, so you can put a global variable there! Fortunately, the “fast-restart” case doesn’t jump all the way back to the entry point, so the fact that those instructions were corrupted is not significant.

Bonus bonus chatter: Otul Osan also noted that the fast-restart wasn’t perfect: If you try two fast-restarts in a row, the second one crashes. I wasn’t able to reproduce this. I was able to fast-restart four times in a row without incident. My guess is that some device driver did not reset itself properly, so when the system restarted, the second instance of the driver saw a slightly weird device, and the weirdness finally caught up to it at shutdown. (Maybe it corrupted some memory that didn’t cause problems until shutdown.)