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_ 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.)
This whole “reuse code space for variables” thing is possible only in real mode, right? In my understanding protected mode would make the code area read-only…
This is before the days of the NX bit in x86; it would be entirely possible (in protected mode) to set the page writable and executable at the same time.
Modern OSes enforce so-called writable XOR executable, using the NX bit on x86-64 processors, but Win95 didn't. And this, in turn, made it easier to exploit bugs when running under Windows 95 - on Windows 11, there's a promise that if a page is writable, the processor will fault if you try to execute it, but in Windows 95 days, you could write to a page, and then trigger a jump...
@Frédéric B.
"What I meant is that I would expect any protected mode OS to by default mark the code segment as non-writable after loading it. So the program would need to explicitly change permissions before pulling this kind of stunt. But in retrospect that would probably break older programs that did it."
This is actually a configurable setting in Windows, and yes, it does interfere with older programs.
The setting is "Data Execution Prevention", and it can be configured to only cover Windows system programs and services, or all programs on the system.
By default, client versions of Windows have DEP turned off(system...
Enforcing W^X at the OS level would make HEAP_CREATE_ENABLE_EXECUTE fail and force any run-time thunk to be on its own page (or worse, its own page allocation boundary).
>it would be entirely possible (in protected mode) to set the page writable and executable at the same time.
What I meant is that I would expect any protected mode OS to by default mark the code segment as non-writable after loading it. So the program would need to explicitly change permissions before pulling this kind of stunt. But in retrospect that would probably break older programs that did it.
@Joshua Hudson:
This is exactly correct.
This is the difference in understanding what a feature does, and what it's generally used for.
The NX(No eXecute) bit does exactly that: it prevents the page from being used as executable code, the same as the write bit sets whether or not the page can be written to.
The two are not mutually exclusive, and both can be set or unset for any page.
The NX bit is usually used in tandem with unsetting/resetting the write bit, so your pages containing executable code can't be dynamically modified, safeguarding the code against various memory attacks. But as Joshua said,...
@Simon Farnsworth : I wish people wouldn't make stuff up.
Truth: the NX bit is used to enforce code from non-executable pages is not executed
Myth: the OS enforces writable XOR executable
Not two years ago I made a mistake and had the wrong alignment for the writable data segment (8 bytes rather than 4096 bytes). The linker noticed it was trying to place writable data and code on the same page, and rather than adjust the alignment, it created a single page section that had RWX all set to true, and since main() was on the bottom (common result of a...
So if any TSR is loaded before win.com, fast restart is not possible?
The TSR would be loaded in memory below that of win.com, not after, so win.com still sees a large continuous block of memory after its own code.