Okay, I went back and dug through the old Windows 3.0 source code to answer this question. It took me about four hours to study it all, try to understand what the code was doing, and then distill the conclusions into this article. Writing up the results took another two hours. That's six hours I could've spent doing something enjoyable.
It's interesting that Raymond has the source at hand. How many people at Microsoft have general access to the Windows 3.0 source code still? I wonder what barriers remain for Microsoft to just release early Windows source to the academic community so that Raymond doesn't have to be the proxy for all these questions? Is there any evidence than any valuable Windows 3.0 code remains in Windows 7 and is therefore worth protecting?
Large parts of the source code to NT4 and 2000 were leaked and are trivially available - and there's also the WRK for more modern kernel sources.
Of course, simply having read illegally-downloaded, copyrighted microsoft code makes you a liability in the eyes of several open source projects such as Wine and ReactOS.
- still part of current Windows (unsure about specific code, but 32-bit Win7 still has enough code to run Win3x apps, possible Win8 does but haven't confirmed personally)
What I took away from that statement was how incredibly sharp you have to be to summarize the differences between ancient kernels (and he implies that he hasn't seen the source code in a long time) in about 4 hours.
Good ol' windows DPMI, where you could create a read/write LDT value with the same address as the GDT, taking over the processor security at the lowest level. That wasn't fixed until win2k.
So, the reason that hangs win9x is that cli disables interrupts, then foo: jmp foo runs into an infinite loop. With interrupts disabled, it's impossible to preempt the process, so it just hangs everything.
This shouldn't work from a win32 app, though, since that runs in ring3 where cli is an illegal instruction; it should only work from VDMs.
I know what this code is supposed to do. I wrote it myself expecting to see "General Protection Fault".
IIRC, it indeed faulted when executed from main() in a C application, but somehow it hanged Windows 95/98 when inserted immediately at the _start label of a simple 32-bit assembly code. So either executables had some "run in ring3" flag which my assembler didn't set, or the pre-main() initialization code was handled in some special way (executed in supervisor mode or with broken exception handling resulting in a lockup).
Ahh, misunderstood your original statement, sorry!
And yeah, it should fault; I don't see why they'd run init code in ring0, but win9x did some very strange stuff. There was some malware that I'm trying to recall that would rewrite the IDT and then trigger an interrupt, immediately running itself in ring0 -- anyone know which that was? I used to have the assembly sitting around, since it was a fun little virus to analyze.
In Windows 9x they always were interactive - you could either reboot immediately with CTRL+ALT+DEL or press "any key" to enjoy further bluescreens, probably at the cost of slightly increased probability of filesystem corruption.
I always chose the second option. I liked watching W95 scandisk with this bullet point list of checks it's going to perform and animated progress bar. Much better than NT scandisk.
It's interesting that Raymond has the source at hand. How many people at Microsoft have general access to the Windows 3.0 source code still? I wonder what barriers remain for Microsoft to just release early Windows source to the academic community so that Raymond doesn't have to be the proxy for all these questions? Is there any evidence than any valuable Windows 3.0 code remains in Windows 7 and is therefore worth protecting?