Difference between revisions of "Windows 3.0"

From Computer History Wiki
Jump to: navigation, search
(some notes on modes.)
Line 8: Line 8:
 
}}
 
}}
 
[[Image:Windows 3.0 on Virtual PC 2007.jpg|200px|thumb|right|Windows 3.0 on Virtual PC 2007]]  
 
[[Image:Windows 3.0 on Virtual PC 2007.jpg|200px|thumb|right|Windows 3.0 on Virtual PC 2007]]  
 +
 +
== About ==
  
 
Windows 3.0 was the breakout sucess that [[Microsoft]] had long hoped for.  At the time they were partnering with [[IBM]] with the [[OS/2]] project.  However they didn't want to have such a large 'break' with their main product of the time [[MS-DOS]] so they kept on looking for ways to improve on it.  Microsoft had become enamored with the new intel i386 cpu, and wanted to build a great 32bit enviroment.  While IBM had insisted OS/2 support the 16 bit i286 cpu, Microsoft was free to make improvements to it's current realmode 16bit enviroment Windows.
 
Windows 3.0 was the breakout sucess that [[Microsoft]] had long hoped for.  At the time they were partnering with [[IBM]] with the [[OS/2]] project.  However they didn't want to have such a large 'break' with their main product of the time [[MS-DOS]] so they kept on looking for ways to improve on it.  Microsoft had become enamored with the new intel i386 cpu, and wanted to build a great 32bit enviroment.  While IBM had insisted OS/2 support the 16 bit i286 cpu, Microsoft was free to make improvements to it's current realmode 16bit enviroment Windows.
  
 
On the way to Windows 3.0 there was work done on the kernel to support limited multitaksing (cooperative) in the 2.0 series, culimnating with a 286 version of Windows 2.0 that could run more then one MS-DOS session, although it was very unstable, and a version for the 386 that could run full multiple dos machines (VDM's) within the 16bit constraints.  Expanding on this work, the next logical step was to get Windows to execute in protected mode.
 
On the way to Windows 3.0 there was work done on the kernel to support limited multitaksing (cooperative) in the 2.0 series, culimnating with a 286 version of Windows 2.0 that could run more then one MS-DOS session, although it was very unstable, and a version for the 386 that could run full multiple dos machines (VDM's) within the 16bit constraints.  Expanding on this work, the next logical step was to get Windows to execute in protected mode.
 +
 +
== Background ==
  
 
What had started out as a skunkworks project had shifted the direction of the entire company.  There is an excellent article about it here:  http://blogs.msdn.com/murrays/archive/2006/12/07/saving-windows-from-the-os-2-bulldozer.aspx
 
What had started out as a skunkworks project had shifted the direction of the entire company.  There is an excellent article about it here:  http://blogs.msdn.com/murrays/archive/2006/12/07/saving-windows-from-the-os-2-bulldozer.aspx

Revision as of 14:48, 24 August 2009


Windows 3.0
Type: single user enviroment
Creator: Microsoft
Multitasking: cooperative with paging (386) / swap (286)
Architecture: i86, i286, i386
Date Released: 1990
Windows 3.0 on Virtual PC 2007

About

Windows 3.0 was the breakout sucess that Microsoft had long hoped for. At the time they were partnering with IBM with the OS/2 project. However they didn't want to have such a large 'break' with their main product of the time MS-DOS so they kept on looking for ways to improve on it. Microsoft had become enamored with the new intel i386 cpu, and wanted to build a great 32bit enviroment. While IBM had insisted OS/2 support the 16 bit i286 cpu, Microsoft was free to make improvements to it's current realmode 16bit enviroment Windows.

On the way to Windows 3.0 there was work done on the kernel to support limited multitaksing (cooperative) in the 2.0 series, culimnating with a 286 version of Windows 2.0 that could run more then one MS-DOS session, although it was very unstable, and a version for the 386 that could run full multiple dos machines (VDM's) within the 16bit constraints. Expanding on this work, the next logical step was to get Windows to execute in protected mode.

Background

What had started out as a skunkworks project had shifted the direction of the entire company. There is an excellent article about it here: http://blogs.msdn.com/murrays/archive/2006/12/07/saving-windows-from-the-os-2-bulldozer.aspx

Thursday, December 07, 2006 9:57 PM MurrayS
Saving Windows from the OS/2 Bulldozer
In my blog description, I promised to write occasionally about the early Windows days. So here's a post on how David Weise and I got Windows 2.0 into protected mode and blew away the old DOS 640 KB RAM barrier. If this hadn't happened, we'd probably be using some variant of OS/2 today instead of Windows. I wrote this text for Chapter 5 of the book The Personal Computer from the Inside Out, by Richard Shoemaker and myself, published by Addison-Wesley (3rd edition, 1994). Chapter 5 contains a wealth of information on the Intel x86 protected-mode architecture in case you're interested in more details. SST (Scroll Screen Tracer) is referred to below. It's the debugger I wrote that was popular back in the days when people still wrote assembly language. It could even execute backwards!
"Back in the summer of '88, one of us (Murray) was consulting at Microsoft with the mission to write a 286-compatible DOS extender and get Microsoft's CodeView debugger running in protected mode up out of the way of DOS programs running down below in the first megabyte of RAM. To get the ball rolling, Murray built the DOS extender into SST, with the idea that it would be separated out later, something Murray's colleague, Gene Apperson, did, in fact do.

"Aiding the project was SST's ability to load a real-mode .exe in a way that the .exe could run in protected mode. Basically, instead of relocating .exe segment values to the corresponding runtime paragraphs, SST replaced the segment values with selectors pointing to segment-descriptors with appropriate base addresses. In addition to identifying the .exe locations with segment values, the real-mode .exe header includes a far start address whose segment clearly has to be a code segment. Accordingly SST marked the descriptor attribute for that segment to be for code and all others to be for data. Of course, some of these allegedly data segments could be code segments and if you try to execute an instruction in a data segment, a general-protection (GP) exception occurs. So any time a GP exception occurred due to data being executed, SST changed the corresponding descriptor attribute to be for code and iret'd to the faulting instruction. Worked like a champ!

"Well, at a late-June Friday-night party celebrating the opening of Microsoft's big new Canyon-Park manufacturing facility, Murray spied his good friend David Weise, a Windows developer, fellow physicist, and all-round computer whiz. Looking for some fun, Murray teased David that David's new Windows 286 (Windows 2.x with access to the 64-KB HMA) was basically a joke. What one really should do was to get Windows into protected mode and blow away the 640-KB RAM barrier altogether. Much to Murray's surprise, David said, "Yes, let's go do it!" So Murray said, "OK, how about tomorrow?" David said, "No, let's go right now!" And so the two left the party, went over to the Microsoft campus, and used SST to load the Windows 2.x kernel.exe into protected mode. They single stepped along for a while and then, sure enough, GP fault! David fixed the code for that GP fault and single stepped on to the next. Things looked really exciting.

"For several weeks, David worked through the main Windows 2.x dynamic link libraries (DLLs), kernel.exe, gdi.exe, and user.exe, ironing out the GPs, and getting Murray to add features to SST to aid the debugging process. Thanks to Steve Wood's original memory-allocation design, many of the changes involved bypassing real-mode code that served only to emulate the protected mode of the 286. For a whole month following the Friday-evening party, David and Murray told no one what they were doing. The buzzword of the day was "OS/2" and many people at Microsoft (let alone at IBM) might have been really upset to learn that Windows would soon grow out of its baby clothes.

"Meanwhile, as well documented, in the book by Manes and Andrews (1992) and elsewhere, Bill Gates and Steve Ballmer had had it up to their ears with IBM's old-fashioned software development methods and continual specification changes on OS/2. So when David showed Steve how close he was to getting Windows into protected mode, Steve said "Let's go for it," a decision enthusiastically endorsed by Bill in the Windows 3.0 planning meeting three days later.

"There's a whole lot between that early version of protected-mode Windows and the ones described in the following section. But there's no doubt that busting the 640-KB RAM barrier was akin to letting a genie out of the bottle."

With Windows now running in protected mode, that meant that people would have access to more memory (albeit in 64k chunks as both the 386 & 286 kept the 286's memory model for compatability) and errant applications would generate a UAE, and the enviroment could potentially keep on running.

Around this time Mircrosoft then had released QuickC for Windows, which included a version of the Microsoft C Compiler that executed in protected mode, and a copy of the Windows SDK for $149, and allowed other vendors to license and re-sell the Windows SDK. Borland and Watcom come to mind as two that did. Compared to the price (and availability) of the OS/2 SDK, more and more developers chose to go with Windows.

Modes

Windows 3.0 had three different modes of operation, each tailored for a specific CPU generation.

Real Mode

Real mode, operated in the 'real mode' of the 286 & 386 cpu's, and on any 8086/8088 80186 cpu, confined to only 1MB of accessable memory. This was more so for compatability with prior versions of Windows.

Standard Mode

The standard mode took advantage of the i286 cpu's protected mode. It allowed for MS-DOS sessions, however all Windows programs would be paged out to disk while the MS-DOS session was running. Standard mode allowed for limited segmentation however it wasn't real virtual memory like OS/2 had for it's 16bit version. Standard mode was really a stop gap measure for the 386 mode.


386 Enhanced Mode

This mode enabled VDM's limited pre-emptive multitasking of VDM's and demand paged virtual memory. However it's protected mode enviroment for Windows applications was the same as the 286 version, it could just access more physical RAM and swap better. At the time the big feature was to copy & paste data between multiple DOS machines, and to copy data into the new Windows applications.