

Enhanced-mode Windows 3.0 didn't exactly run a copy of standard-mode Windows - AndrewDucker
http://blogs.msdn.com/b/oldnewthing/archive/2013/02/08/10392028.aspx

======
rhplus
_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?

~~~
ConstantineXVI
Many possible reasons:

\- 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)

\- third-party code they don't have full rights to

\- trade secrets

\- pride

\- simply don't care

~~~
RyJones
Your second reason is right on.

------
snarfy
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.

~~~
mich41
So it was never fixed. Win2k ran the NT kernel which AFAIK was written from
scratch.

Another funny thing which worked in win9x was:

    
    
            cli
     foo:   jmp foo
    

I never understood why and how, but it really did.

~~~
daeken
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.

~~~
mich41
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).

~~~
daeken
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.

------
sosuke
Woah, I never knew the blue screen of death was at one time functional.

~~~
mich41
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.

