| Date: | April 7, 2004 / year-entry #134 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20040407-00/?p=39893 |
| Comments: | 14 |
| Summary: | In an earlier comment, Larry Osterman described why Windows 3.0 was such a runaway success. He got a little of the timeline wrong, so I'll correct it here. Windows 2.0 did support protected mode. And it was Windows/386, which came out before Windows 3.0, which first used the new virtual-x86 mode of the 80386 processor... |
In an earlier comment, Larry Osterman described why Windows 3.0 was such a runaway success. He got a little of the timeline wrong, so I'll correct it here. Windows 2.0 did support protected mode. And it was Windows/386, which came out before Windows 3.0, which first used the new virtual-x86 mode of the 80386 processor to support pre-emptively multitasked DOS boxes. The old Windows 2.0 program was renamed "Windows/286" to keep the names in sync. The three modes of Windows then became "real mode" (Windows 1.0 style), "standard mode" (Windows/286 style) and "enhanced mode" (Windows/386 style). Amazingly, even though the way the operating system used the processor was radically different in each of the three modes, a program written for "real mode" successfully ran without change in the other two modes. You could write a single program that ran on all three operating systems. And then Windows 3.0 came out and the world changed. Sales were through the roof. I remember that some major software reseller (Egghead?) was so pleased with the success of Windows 3.0 that it bought bought every Microsoft employee a Dove ice cream bar. (Even the employees like me who were working on OS/2.) I was sitting in my office and some people came in with a big box of ice cream bars and they handed me one. "This is from Egghead. Thank you for making Windows 3.0 a success," they said. It was a strange feeling, getting a thank-you for something you not only didn't work on, but something which totally destroyed the project you were working on! [Raymond is currently on vacation; this message was pre-recorded.] |
Comments (14)
Comments are closed. |
Egghead was owned by the same company that owned a supermarket chain, QFC.
And the dove bars (I remember them) were months past their expiration date. I was sort of surprised at how bad they tasted.
So I think egghead, a fairly inept operation to begin with, was just dumping leftover inventory from their supermarkets.
You had to ruin the story didn’t you Joel?
That’s funny for so many reasons.
I love your blog, and am a regular reader, but I had to comment on this: "Windows 2.0 did support protected mode… The old Windows 2.0 program was renamed "Windows/286" to keep the names in sync. "
Are you sure about that? The only 286-specific feature I remember about Windows 2.x/286 was that they could enable the A20 line (via himem.sys) and use the memory between 1024-1088K for the windows environment. I always remembered that protected mode execution of kernel/user/gdi was added in 3.x.
The story behind that I had heard was that some Microsoft employee was inspired and tried to port the Windows kernel to protected mode himself. After he got it working, he demoed it to senior management (Gates/Ballmer??) who saw the implications right away.
Yeah, I remember reading a book that said David Weiss did it.
Joel, so the dates were expired. What made you want to taste them so bad? Was it the bright shiny packaging.
Ah win3.0,the good old days when configuration madness was somewhat manageable.
Peter Evans, you clearly have never seen developers get their hands on free food.
"Geez, those donuts are leftover from yesterday, that’s lame… hey, who ate them all without throwing out the box?!"
Mike,
I’m sure that Windows 2.0 was capable of using (almost) all of 16M of 80286 Protected Mode address space. Of course, those were segments of 64K and two descriptor tables inside which made coding for this architecture quite difficult, so not too many applications actually took advantage of this. I remember the joy of allocating arrays bigger then 64K. Because of those descriptor tables it was even more complicated then in Real Mode, i.e. some techniques didn’t work.
It was until Win 3.0 with Win32s, when plain address space became available and everyone just fell in love with it and huge wave of applications emerged on this platform.
As of A20 and himem.sys, that could be done in DOS completely in Real Mode. The only reason Protected Mode was required is that upper 64K-16 bytes was actually a window, through which all the upper memory could be accessed. It was implemented by going to Protected Mode and copying requested segments of memory into this window. There was a trick of getting back into the real mode, since 80286 wasn’t capable of going back, it had to be restarted (by causing double fault, if I’m not mistaken). BIOS was capable of recognizing this kind of restart and not initiating POST sequence.
RomanP,
The PC-AT’s keyboard controller could restart the CPU, and the CPU could tell the controller to do it.
"I’m sure that Windows 2.0 was capable of using (almost) all of 16M of 80286 Protected Mode address space."
Ok… there’s a difference between "using all of the protected mode address space" and "running in protected mode". Are you referring to Windows switching to protected mode to copy segments to and from memory >1MB, and then switching back to real mode to actually execute Windows and user apps?
"Of course, those were segments of 64K and two descriptor tables inside which made coding for this architecture quite difficult,"
Heh… trust me… I remember __ahincr and __ahshift quite well. :-)
"It was until Win 3.0 with Win32s, when plain address space became available and everyone just fell in love with it and huge wave of applications emerged on this platform. "
My understanding of the timing is this:
Windows 1.0-2.x and /286, /386 – Windows and Windows applications run in real mode with (segment*16+offset) addressing. Windows has facilities to page unlocked segments to and from EMS and XMS memory.
Windows /386 – This is Windows 2.x with the VxD style 32-bit multitasker underneath. Windows still runs in real mode, but this time in a V86 session alongside ofther V86 sessions that can run DOS applications.
Windows 3.0 – Windows can run in real, standard, or 386 enhancded mode. Real mode is analagous to Windows 2.x. Standard Mode and Enhanced mode have made the major change that the Windows environment itself (kernel/gdi/user) runs in protected mode with descriptor_table[selector]+offset addressing. 386 enhanced mode runs an updated version of the VxD 32-bit layer that also acts as a DPMI server to provide the services to allow the Windows environment to run in protected mode.
Windows 3.1 – Adds ExecPE and other parts of the mechanism to support Win32s.
Windows 3.11 – Moves some entry points around to break OS/2 for Windows. :-)
Windows for Workgroups 3.11 – Notable for moving the FAT file system code from real-mode into the 32-bit VxD part of the OS. This is called 32 Bit File Access.
"As of A20 and himem.sys, that could be done in DOS completely in Real Mode."
That’s the 1024-1088K thing I mentioned.
"The only reason Protected Mode was required is that upper 64K-16 bytes was actually a window, through which all the upper memory could be accessed. It was implemented by going to Protected Mode and copying requested segments of memory into this window. There was a trick of getting back into the real mode, since 80286 wasn’t capable of going back,"
Okay, based on this, is my first statment true?
That is "Windows/286 ran all of its applications in real mode, but switched into protected mode to allow copying information to and from" memory >1MB?"
Thanks,
Mike
Windows 2.0 supported two modes, "real mode" and "standard mode". Standard mode used the 80286 16-bit protected mode.
Windows/386 added "enhanced mode" which used the 80386 32-bit protected mode to provide virtual memory to the 80286 16-bit protected mode kernel.
By the time you reached Windows 3.0, the only time you ran in real mode was to change the size of your pagefile. (This operation could not be done whle the pagefile was in used, so you had to do it from real mode.)
The weirdness that RomanP refers to is that memory blocks larger than 64K used multiple consecutive selectors, where "consecutive" means that each one is the previous one plus 4. (The bottom two bits of the selector encodes ring information.) So the byte after xxxx:FFFF was (xxxx+4):0000 if you’re in protected mode [assuming it was part of a contiguous allocation], but it’s (xxxx+4096):0000 if you’re in real mode.
RomanP’s remark about the "64K-16 bytes" is talking about something else entirely (the HMA). It is irrelevant to Windows protected mode.
Before continuing, I really do enjoy your blog, despite being a little blockheaded about this whole protected mode Windows/286 thing. :-)
‘Windows 2.0 supported two modes, "real mode" and "standard mode". Standard mode used the 80286 16-bit protected mode. ‘
This is what I dispute. According to Microsoft Knowledge Base article 58315, entitled "Summary of new features in Windows 3.0", the first entry on the list is "Windows now runs in protected mode on appropriate configurations. This gives applications direct access to extended memory and allows more simultaneous applications to be run. "
In Knowledge Base article 58317, "Windows 3.0 Modes and Memory Requirements", the summary line reads "This article contains information on the processor and memory requirements for the three different operating modes of Microsoft Windows version 3.0. These modes are real mode (similar to Windows/286 versions 2.x), 286 standard mode (also known as 286 protected mode), and 386 enhanced mode (also known as 386 protected mode). "
KB 32905 also mentions "Windows runs in protected mode" as the first feature listed for version 3.0.
BTW, I do not dispute that XMS memory might have required switching to and from protected mode, but I’ve always gotten the impression that was solely to copy memory blocks >1MB into the real-mode address space so that real mode processes could access the data. I honestly don’t know/remember.
"The weirdness that RomanP refers to is that memory blocks larger than 64K used multiple consecutive selectors, where "consecutive" means that each one is the previous one plus 4. "
That was what I was referring to when I spoke of __ahincr and __ahshift. The only documentation I still have on this is in Schulman’s "Undocumented Windows", but I’m pretty sure that they were documented parts of 3.1, since I was using them to access huge arrays before I had the book.
"RomanP’s remark about the "64K-16 bytes" is talking about something else entirely (the HMA)."
And that was what I was referring to when I mentioned the range of memory at 1024-1088K and the A20 line.
This discussion has brought back another distant memory. Wasn’t there a way to run 32-bit user code in Windows 3.0 that predated Win32S} IIRC it didn’t allow any kind of API access, and was basically entirely useful for computational kernels, etc.. I seem to remember seeing something about that in the old Microsoft help file that shipped with Turbo Pascal for Windows 1.0 (even though TPW didn’t support 32-bit compilation, of course).
Rats, you may be right, Mike. I can’t remember any more…
Yes, there was a library for 32-bit memory in Windows 3.z but I too forgot the name…