Enhanced-mode Windows 3.0 didn't exactly run a copy of standard-mode Windows | Hacker News Reader

Enhanced-mode Windows 3.0 didn't exactly run a copy of standard-mode Windows

blogs.msdn.com

53 pointsAndrewDucker14 comments

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?

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

Your second reason is right on.

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.

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.

That doesn't stop some people making interesting windows distros, though - my favourite example is this attempt at recreating NT history: http://www.betaarchive.com/forum/viewtopic.php?f=21&t=10...

And the old MS-DOS 6.0 source too.

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

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.

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

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.

In some older version of Windows, the blue screen would dump out debugging information that was useful to developers. For example:

http://www.flickr.com/photos/chagiajose/3326640267/lightbox/

Reply on news.ycombinator.com