Update: Since the original document disappeared, a local copy is now provided.
When researching the history of computing, from time to time an unexpected gem turns up. The copy of Ray Ozzie’s notes from a 1985 meeting with Microsoft is one of such gems.
Between 2006 and 2010, Ray Ozzie was the chief software architect at Microsoft, a role he took over from Bill Gates. But in the early 1980s, Ozzie worked at Lotus on the Symphony product, and in 1984 left Lotus to start a company called Iris Associates. Iris worked on a software project which (several years later) became known as Lotus Notes.
At the beginning of April 1985, Ray Ozzie (Iris) met with Microsoft in Bellevue, Washington (Microsoft moved to Redmond in early 1986). From the notes it is obvious that Iris had an unusual level of access; besides providing answers from managers and engineers, Microsoft also disclosed the bulk of its org chart as well as internal project scheduling data, including unannounced projects.
The org chart is interesting for the number of misspellings—it clearly had not been provided in written form (Neil Conzen instead of Konzen, Martin Dunsmere instead of Dunsmuir, Mark Zibokowski instead of Zbikowski).
The meeting took place at a very interesting time for Microsoft and the PC industry. Iris was attempting to take advantage of the latest Microsoft technologies, many of which were unreleased or just barely released. The barely released ones included DOS 3.1, Microsoft Networks, and the Microsoft C 3.0 compiler. The unreleased ones included Windows and DOS 4.0 (the infamous multitasking variety).
Included is a list of Microsoft Windows development goals, apparently a document created by Microsoft and summarizing the development objectives for Windows—such as fitting on a single bootable 360K floppy (including a subset of DOS 3.x), or performing well on a PC with 256K RAM.
The Q&A session between Iris and Microsoft forms the bulk of the meeting notes and is the most interesting part of the document. It’s obvious that Iris was using the early Windows development kits and running into numerous problems—with the compiler, with the development tools, with the SDK, and with Windows itself. Not particularly unexpected as Windows was still months from release at that point, if far behind the original schedule.
In the notes there are numerous references to DOS 4.0 or just “4.0” which clearly pertain to the multitasking MS-DOS 4.0. Microsoft was planning an integrated DOS 4.0 + Windows release in the first half of 1986. The product never materialized and the closest to it was OS/2 1.1 in late 1988. Section 5.2 of the notes mentions that DOS 4.0 should be released before the end of 1985.
There is a note that due to scheduling constraints, threads, named pipes, and swapping had been removed from DOS 4.0. Iris had been hoping to use threads, but that was not to be, or at least not in 1985.
An intriguing note can be found in section 5.6. Apparently Microsoft was planning to use the HMA (the first 64K of the second megabyte of the address space) for DOS 4.0. Microsoft was clearly aware of the possibilities, but DOS (the 3.x branch) did not utilize the HMA until the 1991 release of MS-DOS 5.0.
Just as interesting are mentions of DOS 5.0, meaning OS/2 (or Advanced DOS). Section 5.8 lists the planned features of DOS 5.0: protected mode, pipes, threads, asynchronous I/O, demand execution, installable file systems, sound services, >32MB file systems. With the exception of sound services, these features were all eventually implemented in OS/2, although it took until 1989 to add installable file systems.
At the time Microsoft claimed that no source changes would be needed to run an application in the integrated “Windows/5.0” environment. That turned to be far from true if one considers OS/2 with Presentation Manager to be an embodiment of “Windows on DOS 5.0”. Microsoft apparently did not provide any DOS 5.0 scheduling information to Iris.
In November 1985 there was a follow-up meeting between Iris and Microsoft. At that time, Windows 1.01 was finalized (released on November 20, 1985) but Iris was unhappy with its features and performance. There was talk of a Windows 1.1 release, but Iris was concerned it would be too late for their purposes. It’s not clear when Windows 1.1 (not 1.01!) was meant to be released (“6-9 months of development time”), but fairly clear that it didn’t happen. It is possible or even likely that Windows 2.0 is what “Windows 1.1” eventually turned into.
The Nov ’85 meeting notes are largely highly technical, but there are several items of general interest. For example, Iris asked for Windows to avoid “hooking into DOS” when running on top of DOS 4/5. Microsoft’s Steve Wood conceded that this might be useful. It is known that Windows 2.0 was able to run in the OS/2 1.x DOS box.
There’s also a mention of a Microsoft Networks redirector running on top of Xenix. Iris had received a demo version from Microsoft, although there were apparently some significant bugs. It appears that at that point, Microsoft’s interest in Xenix was waning.
All in all, this document is a fascinating window into the past. It’s all the more interesting for the fact that it contains a wealth of information that was only known to a handful of people at the time.
“Microsoft was planning an integrated DOS 4.0 + Windows release in the first half of 1986. The product never materialized and the closest to it was OS/2 1.1 in late 1988.”
And also ICL’s DOS 4.1/Windows 1.03 bundle:
http://web.archive.org/web/20070220193954/http://www.16bitos.com/410ms.htm
A bundle is not an integrated product, so I don’t see how that’s relevant. DOS 6.0 + Windows 3.1 (or whatever) bundles weren’t an integrated product either.
If there was no OS/2 it’d be strange to imagine a combined world of a multitasking dos+windows .. I wonder how Windows/386 would have fit into that world, as seemingly there was a string 32bit movement inside of Microsoft that seemingly got derailed with IBM’s big investment for OS/2 on the 80286…
Although IBM really did want something big to announce with their PS/2 line of computers that would be a compelling reason to buy one.. but that didn’t pan out so well for them.
I don’t think Windows/386 would have fit into that world very well, just like it didn’t fit very well into a world which included OS/2 (aka DOS 5). Then again, if EMM386 could bolt V86 mode onto of DOS, I don’t see why it couldn’t be done with 16-bit OS/2…
It’s clear that Microsoft had some form of multitasking DOS 4 going with Windows 1.0 back in 1985, but who knows how stable and finished the combo was.
The problem Microsoft had with IBM was that IBM never liked Windows much, and refused to push Windows (rumor has it that Dick Hanrahan was the #1 Windows hater at IBM). And when IBM didn’t care for integrated DOS+Windows or multitasking DOS 4.0, that pretty much killed those products. Which only goes to show how much Microsoft was beholden to IBM at the time (and why they tried to get out of that dependency so hard).
I’d say one of the biggest problems with the PS/2 machines was that they were too much, too soon. The technology was very good but too far ahead of its time. ISA was not yet at its limit, and few people needed the performance or ease of use (plug and play!). When PCI “rediscovered” much of the same technology years later, everyone loved it because people were already sick of slow and unstable adapters and configuration hell. In fact PCI may well be the best thing Intel ever did…
“And when IBM didn’t care for integrated DOS+Windows or multitasking DOS 4.0, that pretty much killed those products. ”
I think the real fault here is that the 80286 was introduced in *1982*.
“Then again, if EMM386 could bolt V86 mode onto of DOS, I don’t see why it couldn’t be done with 16-bit OS/2…”
Except DOS and 16-bit OS/2 are two completely different things.
And well, IBM tried to impose royalties on MCA, but in response EISA was developed which had most of the same features while being compatible with ISA.
dont forget about hpfs386 .. there is no fundamental reason why os2 1.x couldnt run multiple dos sessions much like windows/386 did.. If anything I’d imagine they would kill that idea as it’d be harder for the compelling upgrade to cruiser …
And yet EISA was an even bigger flop than MCA. EISA was simply a hedge by companies opposed to IBM, limited to more or less exotic server systems. When PCI showed up, EISA was the first to go.
Saying that DOS and OS/2 are different things is correct, but meaningless. Maybe you have some arguments why 16-bit OS/2 couldn’t support V86 mode, but being different from DOS isn’t one. Maybe there is some technical reason that would prevent it, but I can’t think of one. If you can, please explain…
There was at least one successful piece of software which merged a 16-bit protected mode core with V86 sessions. It was called Windows 3.x.
OK, I will explain. OS/2 1.x is a normal 286 protected mode operating system that used ring 0/2/3 to support memory protection and preemptive multitasking. DOS is a real mode operating system designed for 8086 processors. Windows 3.0 protected mode was created when David Weise realized that a DOS extender can be used to adapt Windows to protected mode. By then, Windows/386 already existed which ran multiple DOS VMs using virtual 8086 mode. To make the DOS extender interoperate with Windows/386, DPMI was created. This results in an architecture which is quite different from OS/2 1.x.
I was looking for technical reasons, so please try again. Why would it be impossible to have a 16-bit protected-mode OS which on a 386 system also supported V86 tasks? Such a system would certainly require some amount of 32-bit code; it would presumably require paging for the V86 tasks (although it might run 16-bit protected mode tasks without paging or with identity paging). Neither seems insurmountable to me.
There’s also nothing saying that such a system would have to support DPMI; it might work more like IGC’s VM/386. That would still be a vast improvement over the OS/2 1.x “penalty box”.
Looking at this quick note:
> ; useallmem = [yes|no]
> ; This parameter specifies whether the 386 HPFS should use memory above the
> ; 16M boundary, provided this system is configured with more than 16M.
> ; Some adapters, for example the IBM Token Ring Busmaster Server/A, cannot
> ; do direct memory access (DMA) to memory above the 16M boundary. If you
> ; have a LAN or disk adapter that cannot do DMA to memory above the 16M
> ; boundary, the 386 HPFS must use only memory below 16M so that the adapter
> ; can put data into the file system buffers. Set useallmem to yes if all
> ; of your adapters can access memory above the 16M boundary. Set useallmem
> ; to no if any of your LAN or disk adapters cannot access memory above the
> ; 16M boundary. If useallmem is not specified, the default setting is no.
If HPFS386 can do this on OS/2 1.x then I really don’t see any reason why you couldn’t enter v86 mode as an injected task (I mean MS did have the source to OS/2!) and give access to VMs much like Windows/386 .. I would imagine you could allocate display buffers/device status below the 16MB line, and let PM display/interact with the VMs, and otherwise let them run above 16MB… Or even just let them all run below 16mb.. HPFS386 accessing memory above 16mb pretty much says that the driver shifted from 16bitPM to 32bitPM. I wouldn’t expect any DPMI / VCPI .. if anything it’d be like running Windows/386 …. But still I guess if OS/2 1.2 could do that, who’d want 2.0?
Mind you, the > 16MB support would be hardly necessary. We’re talking ~1989 or earlier here, back then no one had 16MB. A 4MB machine was a big system. Heck, OS/2 1.0 won’t even boot (will crash) if you give it 16MB! That to me very strongly suggests that in 1987, even Microsoft didn’t have 16MB systems.
I too would envision something like Windows/386, or possibly VM/386. No fancy stuff like DPMI, just good old DOS, maybe with EMS emulation. Windowing would have been great, but then again even OS/2 1.0 could have been a nice task switcher for full-screen VDMs.
As to who would want 2.0… in 1989, not many. But in the early 1990s, 32-bit software was getting more and more popular as more people had 386s. And for developers, flat model programming with “unlimited” address space was just too irresistible (segmentation actually isn’t a bad idea, but 16-bit segments suck).
Oh, and re DPMI/VCPI – it’s important to note that if Microsoft and IBM hadn’t failed to establish OS/2 as a mass-market DOS replacement, no one would have cared about DPMI/VCPI. The whole DOS extender thing was a kludge, nobody really wanted those things, but the market reality was that everyone was running DOS and folks wanted >1MB RAM. There was demand, so supply naturally materialized 🙂
what is more surprising to me is that PharLap charged so much to developers instead of trying to sell a “windows” like protected mode dos environment themselves…
They would have sold a lot more seats partnering with devs, instead of showing how cool their extenders were then how insanely expensive they were per product…. oh well.
Balmer was right, its all about developers… which makes me wonder why they are going to pull C++ from the lite downloads..
Oh yeah, and the fact that there was only a SINGLE dos box was insane.. windows could swap it out of the way in real/standard and launch new memory spaces, its not like the dos mode executed while in protected mode.. its like they wanted OS/2 1.x to be as.. much of a lame duck as possible.
not to mention just how barren 1.x was… well at least they figured that out for 2.00 ..
I think the problem with OS/2 1.0 was that a) Microsoft started working on it back in 1985, if not earlier, and b) they completely misjudged the importance of DOS. It may be that they really did intentionally make it somewhat hard to run DOS apps to “incentivize” folks to run OS/2 instead, but that backfired. Remember that Microsoft’s recommended solution was the Family API, which had its own issues…
michaln: Then of course the MS OS/2 2.0 fiasco led DOS extenders to last for longer than it should have.
Certainly. Had OS/2 2.0 been released in 1989-1990 as originally planned, it might have (might have) staved off the need for DOS extenders before they became truly mainstream. But OS/2 2.0 was late and problematic, and NT 3.1 wasn’t any better. Windows 95 was really what eliminated the need for DOS extenders (including for games) and that took a long, long time.
One of the last major DOS extended applications was id Software’s Quake – released in mid-1996, nearly 10 years after the arrival of the first 386 PC!
BTW, I wonder why they didn’t do a 16-bit EISA with features from 16-bit MCA like level-triggered sharable interrupts. And yea, on the desktop, VLB ended up being much more popular.
I suspect that EISA was mostly a hedge. It was more about preventing IBM from gaining the upper hand than actual technological progress. EISA also had to fight the same problem as MCA, which was that not nearly everyone needed the extra performance – not yet.
I’ve never seen a desktop machine with EISA slots, and even EISA servers weren’t widespread. From my own experience, MCA was far more successful.
IBM’s biggest mistake may have been removing ISA completely – not every device benefited from it. I regularly used ISA-based sound cards and modems in the late 1990s and there was nothing wrong with them from a performance or reliability perspective (or cost perspective, for that matter!). For graphics and storage, and soon networking, ISA had no chance, but there were lots of other devices where the ISA performance was entirely adequate.
The biggest advantage MCA/EISA arguably had over ISA for the “simple” devices was configurability, but it’s questionable whether that was worth the higher price to the typical user.
Ive only seen two machines with EISA at end users homes.. one was running MS-DOS + windows (lol) although he later switched to NT 3.1 … The other machine had EISA slots, but the board itself had no support for EISA so it was more like a dummy slot ..
I’ve only worked in one place with PS/2 servers, and they were being rapidly phased out by Compaq gear.. It was the move from CCMail on OS/2 to Lotus Notes on NT .. But all the thousands of customer service people were running OS/2 2.1 .. fun times.
“which makes me wonder why they are going to pull C++ from the lite downloads..”
MS never was planning to do this.
Someone better tell ms
http://arstechnica.com/information-technology/2012/05/no-cost-desktop-software-development-is-dead-on-windows-8/
There won’t be any c ++ in the next vs express
No desktop software development don’t mean no C++.
Ok, every tech source says no c++ in the express editions so unless you’ve got something to back that there will be C++ I’ll be interested to hear.
From http://msdn.microsoft.com/en-us/windows/apps/hh852659.aspx :
“You can use the tools in Visual Studio 2012 Express RC for Windows 8 to create Metro style apps for Windows 8. The tools include a fully featured code editor, a powerful debugger, a focused profiler, and rich language support that you can use to build apps written in HTML5, JavaScript, C++, C# or Visual Basic.”
> One of the last major DOS extended applications was id Software’s
> Quake – released in mid-1996, nearly 10 years after the arrival of
> the first 386 PC!
id Software was apparently very trendy and changed compilers and technology at the drop of a hat. Wolf3D -> Doom -> Quake -> Quake 2, etc. etc. all used different compilers and heavily increased cpu requirements. (Actually, didn’t Duke Nukem 3D come out in 1996? That was Watcom-compiled for DOS.) Yeah, we all know that DOS games eventually stopped being commercially developed in the late ’90s. I don’t honestly know why, the tech was still there. It wasn’t until XP (NT)’s crappy NTVDM (though loads better than Vista) that people were abandoning DJGPP and DOS stuff because it simply wouldn’t work well anymore, if at all. So at least then there was a technical reason. (NT 4.0 didn’t even support LFNs for DOS stuff, ugh, only added in 2k.) But DJGPP was previously very popular before all that throughout the ’90s (v2 introduced in 1996 had loads of GNU POSIX tools, exclusively used DPMI, transparent libc Win9x LFN support, etc).
Anyways, the only reason id Software used DJGPP was because a). they started in 1994, b). they wanted to cross compile (from quad-core Alphas??), c). they wanted to ship the compiler itself with linkable objects so that modders could have fun (but eventually opted for wimpy hand-written QuakeC instead). This all started before Win95 was out, and IIRC, Quake only shipped in late 1996 (after 18 months). Win95’s DPMI was buggy and had to be worked around (esp. trying to get Quake working in 16 MB under Win95, thanks to CWS of CWSDPMI). Not to mention NT bugs re: nearptrs that MS refused to fix because “NT isn’t for games”, which is why it still won’t work there. And top that off with Carmack’s insistence to drop DOS for Quake 2 because of lack of decent .DLL or networking support, among other reasons. So yeah, later on, it became more popular to use Win95/NT natively because of drivers and less bugs, e.g. Quake-based Hexen 2 was Win95 only (although H2 was recently [2008?] ported via hackers to many other OSes, including back to DOS/DJGPP).
Wolfenstein 3D was built with good old Turbo C on a PC. It’s known that DOOM was developed on a NeXT machine where gcc was the system compiler. At that point (late ’92/early ’93?), DJGPP probably wasn’t quite there. I couldn’t find any information about what platform Quake was developed on, but it’s know that id was a somewhat early NT adopter. But yes, id had a lot of money and they liked shiny toys (hence NeXT).
In the late 1990, the DOS game tech was unquestionably there. However, any game company with a marketing department had a bunch of people who insisted on Windows 9x support because it was “cool”. Never mind you needed twice as much RAM for less performance. Once it got to 3D, it really wasn’t much of a contest, but until then, DOS was arguably the better platform.
I agree that NT was about the worst platform for extended DOS and DOS games. OS/2 was a much better platform, but with less support from ISVs.
And yes, Duke Nukem 3D was one of the very very long list of games developed with Watcom C/C++.
Quake was developed on NeXTSTEP (though not on NeXT hardware). It wasn’t until 1996 that id moved to NT.
Not that I disbelieve it, but do you have any source for that?
Romero’s blog: http://rome.ro/2006/12/apple-next-merger-birthday.html
Carmack’s .plan: http://www.team5150.com/~andrew/carmack/johnc_plan_1996.html
Thanks! You’d think this would be worth mentioning on the Wikipedia entry for Quake, but no…
Unfortunately the document link is gone..
Indeed it is. The link now points to a local copy of the original document…
Notice the EGA write only register problem was already mentioned. I think MS was already working on multitasking DOS 4.0 when IBM designed the EGA, right?
Doom was 100% done with Watcom for the DOS release.
I don’t think anyone disputes that. I believe Watcom C/C++32 version 9.5 was used for the DOS version of DOOM.