The beginning of serious work on the operating system that would come to be known as OS/2 left Microsoft’s team of Windows developers on decidedly uncertain ground. As OS/2 ramped up, Windows ramped down in proportion, until by the middle of 1986 Tandy Trower had just a few programmers remaining on his team. What had once been Microsoft’s highest-priority project had now become a backwater. Many were asking what the point of Windows was in light of OS/2 and its new GUI, the Presentation Manager. Steve Ballmer, ironically the very same fellow who had played the role of Windows’s cheerleader-in-chief during 1984 and 1985, was now the most prominent of those voices inside Microsoft who couldn’t understand why Trower’s team continued to exist at all.
Windows survived only thanks to the deep-seated instinct of Bill Gates to never put all his eggs in one basket. Stewart Alsop II, editor-in-chief of InfoWorld magazine during this period:
I know from conversations with people at Microsoft in environments where they didn’t have to bullshit me that they almost killed Windows. It came down to Ballmer and Gates having it out. Ballmer wanted to kill Windows. Gates prevented him from doing it. Gates viewed it as a defensive strategy. Just look at Gates. Every time he does something, he tries to cover his bet. He tries to have more than one thing going at once. He didn’t want to commit everything to OS/2, just on the off chance it didn’t work. And in hindsight, he was right.
Gates’s determination to always have a backup plan showed its value around the beginning of 1987, when IBM informed Microsoft of their marketing plans for their new PS/2 hardware line as well as OS/2. Gates had, for very good reason, serious reservations about virtually every aspect of the plans which IBM now laid out for him, from the fortress of patents being constructed around the proprietary Micro Channel Architecture of the PS/2 hardware to an attitude toward the OS/2 software which seemed to assume that the new operating system would automatically supersede MS-DOS, just because of the IBM name. (How well had that worked out for TopView?) “About this time is when Microsoft really started to get hacked at IBM,” remembers Mark Mackaman, Microsoft’s OS/2 product manager at the time. IBM’s latest misguided plans, the cherry on top of all of Gates’s frustration with his inefficient and bureaucratic partners, finally became too much for him. Beginning to feel a strong premonition that the OS/2 train was going to run off the tracks alongside PS/2, he suddenly started to put some distance between IBM’s plans and Microsoft’s. After having all but ignored Windows for the past year, he started to talk about it in public again. And Tandy Trower found his tiny team’s star rising once again inside Microsoft, even as OS/2’s fell.
The first undeniable sign that a Windows rehabilitation had begun came in March of 1987, when Microsoft announced that they had sold 500,000 copies of the operating environment since its release in November of 1985. This number came as quite a surprise to technology journalists, whose own best guess would have pegged Windows’s sales at 10 percent of that figure at best. It soon emerged that Microsoft was counting all sorts of freebies and bundle deals as regular unit sales, and that even by their own most optimistic estimates no more than 100,000 copies of Windows had ever actually been installed. But no matter. For dedicated Microsoft watchers, their fanciful press release was most significant not for the numbers it trumpeted but as a sign that Windows was on again.
According to Paul and George Grayson, whose company Micrografix was among the few which embraced Windows 1, the public announcement of OS/2 and its Presentation Manager in April of 1987 actually lent Microsoft’s older GUI new momentum:
Everybody predicted when IBM announced OS/2 and PM [that] it was death for Windows developers. It was the exact opposite: sales doubled the next month. Everybody all of a sudden knew that graphical user interfaces were critical to the future of the PC, and they said, “How can I get one?”
You had better graphics, you had faster computers, you had kind of the acknowledgement that graphical user interfaces were in your future, you had the Macintosh being very successful. So you had this thing, this phenomenon called Mac envy, beginning to occur where people had PCs and they’d look at their DOS-based programs and say, “Boy, did I get ripped off.” And mice were becoming popular. People wanted a way to use mice. All these things just kind of happened at one moment in time, and it was like hitting the accelerator.
It did indeed seem that Opportunity was starting to knock — if Microsoft could deliver a version of Windows that was more compelling than the first. And Opportunity, of course, was one house guest whom Bill Gates seldom rejected. On October 6, 1987, Microsoft announced that Windows 2 would ship in not one but three forms within the next month or two. Vanilla Windows 2.03 would run on the same hardware as the previous version, while Windows/386 would be a special supercharged version made just for the 80386 CPU — a raised middle finger to IBM for refusing to let Microsoft make OS/2 an 80386-exclusive operating system.
But the most surprising new Windows product of all actually bore the name “Microsoft Excel” on the box. After struggling fruitlessly for the past two years to get people to write native applications for Windows, Microsoft had decided to flip that script by making a version of Windows that ran as part of an application. The new Excel spreadsheet would ship with what Microsoft called a “run-time” version of Windows 2, sufficient to run Excel and only Excel. When people tried Excel and liked it, they’d go out and buy a proper Windows in order to make all their computing work this way. That, anyway, was the theory.
Whether considered as Excel for Windows or Windows for Excel, Microsoft’s latest attempt to field a competitor to Lotus 1-2-3 already had an interesting history. It was in fact a latecomer to the world of MS-DOS, a port of a Macintosh product that had been very successful over the past two years.
After releasing a fairly workmanlike version of Multiplan for the Macintosh back in 1984, Microsoft had turned their attention to a more ambitious Mac spreadsheet that would be designed from scratch in order to take better advantage of the GUI. The wisdom of committing resources to such a move sparked considerable debate both inside and outside their offices, especially after Lotus announced plans of their own for a Macintosh product called Jazz.
Lotus 1-2-3 on MS-DOS was well on its way to becoming the most successful business application of the 1980s by combining a spreadsheet, a database, and a business-graphics application in one package. Now, Lotus Jazz proposed to add a word processor and telecommunications software to that collection on the Macintosh. Few gave Microsoft’s Excel much chance on the Mac against Lotus, the darling of the Fortune magazine set, a company which could seemingly do no wrong, a company which was arguably better known than Microsoft at the time and certainly more profitable. But when Jazz shipped on May 27, 1985, it was greeted with unexpectedly lukewarm reviews. It felt slow and painfully bloated, with an interface that felt more like a Baroque fugue than smooth jazz. For the first time since toppling VisiCalc from its throne as the queen of American business software, Lotus had left the competition an opening.
Excel for Mac shipped on September 30, 1985. In addition to feeling elegant, fast, and easy in contrast to the Lotus monstrosity, Microsoft’s latest spreadsheet was also much cheaper. It outdistanced its more heralded competitor in remarkably short order, quickly growing into a whale in the relatively small pond that was the Macintosh business-applications market. In December of 1985, Excel alone accounted for 36 percent of said market, compared to 9 percent for Jazz. By the beginning of 1987, 160,000 copies of Excel had been sold, compared to 10,000 copies of Jazz. And by the end of that same year, 255,000 copies of Excel had been sold — approximately one copy for every five Macs in active use.
Such numbers weren’t huge when set next to the cash cow that was MS-DOS, but Excel for the Macintosh was nevertheless a breakthrough product for Microsoft. Prior to it, system software had been their one and only forte; despite lots and lots of trying, their applications had always been to one degree or another also-rans, chasing but never catching market leaders like Lotus, VisiCorp, and WordPerfect. But the virgin territory of the Macintosh — ironically, the one business computer for which Microsoft didn’t make the system software — had changed all that. Microsoft’s programmers did a much better job of embracing the GUI paradigm than did their counterparts at companies like Lotus, resulting in software that truly felt like it was designed for the Macintosh from the start rather than ported over from another, more old-fashioned platform. Through not only Excel but also a Mac version of their Word word processor, Microsoft came to play a dominant role in the Mac applications market, with both products ranking among the top five best-selling Mac business applications more months than not during the latter 1980s. Now the challenge was to translate that success in the small export market that was the Macintosh to Microsoft’s sprawling home country, the land of MS-DOS.
On August 16, 1987, Microsoft received some encouraging news just as they were about to take up that challenge in earnest. For the first time ever, their total sales over the previous year amounted to enough to make them the biggest software company in the world, a title which they inherited from none other than Lotus, who had enjoyed it since 1984. The internal memo which Bill Gates wrote in response says everything about his future priorities. “[Lotus’s] big distinction of being the largest is being taken away,” he said, “before we have even begun to really compete with them.” The long-awaited version of Excel for PC compatibles would be launched with two important agendas in mind: to hit Lotus where it hurt, and to get Windows 2 — some form of Windows 2 — onto people’s computers.
Excel for Windows — or should we say Windows for Excel? — reached stores by the beginning of November 1987, to a press reception that verged on ecstatic. PC Magazine‘s review was typical:
Microsoft Excel, the new spreadsheet from Microsoft Corp., could be one of those milestone programs that change the way we use computers. Not only does Excel have a real chance of giving 1-2-3 its most serious competition since Lotus Development Corp. introduced that program in 1982, it could finally give the graphics interface a respectable home in the starched-shirt world of DOS.
For people who cut their teeth on 1-2-3 and have never played with a Mac, Excel looks more like a video game than a serious spreadsheet. It comes with a run-time version of Microsoft Windows, so it has cheery colors, scroll bars, icons, and menu bars. But users will soon discover the beauty of Windows. Since it treats the whole screen as graphics, you can have different spreadsheets and charts in different parts of the screen and you can change nearly everything about the way anything looks.
Excel won PC Magazine‘s award for “technical excellence” in 1987 — a year that notably included OS/2 among the field of competitors. The only thing to complain about was performance: like Windows itself, Excel ran like a dog on an 8088-based machine and sluggishly even on an 80286, requiring an 80386 to really unleash its potential.
Especially given the much greater demands Excel placed on its hardware, it would have to struggle long and hard to displace the well-entrenched Lotus 1-2-3, but it would manage to capture 12 percent of the MS-DOS spreadsheet market in its first year alone. In the process, the genius move of packaging Windows itself with by far the most exciting Windows application yet created finally caused significant numbers of people to actually start using Microsoft’s GUI, paving the road to its acceptance among even the most conservative of corporate users. Articles by starch-shirted Luddites asking what GUIs were really good for became noticeably less common in the wake of Excel, a product which answered that question pretty darn comprehensively.
Of course, Excel could never have enjoyed such success as the front edge of Microsoft’s GUI wedge had the version of Windows under which it ran not been much more impressive than the first one. Ironically, many of the most welcome improvements came courtesy of the people from the erstwhile Dynamical Systems Research, the company Microsoft had bought, at IBM’s behest, for their work on a TopView clone that could be incorporated into OS/2. After IBM gave up on that idea, most of the Dynamical folks wound up on the Windows team, where they did stellar work. Indeed, one of them, Nathan Myhrvold, would go on to become Microsoft’s chief software architect and still later head of research, more than justifying his little company’s $1.5 million purchase price all by himself. Take that, IBM!
From the user’s perspective, the most plainly obvious improvement in Windows 2 was the abandonment of Scott MacGregor’s pedantic old tiled-windows system and the embrace of a system of sizable, draggable, overlappable windows like those found on the Macintosh. For the gearheads, though, the real excitement lay in the improvements hidden under the hood of Windows/386, which made heavy use of the 80386’s “virtual” mode. Windows itself and its MS-DOS plumbing ran in one virtual machine, and each vanilla MS-DOS application the user spawned therefrom got another virtual machine of its own. This meant that as many MS-DOS applications and native Windows applications as one wished could now be run in parallel, under a multitasking model that was preemptive for the former and cooperative for the latter. The 640 K barrier still applied to each of the virtual machines and was thus still a headache, requiring the usual inefficient workarounds in the form of extended or expanded memory for applications that absolutely, positively had to have access to more memory. Still, having multiple 640 K virtual machines at one’s disposal was better than having just one.
Windows/386 was arguably the first version of Windows that wasn’t more trouble than it was worth for most users. If you had the hardware to run it, it was a very compelling product, even if the realities of the software market meant that you used it more frequently to multitask old-school MS-DOS applications than to run native Windows applications.
A Quick Tour of Windows/386 2.11
Microsoft themselves didn’t seem to entirely understand the relationship between Windows and OS/2’s Presentation Manager during the late 1980s. This version of Windows inexplicably has the “Presentation Manager” name as well on some of the disks. No wonder users were often confused as to which product was the real Microsoft GUI of the future. (Version 2.11 of Windows/386, the one we’re looking at here, was released some eighteen months after the initial 2.01 release, which I couldn’t ever manage to get running under emulation due to strange hard-drive errors. But the material differences between the two versions are relatively minor.)
Windows 2 remains less advanced than Presentation Manager in many ways, such as the ongoing lack of any concept of application installation. Without it, we’re still left to root around through the individual files on the hard disk in order to start applications.
Especially in the Windows/386 version, most of the really major improvements that came with Windows 2 are architectural enhancements that are hidden under the hood. There is, however, one glaring exception to that rule: the tiled windows are gone, replaced with a windowing system that works the way we still expect such things to work today. You can drag these windows, you can size them, and you can overlap them as you will.
The desktop concept is still lacking, but we’re making progress. Like in Windows 1, icons on the desktop only represent running applications that have been minimized. Unlike in Windows 1, these icons can now be dragged anywhere on the proto-desktop. From here, it would require only one more leap of logic to start using the icons to represent things other than running applications. Baby steps… baby steps.
Windows/386 removes some if by no means all of the sting from the 640 K barrier. Thanks to the 80386’s virtual mode, vanilla MS-DOS applications can now run in memory above the 640 K barrier, leaving the first 640 K free for Windows itself and native Windows applications. So few compelling examples of the latter existed during Windows/386’s heyday that the average user was likely to spend a lot more time running MS-DOS applications with it anyway. In this scenario, memory was ironically much less of a problem than it would have been had the user attempted to run many native applications.
One of the less heralded of Microsoft’s genius marketing moves has been the use of Microsoft Excel as a sort of Trojan horse to get people using Windows. When installed on a machine without Windows, Excel also installs a “run-time” version of the operating environment sufficient only to run itself. Excel would, as Microsoft’s thinking went, get people used to a GUI and get them asking why they couldn’t use one for the other tasks they had to accomplish on the computer. “Why, as a matter of fact you can,” would go Microsoft’s answer. “You just need to buy this product called Windows.” Uptake wouldn’t be instant, but Excel did become quite successful as a standalone product, and did indeed do much to pave the way for the eventual near-universal acceptance of Windows 3.
Excel running under either a complete or a run-time version of Windows. When it appeared alongside Windows 2 in late 1987, it was by far the most sophisticated and compelling application yet made for the environment, giving the MS-DOS-using masses for the first time a proof of concept of what a GUI could mean in the real world.
Greatly improved though it was, Windows 2 didn’t blow the market away. Plenty of the same old problems remained, beginning and for many ending with the fact that seeing it at its best required a pricey 80386-based computer. In light of this, third-party software developers didn’t exactly stampede onto the Windows bandwagon. Still, having been provided with such a wonderful example in the form of Microsoft Excel of how compelling (and profitable) a Windows application done right could be, some of them did begin to commit some resources to Windows as well as vanilla MS-DOS. Throughout the life of Windows 2, Microsoft made a standard practice of giving their run-time version of it to outside application developers as well as their own, all in a bid to give people a taste of a GUI through the word processor, spreadsheet, or paint program they were going to buy anyway. To some extent at least, it worked. Some users turned that taste into a meal by buying boxed copies of Windows 2, and still more were intrigued enough to quit scoffing and start accepting that GUIs in general might truly be a better way to get their work done — if not now, then at some point in the future, when the hardware and the software had both gotten a little bit better.
By the spring of 1988, Windows was still at least an order of magnitude away from meeting the goal Bill Gates had once stated it would manage before the end of 1984: that of being installed on 90 percent of all MS-DOS computers. But, even if Windows 2 hadn’t blown anyone away, it was doing considerably better than Windows 1, and certainly seemed to have more momentum than OS/2’s as-yet-unreleased Presentation Manager. Granted, neither of these were terribly high bars to clear — and yet there was a dawning sense that Windows, six and a half years on from its birth as the humble Interface Manager, might just get the last laugh on the MS-DOS command line after all. Microsoft was already formulating plans for a Windows 3, which was coming to be seen both inside and outside the company as the pivotal version, the point where steadily improving hardware would combine with better software to break the GUI into the business-computing mainstream at long last. No, it wasn’t 1984 any more, but better late than never.
And then a new development threatened to pull the rug out from under all the progress that had been made. On March 17, 1988, Apple blindsided Microsoft by filing a lawsuit against them in federal court, alleging that the latter had stolen the former’s intellectual property by copying the “look and feel” of the Macintosh GUI. With the gauntlet thus thrown down, the stage was set for one of the most titanic legal battles in the history of the computer industry, one with the potential to fundamentally alter the very nature of the software business. At stake as well was the very existence of Windows just as it finally seemed to be getting somewhere. And as went Windows, Bill Gates was coming to believe once again, so went Microsoft. In order for both to survive, he would now have to win a two-front war: one in the marketplace, the other in the court system.
(Sources: the books The Making of Microsoft: How Bill Gates and His Team Created the World’s Most Successful Software Company by Daniel Ichbiah and Susan L. Knepper, Hard Drive: Bill Gates and the Making of the Microsoft Empire by James Wallace and Jim Erickson, Gates: How Microsoft’s Mogul Reinvented an Industry and Made Himself the Richest Man in America by Stephen Manes and Paul Andrews, Computer Wars: The Fall of IBM and the Future of Global Technology by Charles H. Ferguson and Charles R. Morris, and Apple Confidential 2.0: The Definitive History of the World’s Most Colorful Company by Owen W. Linzmayer; PC Magazine of November 10 1987, November 24 1987, December 22 1987, April 12 1988, and September 12 1989; Byte of May 1988 and July 1988; Tandy Trower’s “The Secret Origins of Windows” on the Technologizer website. Finally, I owe a lot to Nathan Lineback for the histories, insights, comparisons, and images found at his wonderful online “GUI Gallery.”)
Sniffnoy
July 20, 2018 at 5:00 pm
I just have to wonder where the name “Microsoft Excel” came from. Doesn’t fit the whole deliberately-generic naming pattern.
Jimmy Maher
July 20, 2018 at 5:22 pm
Yeah, I haven’t seen a source for that. My feeling is that Microsoft Spreadsheet would be… a little too generic? Microsoft Word worked, but Microsoft Spread certainly doesn’t sound very nice. Excel is a great name anyway, which somehow manages to convey the same spirit of almost generic simplicity.
whomever
July 20, 2018 at 6:05 pm
Also they may have thought that “Microsoft Spreadsheet” could be confused with Multiplan?
Pedro Timóteo
July 20, 2018 at 6:13 pm
I think the point is to be generic and “universal-sounding”, but *not* descriptive. So it’s Word, not Word Processor. It’s PowerPoint, not Presentation(s). Office, not Application Suite or something. Etc. etc..
Steve McCrea
July 20, 2018 at 10:13 pm
I think Microsoft Sheet, Microsoft Cell, or Microsoft Data would have worked better.
“did became” -> “became” or “did become”
Jimmy Maher
July 21, 2018 at 7:35 am
Thanks!
flowmotion
July 21, 2018 at 2:39 pm
I’ve always assumed “Excel” was a play on “cell”, as a spreadsheet is grid of cells. The original icon was also a crossed XL.
Steve McCrea
July 24, 2018 at 4:36 pm
Yes, seems obvious in retrospect!
tedder
July 20, 2018 at 6:57 pm
So good. I didn’t know about the Excel/Windows trojan horse.
Ugh, Myhrvold. The king of the patent troll mountain.
Pierre
July 21, 2018 at 1:27 am
Yeah. That was news to me too and I was around back then. At this time I was running GEM at work which worked way better than Windows 2. It took until Windows 3.1 and the release of Visio for me to fully commit to Windows. I was impressed with Windows 3.0 when it came out but it wasn’t enough for me to go all in.
Lefty
August 12, 2021 at 7:55 pm
Ran WP under DOS and Ventura Publisher under GEM on a 286-12. VP for Windows was a pig, looked to OS/2 (BS/2?) for multitasking but wouldn’t install on a 386 with a SCSI hard disk. Went from doing documents to Multimedia with Video for Windows and WFWG 3.11 and never looked back.
sam
July 20, 2018 at 10:03 pm
Typo: “yet created finally caused”
Jimmy Maher
July 21, 2018 at 7:34 am
As intended, actually…
Keith Palmer
July 21, 2018 at 12:53 am
I didn’t know about Excel being used to promote Windows 2, either. Reading Macworld magazines from the late 1980s, I recall noticing “we’d better keep our eyes open” comments bringing up Aldus Pagemaker for Windows… (I’m sure the next instalment in this series will force me to confront my own prejudices, which didn’t even form until years later.)
The cameo appearance here by Lotus Jazz, although intimated beforehand in some comments on previous entries, did catch my attention. Quite a while ago, I found in the third-to-last issue of Creative Computing an unimpressed review of Jazz; the reviewer John J. Anderson blamed the program’s limitations on the Macintosh 512K’s limitations and offered a laundry list of improvements (all apparently to be squeezed into the compact Macintosh case) to be made before the impending one-two punch of the Commodore Amiga and Atari ST put Apple out of business. I can only wonder what the magazine might have made of Microsoft Excel; a few months later, in the more congenial confines of Macworld, Steven Levy brought up some comments from Lotus to speculate the program just hadn’t been aimed at “power users,” with Excel his counterexample…
Jimmy Maher
July 21, 2018 at 7:37 am
I think Jazz was just trying to do too much. Excel did one thing, and did it well. Jazz did many things, but badly.
whomever
July 21, 2018 at 1:51 am
By the way, let’s not forget Microsoft’s brilliant marketing, including the most epic advertisement ever made (in the same way that the Star Wars Holiday Special was epic): https://www.youtube.com/watch?v=noEHHB6rnMI
Casey Muratori
July 21, 2018 at 7:12 am
It might be worth clarifying that, unless I am misremembering, Windows 2 was _not_ a preemptive multitasking OS. It was only the DOS layer that allowed preemption – programs written for the GUI were still cooperative, I think?
Anyway the article is correct as written, to be sure, because it describes the DOS part as preemptive without explicitly mentioning the rest of the OS. But I just worried that it might be misleading to not be more specific about it!
Great article as always,
– Casey
Jimmy Maher
July 21, 2018 at 7:55 am
Windows/386 actually did use a universal preemptive-multitasking model, for native Windows and vanilla MS-DOS applications alike. It ran exclusively in the 80386’s virtual mode, and every application, regardless of type, got its own preemptively-multitasked virtual machine. The big drawback to this approach was that every application was stuck inside its own 640 K pool of memory.
Later, Windows 3.0 would use DPMI to run native applications in protected mode, reserving virtual mode for MS-DOS applications. The advantage of this was that native Windows applications got a flat memory model, free of having to worry about the 640 K barrier. The drawback was that all of the native applications cooperatively rather than preemptively multitasked.
flowmotion
July 21, 2018 at 2:29 pm
I used Excel 2/3 and Word 4/5 on 68000-based Macintosh SE and they were definitely “killer apps”. Very serendipitous that I made the right choice 25+ years ago, and have never had to relearn any of that.
> Microsoft themselves didn’t seem to entirely understand the relationship between Windows and OS/2’s Presentation Manager during the late 1980s.
Oh, they knew all too well. Ballmer was going around telling developers that Presentation Manager would be “protected mode Windows” and it would be “just a recompile” to ship a 32-bit app. IBM was not on board with that plan, to their later chagrin. Windows NT and Win32 shipped a year after OS/2 2.0, and once MS had a “roadmap”, PM was dead meat.
Tomber
July 21, 2018 at 5:08 pm
Windows/386(and all derivatives) are pretty complicated to explain. Most of what you wrote is true — but not complete. It is not mere coincidence that the best book about it is called Unauthorized Windows 95 by Andrew Schulman. Speaking to /386 or 3.x, the multitasking of DOS apps could be called pre-emptive. Windows apps, not pre-emptive. All calls to DOS and BIOS were generally handled by switching the machine back to real-mode, letting the actual DOS and DOS drivers run, return the result, and then switch back to protected mode to hand the result over to the virtual machine that generated the call. Some calls could bounce around the modes a couple times. This is how Windows 3.1 eventually had ’32-bit Disk Access’ and ’32-bit File Access’, .386 virtual device drivers, and yet still worked perfectly on top of DOS device drivers for CD-ROM, SCSI, etc. Because of all this, crashes were still possible, and not that uncommon. One DOS was shared amongst all, while OS/2 2.x would have the ability to boot separate independent DOS for each instance.
The big catch is that although there was a 32-bit core kernel in operation, the task(VM) that people called ‘Windows’ was running in a single 16-bit protected mode. This similarity allowed a Windows 3.0 executable to run in real-mode, 286 standard(protected) mode, or 386 enhanced(protected) mode, because all the pointers were 16-bit(any experts pardon my looseness here).
Other books are Windows Internals (possibly also Windows 95 system programming secrets) by Matt Pietrek.
With regard to the 640k limit, DOS apps under Windows 3+ could access plenty of memory, using XMS, EMS, or direct DPMI calls if they used DOS extender technology. The remaining problem was how many device drivers you had to load, and whether there was enough 640k left to get Windows or your app running. Some apps would require actual 640K memory, and with many of them running or a memory leak, it could run out while Windows was running.
Jimmy Maher
July 21, 2018 at 5:23 pm
This sounds more like a description of Windows 3.x than Windows/386. To my knowledge, the latter did not “switch the machine back to real-mode, letting the actual DOS and DOS drivers run, return the result, and then switch back to protected mode to hand the result over to the virtual machine that generated the call.” This sounds like a description of the DPMI DOS extender, which didn’t exist until Windows 3.0. Windows/386 is very much an odd duck in the Windows family…
Tomber
July 21, 2018 at 6:08 pm
Windows/386 is an odd-duck because it did what DPMI does, before DPMI was formalized into a standard, which Windows 3 then implemented and served to apps. Windows/386 had no choice but to switch back to real-mode: The only way to avoid switching back to real-mode is to implement a 386 virtual device driver, and they simply didn’t exist for most peripherals at that point in time unless they were generic enough to be implemented in Windows/386. Everything else had to fall back to DOS, DOS drivers, or the BIOS, which meant the CPU could not be in protected mode at that time, in general. (I think in some cases, it was possible to stay in protected mode and reflect a DOS call into a special task(VM) that encased the underlying DOS, but if DOS then called the BIOS, you were going to real mode.)
As an illustration, the reason Windows 3.1x had the 32-bit disk/file access layers available is that Microsoft finally included a 386 virtual device driver for the typical hard disk controller of the time. That allowed the system to stay in protected mode for most hard disk accesses, for the first time. It also implemented a 386 disk cache, since real-mode SMARTDRV would no longer be in the mix.
Jimmy Maher
July 21, 2018 at 6:45 pm
I hesitate to argue too much, as I haven’t seen the sources you reference, but there are a few things that continue to give me pause.
One is this post on the authoritative site OS/2 Museum: http://www.os2museum.com/wp/windows386-2-01/ .
Another is the May 1988 Byte feature article on multitasking, which presents essentially the same description of Windows/386, describing it as preemptive multitasking all around.
And a third is a fairly lengthy account in the book Gates, in which programmer David Weise describes the ability to use protected mode in this way coming to him in the summer of 1988 — i.e., well after the release of Windows/386 — after seeing Murray Sargent’s Microsoft CodeView debugger, which made use of VCPI, Quarterdeck’s earlier implementation of the DOS-extender concept. It then goes on to describe the internal debate around the idea at Microsoft — was it stepping too much on the toes of OS/2? — before Gates said to “go ahead.”
My understanding had been that each virtual machine simply spawned its own copy of MS-DOS under Windows/386. It was such a minimal operating system that the overhead wouldn’t have been that great — certainly well under 100 K. I believe this was how OS/2 functioned.
But I’ll do my best to track down your sources and see what’s what. Thanks!
Lisa H.
July 21, 2018 at 7:50 pm
Excel looks more like a video game than a serious spreadsheet.
…?!? What an odd thing to say.
Jimmy Maher
July 21, 2018 at 10:03 pm
There was a weirdly… puritanical bent to mainstream business computing during the 1980s. Aesthetic ugliness was viewed as a marker of seriousness of intent, its opposite liable to prompt the dreaded label of “games machine.” The PC Magazine reviewer is actually being quite open-minded by the standard of his peers…
VileR
August 8, 2018 at 9:52 am
I read that not really as an expectation of ‘ugliness’, but perhaps a comment on the visual impact of that over-saturated neon palette of 16 colors, which Windows 2 and its applications were using rather garishly (all those bright aqua and yellow highlights everywhere, etc.). Certainly not what people were accustomed to in business software, especially when people’s expectations of a GUI’s look-and-feel were still largely based on the Lisa/Macintosh style with its monochromatic ‘seriousness’.
Alain
July 21, 2018 at 7:53 pm
Good old days.
I installed Windows/386 with Excel and Word for Windows 1.0, I still have the hardcover manual that came with that, with the first HP laser printers for a few brave souls and after the other users saw what could be done I could not keep up with the demand in the shop where I was working at that time.
Tomber
July 21, 2018 at 8:00 pm
It may be that the ‘Windows’ task(VM) on /386 was running in real-mode(which is to say, protected-mode as a V86 task, like a DOS box, with memory being provided by an EMM386-style interface to the 386 kernel), but that doesn’t change that your Windows apps would have been co-operative between themselves. I happen to have the book Gates, and looking at those pages, I will deduce that what Weise was doing was converting the real-mode Windows code(GDI/USER/KERNEL, etc.) to run in what became Standard mode or 386 Enhanced mode(e.g., as a 16-bit protected mode task). There is always a risk of confusion of terms here, because what people call ‘Windows’ was really just a sub-task of a greater, unnamed, 386 kernel. This would be similar to taking relatively clean Turbo Pascal 6 code, and then recompiling it to run in 16-bit protected mode on Borland Pascal 7.0.
That reading explains pretty well why all he needed was a protected-mode debugger, and not what is called a ‘kernel’ debugger. The debugger he used was for apps, while a kernel debugger would be for an operating system kernel, which ‘Windows'(GDI/USER/KERNEL) was not.
As an aside, when Windows 3.x would hang badly, you could press Ctrl-Alt-Delete, and a blue text screen would appear with a couple unpleasant options. That screen was provided by the 386 kernel, and would call itself either IOS (the 386 kernel) or just Windows.
For the Byte reference, I wouldn’t disagree that it is pre-emptive for the DOS boxes, but not Windows apps. Win16 apps are not, by design, capable of pre-emptive multitasking unless you spawn separate Windows16 instances(like NT 3.1 could do, at cost of RAM and loss of sharing/IPC). That would hold until such time as any of them called something that required the machine to switch back to real-mode. Then, not pre-emptive. It is splitting hairs at that point, unless the stability is your focus.(again, like NT 3.1 or OS/2 2.x)
Also, don’t forget, 100K of extra overhead per DOS window is going to be huge in 1987. The whole machine probably only had 2MB, and OS/2 1.x’s memory requirements were a big problem during the DRAM shortage in that timeframe.
Jimmy Maher
July 21, 2018 at 9:21 pm
Okay. Made some updates based on this. It’s still not crystal-clear to me how these additional virtual machines communicated with MS-DOS — for what it’s worth, Windows/386 was also criticized for being memory-hungry — so I’m going to punt on that question for now. I’m on the archive.org waiting list for the first book you suggested. Sigh…
Thanks!
Tomber
July 21, 2018 at 11:05 pm
I just finished flipping through many pages of the books I mentioned previously. Although Windows/386 is not listed as conforming, for Windows 3.0 with 386 Enhanced Mode and higher, Schulman says on page 296: “Let me repeat that: Windows calls down to DOS in V86 mode. Please don’t dismiss this point as mere semantic hairsplitting or as the remark of a pedant.”
I suspect this would apply to Windows/386 as well. In that case, the CPU is not switching back and forth between real and protected modes, it is just patching up a few variables and then changing tasks(context switch). All the calls to DOS and BIOS are reflected into the special task(V86 VM) that encases DOS when Windows first loads. That leaves all your pre-emptive capabilities in place while DOS or BIOS handles those calls.
As to how the VMs are communicating with MS-DOS, that is arbitrated by the 386 kernel, frequently called VMM in the books. If there is a 386 virtual device driver for a particular function, then that reflection into MS-DOS can be skipped entirely, which avoids a frequently convoluted chain of task switches back and forth between the DOS task/VM and the 386 kernel.
Although I didn’t find anything on it yet in those books, it was probably 286 Standard Mode that required frequent switches back to real-mode, as the 286 has no V86 mode. On the 286, that was difficult, since it hadn’t been designed with the expectation that you’d ever return to real mode.
Jimmy Maher
July 22, 2018 at 8:27 am
Okay. So, I guess my question would be, why do we need such a complicated DPMI specification at all, if we’re sticking MS-DOS inside an 80386 virtual machine and talking to it well enough to get work done? In this case, we don’t need to switch the processor into real mode to communicate with MS-DOS, which was supposedly the main point of DPMI. One scenario, especially relevant in the early days, was obviously to get Windows running on an 80286, which doesn’t have a virtual mode. Another, relevant in the Windows 3.11 era, was to get 32-bit applications running in a 16-bit operating system. Is there any other usage scenario? When Windows 3.0 runs a 16-bit Windows application on an 80386, is it not actually making any use of DPMI at all beyond the initial switch into protected mode? (We set up our virtual machine for MS-DOS, we switch into protected mode for running Windows, and we never need to switch into real mode again…) Was the main point of DPMI in the beginning actually to get Windows running in protected mode on an *80286*?
Tomber
July 22, 2018 at 11:44 pm
Those are good questions. I have two 500-page books on it, Extending DOS 2nd Ed., and DOS and Windows Protected Mode.
The key thing to understand is that DPMI is just an API. A number of smart people figured out that all these things were possible, and then they started bumping into each other. There were many programs that wanted to put the machine in protected mode: EMM386, 386MAX, QEMM386, DOS Extenders (286 or 386), Windows, etc. But only one gets to be in full control at a time. It was obvious that a standard was needed, and DPMI is that standard. (An earlier attempt was VCPI) A program can detect if somebody is already In Charge, if so, ask them to do protected mode things that you can’t do if you’re a mere real-mode program in a V86 task.
There are 16-bit (286) DPMI servers, and 32-bit DPMI servers. There are 16 and 32-bit clients. A 16-bit client can run on a 32-bit server, oftentimes getting the transparent benefits(finer grained paging, more RAM, faster real/protected switches, etc).
A DOS Extended program usually comes with its own DPMI Server built-in, so that it can get going if the system is actually in real mode. But most times, the system is in V86 mode at a DOS prompt (because EMM386 puts it there to emulate EMM), or you are in Windows or OS/2 2.x. If there is already a DPMI server loaded (like Windows 3.0), then that DOS app will ask Windows 3.0 to switch the VM into protected mode. Some complicated stuff happens, and Windows will convert the task/VM from being in V86 mode, to a regular 16 or 32-bit protected mode task. The DOS app is suddenly out of the pond, and in the ocean, but is still just an app. DPMI also manages how interrupts get handled, often by switching back to real mode (actually, V86 mode), etc.
Windows 3 apps can directly call the DPMI server like a DOS app would, however, they are supposed to use the Windows API. In Windows 2, there is no DPMI, so an extended DOS app probably won’t run on Windows/386.
In your example of 16-bit Windows apps on 80386, VMM would have switched the machine into protected mode during Windows startup. There would already be a 16-bit task/VM launched that loads the GUI components and your example app. When the app needs memory, it calls the Windows API, and those GUI components(KERNEL.EXE, here) would probably make a DPMI call to VMM for some memory, the 32-bit components would allocate it, map it into the 16-bit task/VM, and return the call with the pointer/handle to the memory.
32-bit apps on Win 3.x are easy at the VMM level, because VMM was always 32-bit on an 80386. The complicated part would be translating the 32-bit API calls to the 16-bit components running in the 16-bit task/VM. But Win32S did exactly that until Win95 shipped.
It is easy to get a 286 running in protected mode; the hard part is getting it back to real mode if you are going to support the DOS layer. Windows 3.0 added this as Standard mode. I don’t think Win 2.x used protected mode at all on 286.
Going back to EMM386 above(which puts the machine in protected mode with DOS in a V86), when Windows would start it would get all the memory info from EMM386, and then have EMM386 hand over control so that Windows would be in charge for the Windows session. If you exited Windows, the process would be reversed.
Jimmy Maher
July 23, 2018 at 7:46 am
Okay, thanks so much for your help with this. I think I’ve worked out where the line is between too much and insufficient depth for an article to come…
Tomber
July 23, 2018 at 3:07 pm
One point that might be useful: This discussion of 16-bit and 32-bit is often referring to the memory layout. 16-bit is typically using segments/selectors up to 64K, like a 286. 32-bit is typically using the 32-bit flat memory model. This is a separate thing from using 32-bit instructions. If you wanted to make a 386-optimized ZIP algorithm that uses the wider registers, you can do that in real-mode or any mode. Even the distinction between 16-bit or 32-bit protected mode tasks is a construct: In Borland Pascal 7, a 16-bit DPMI client for 286es, you could call the 32-bit DPMI server (obviously not the built-in), allocate a 1MB chunk of RAM, and then manipulate it with hand-inserted assembly instructions. If you tried to use Pascal instructions to access it, it would fail past 64K, but the point is the CPU doesn’t make any distinction.
Christopher Benz
July 24, 2018 at 2:04 pm
Jimmy, I’m finding this sequence of articles absolutely compelling, quite unexpectedly given I am neither a fan of Windows nor have I previously been all that interested in the history of its development. My assumption about Gates at the time was that he didn’t have an original bone in his body, that Windows was largely a rip of the Mac OS and that Gates’ key talent was playing corporate games (hedging his bets). Your chronicle here hasn’t shifted that point of view exactly but given it a more sophisticated context and like many, I’m much more sympathetic with the 2018 version of Gates. Following his journey in the 80’s and early 90’s with the various GUI’s in development in your writing, I now find myself strangely empathetic towards Gates predicament leading into the threat of a legal challenge from Apple at this stage in Windows development. I can see interesting arguments to made on both sides with respect to Apple’s claim of copyright infringement. No doubt without Xerox, the Mac OS wouldn’t exist, however, without the Mac, Windows wouldn’t be Windows. It’s… complicated. Either way, your histories here are extremely well told, and find a graceful balance between the technical and human stories. Look forward to more instalments.
Alex Freeman
July 24, 2018 at 9:49 pm
Yeah, those are basically my sentiments too.
“Excel looks more like a video game than a serious spreadsheet.”
Fun fact: Before my parents got me any video games, I had to content myself with playing around with the cursor in my dad’s copy of Lotus 1-2-3.
Jimmy Maher
July 25, 2018 at 8:30 am
Yes, Gates and his company were more complicated characters than many depictions might lead one to believe. They did plenty of dodgy things, especially during the height of their dominance in the 1990s, but weren’t without ideas or technical competence of their own. Gates’s certainty that the GUI was the necessary future of computing, and his determination to bring that to fruition in the face of setback after setback, counts as visionary in my book. And of course the amazing work he does today absolves him of all his earlier sins in my eyes. Even as a younger man, he refused to countenance the typical rich-guy antics, which he referred to derisively as “decadence.” There was much that was unpleasant about Gates at Microsoft — screaming tantrums, childish petulance, a naked *need* to win that could be thoroughly off-putting, etc. — but much that was admirable as well. I like to think that he’s grown fully into his better self in the years since. While I admire Steve Jobs’s achievements to an appropriate degree, I’ve come to admire Bill Gates as a person.
Richard Wells
July 25, 2018 at 12:29 am
Excel was not the only method Microsoft used to get a runtime Windows to users. There was also Microsoft Pageview which had its own weird history. When Wordperfect added page preview and graphics insertion abilities, MS extracted the page preview and graphic handling portions of the under development Word for Windows to create Pageview. Pageview was shipped free with a Windows runtime to every user of MS Word 4 for DOS. MS accompanied Pageview with a cheap upgrade coupon for the full Windows paired with PC Paintbrush for Windows.
MS had a free download of test versions of File Manager and Program Manager for Windows 2.x which were very similar to the Windows 3 versions. Unfortunately, Windows 2’s memory limits meant that running them left very little memory for applications.
Aula
July 25, 2018 at 9:27 am
I don’t get the point of “ran like a dog”. From the context, it’s apparently intended to mean “ran very slowly” but most dogs are actually pretty fast runners. Also “work like a dog” means “work really hard” so it seems to me that “like a dog” isn’t a simile you should use here.
Jimmy Maher
July 25, 2018 at 9:50 am
It’s a long-established English idiom, even if it doesn’t make complete logical sense: https://english.stackexchange.com/questions/235743/what-is-the-etymology-of-run-like-a-dog. Probably related to the tradition of equating “dog” with things of generally poor quality: a “dog’s breakfast,” “that car you bought is a real dog,” etc.
Aula
July 25, 2018 at 6:57 pm
Sorry, but I still don’t see how “run like a dog” is supposed to imply slowness. If a horse runs like a dog, it is galloping, which is the fastest gait of horses. Galloping is undesirable in horse-related sports, because it suggests that the rider or jockey has lost control of the horse, but it’s not slow. The link you gave is all about a car running like a dog, which means that the car is old and/or unmaintained, but even that rarely means it’s slow. If the engine is so worn out that it can’t produce as much torque at high RPM as it’s supposed to, then that can lower the technical maximum speed of the car, but most cars can’t be legally driven at anywhere near their maximum speed anyway, so a car that runs like a dog can be unreliable, uncomfortable, and possibly even unsafe, but (again) not slow.
Jimmy Maher
July 25, 2018 at 8:30 pm
Well, I’d suggest there’s a fine line between running slowly and running poorly in this case. ;) But, if you prefer: https://www.phrases.org.uk/bulletin_board/58/messages/1735.html.