Microsoft OS/2 2.0 SDK Pre-Release 2, June 1990
In 1990, the strategic PC operating system of Microsoft and IBM was not DOS, not Windows, but OS/2. The first 16-bit OS/2 was initially released in 1987 with a reduced feature set, but by the end of 1989, OS/2 1.2 completed two major features: The Presentation Manager GUI (first seen in OS/2 1.1) and installable file systems, notably the new HPFS file system.
Since before the initial release, Microsoft talked about a 386 specific version of OS/2, with support for a 32-bit, flat model API, and much improved DOS support utilizing the 386’s virtual 8086 (V86) mode.
In 1987, 386-based PCs were few and far between; IBM wanted an operating system better than DOS then, rather than years in the future, and Microsoft had been working on “Advanced DOS”, still 16-bit but utilizing the 286’s protected mode, for several years. The result was OS/2 1.x.
By 1990, the number of 386 and brand-new 486 systems had been gradually increasing. 386-specific software, such as memory managers (“LIMulators”) and DOS multitaskers (including Microsoft’s own Windows/386), was becoming more popular.
Just before the end of 1989, Microsoft made available the first pre-release version of the long promised 32-bit OS/2 2.0, which was intended to be the first mass-market 32-bit PC operating system. This was accompanied by a press release detailing the $2,600 OS/2 2.0 Software Development Kit (SDK).
Unfortunately, the December 1989 pre-release of OS/2 2.0 may not have survived to the present day. But in June 1990, Microsoft shipped the second pre-release of the OS/2 2.0 SDK. And that version has now turned up, after twenty years of searching, and almost 34 years after its release!
The SDK specimen was in original unopened box, with printed documentation and everything.
Here’s what the June 1990 pre-release of OS/2 2.0, also known as build 6.78, looked like when installed:
It looked awfully similar to its 16-bit contemporary, OS/2 1.2. The big tell was the lack of the DOS icon in the lower left corner (the one and only limited DOS box in OS/2 1.x, also known as “DOS coffin”), and more importantly, the addition of DOS Window and DOS Full Screen icons in the Main group.
To put the OS/2 2.0 pre-release in perspective, it came out almost simultaneously with Windows 3.0, a year before DOS 5.0, almost two years before the release of OS/2 2.0, and over three years before Windows NT 3.1.
Hybrid OS
The mid-1990 OS/2 2.0 pre-release was very much a hybrid operating system. Device drivers were 16-bit, the Presentation Manager GUI was 16-bit, most utility programs were 16-bit. But the kernel included a new 32-bit memory manager with paging support, support for 32-bit applications, and notably the MVDM subsystem—Multiple Virtual DOS Machine support.
While hybrid systems are often considered impure, they tend to be the result of sound engineering practices. Why bother writing all new 32-bit code when the existing 16-bit code will do just fine? Reusing large swathes of OS/2 1.2 code no doubt accelerated the development of OS/2 2.0 by many months, if not years.
One of the major objectives of OS/2 2.0 was to run existing 16-bit OS/2 1.x applications. Starting out with much of “userland” code being 16-bit was a logical step. Similarly supporting 16-bit device drivers allowed existing drivers to be used with minimal changes, rather than rewriting everything from scratch.
That said, the OS/2 2.0 designers probably didn’t imagine that quite so much 16-bit code would survive in OS/2 until the end.
Bugs and Incompatibilities
After installing OS/2 build 6.78 (which went smoothly as such), I quickly discovered that DOS boxes just won’t work. Any attempt to start a DOS session would crash, or at best get stuck with a blank screen:
To the credit of OS/2 2.0, the DOS session crashing and burning had no discernible impact on the stability of the system. A major improvement over OS/2 1.x.
After staring at instruction traces for a little while, I found the rather unexpected cause. In the DOSKRNL file (the DOS 4.0 kernel running inside OS/2 DOS boxes), Microsoft tried to be clever and used an invalid instruction as a fast path to access protected mode services. But there was a fatal problem: Microsoft used the 0F 7F opcode, which is not undefined on Pentium MMX and later — it is the MOVQ instruction. For that reason, launching DOS boxes in build 6.78 fails miserably on Pentium MMX and later Intel processors (except perhaps on the Pentium Pro).
Rather interestingly, OS/2 2.0 pre-release build 6.123, which is only a few months newer, does not suffer from this problem. It uses the HLT instruction instead, which always causes a #GP fault in V86 mode, and works fine on modern CPUs. It is a bit of a mystery what motivated Microsoft to change the mechanism, since MMX processors were years away.
I also found myself unable to install the LAN Manager networking components:
The error message is frustratingly vague. After spending some quality time with a disassembler, I found the cause — which was again quite unexpected. The LAN Manager setup fails because it finds NETAPI.DLL to be loaded.
For reasons that are completely unclear, Microsoft shipped NETAPI.DLL on the LAN Manager disks, but also shipped a different NETAPI.DLL as part of the base OS, and the print spooler loads NETAPI.DLL if it finds it (and there’s no obvious way to quit the print spooler). That upsets the networking setup because it thinks LAN Manager (or some other networking software) must be already installed.
The workaround was easy, boot OS/2 6.78 from the installation floppies (or from an OS/2 1.2/1.3 install floppy), rename NETAPI.DLL in the \OS2\DLL directory, reboot. The print spooler simply doesn’t use NETAPI.DLL when it doesn’t find it, and the LAN Manager setup works. How Microsoft managed to ship the pre-release like this is a bit of a puzzle — perhaps some last minute packaging change.
Networking
The OS/2 2.0 SDK came with four disks of networking support. This turns out to be a pre-release version of LAN Manager 2.0 (the SDK came out in June, LAN Manager 2.0 in around November 1990). According to contemporary reports, the networking support was new in the June 1990 SDK; the first OS/2 2.0 SDK from December 1989 did not include networking, quite possibly because LAN Manager 2.0 was not far along enough.
The setup program offers installing a LAN Manager server, or a workstation with the Peer service (which is also a server), but as far as I can tell there are no server components on the disks. There is also no text mode based user interface that would normally be launched using the NET command.
Since it’s based on LAN Manager 2.0, the network stack only comes with the NetBEUI transport (aside from perhaps some exotic XNS transports). There’s no NetBIOS over TCP/IP, and therefore no way to talk to modern servers.
But the pre-release networking code can talk to a LAN Manager 2.0 server and use file sharing. Fun times! It is a shame that IBM did not include networking in the OS/2 2.0 release.
For testing I used the 3Com EtherLink II emulation in VirtualBox:
The OS/2 2.0 pre-release has no trouble seeing a LAN Manager 2.0 server (running on top of OS/2 1.2) running in another VM:
It is likewise no problem to use a network drive and access remote files:
All in all, the OS/2 2.0 pre-release, somewhat surprisingly, came with a pre-release, stripped down, but functional network client. This would have greatly eased software development, because files could be easily copied over a network.
As a side note, it is not possible to install the released LAN Manager 2.0 or 2.1 client on OS/2 6.78. That is, the installer runs, but the system just crashes afterwards—not too surprisingly, given how tightly the network redirector was integrated into the operating system.
Development
A major part of the OS/2 2.0 SDK was obviously the development kit. This included a pre-release version of Microsoft’s 32-bit C compiler, Microsoft Macro Assembler (MASM) with 32-bit support, as well as headers, libraries, and sample code. Plus of course electronic and printed documentation. The printed documentation was new in the June 1990 SDK; the first release came with electronic documentation only.
The development kit was bigger than the OS itself, with 6 compiler disks and 5 toolkit disks versus 10 disks for the operating system itself.
The CL386 compiler is essentially the same compiler that was used for x86-based NT development. Microsoft had had a compiler producing 32-bit code for the 386 processor since circa 1986, and used it to develop 386 XENIX; SCO shipped said compiler for a number of years. The CL386 compiler was the variant of the compiler for DOS-like systems. It eventually turned into the 32-bit Microsoft Visual C++ compiler, but users had to wait until 1993 before they could buy it.
Of course the lucky few who purchased the Microsoft OS/2 2.0 SDK could enjoy writing 32-bit applications several years earlier, in 1990! The SDK came with numerous sample programs and fairly extensive documentation.
Electronic documentation came in two different formats. OS/2 programming information and especially Presentation Manager programming documentation came in the native OS/2 help format:
Documentation for the compiler and assembler, as well the OS/2 API, was in QuickHelp format:
There was significant overlap and much of the documentation was available in both formats, yet other pieces were only available in one or the other format. It appears that the Languages group at Microsoft preferred QuickHelp, but the Systems group and IBM preferred the OS/2 help format.
32-bit Flat Model
The OS/2 2.0 SDK introduced a 32-bit flat programming model that became standard in the 1990s. No more 64-kilobyte segments, no more near and far pointers.
OS/2 2.0 fully utilized the paging capability of the 386 processor. Virtual memory based on swapping uniform 4 KB pages was easier to implement than swapping variable-size segments, as was the case with OS/2 1.x.
The SDK came with a nifty example demonstrating the virtual memory in OS/2 2.0:
The 32-bit programming model was quite different from what DOS and OS/2 1.x programmers were used to, but it was simple. For the most part, paging was entirely transparent and programmers didn’t have to worry about it.
Just as importantly, the flat memory model made porting from other platforms much easier, because it was similar to the programming model used by 32-bit UNIX platforms.
DOS Boxes
The DOS support in OS/2 6.78 seems fairly functional and complete. The user interface for setting DOS properties looked quite different from the released OS/2 2.0, but the actual settings look familiar:
The big news was of course the ability to run DOS in a window:
Needless to say, OS/2 6.78 was quite capable of running multiple DOS boxes at the same time, in a mix of windowed and full-screen sessions. That was something OS/2 1.x could only dream of.
It is highly likely that Microsoft leveraged experience with Windows/386 when designing the OS/2 MVDM subsystem, although the actual implementation was quite different and probably didn’t share much if any code.
Although there perhaps wasn’t much point in it, the development tools shipped with the SDK could be run in a DOS box:
The 32-bit executable the SDK produced of course did not run under DOS.
Judging from contemporary press reports, the DOS support in the OS/2 2.0 SDK worked reasonably well even in the first December 1989 release. The June ’90 release was no doubt even better.
What If
The 6.78 build of OS/2 2.0 feels surprisingly stable and complete. The cover letter that came with the SDK stressed that Microsoft developers had been using the OS/2 pre-release for day-to-day work.
The minimalist, hybrid approach allowed Microsoft and IBM to leverage an existing functional and stable operating system (OS/2 1.2) and extend it with major new functionality (32-bit applications, DOS boxes).
After seeing how far along OS/2 2.0 was in June 1990, it sounds very credible that the Microsoft/IBM split delayed the release of OS/2 2.0 by at least a year.
If Microsoft and IBM released 32-bit capable OS/2 with good DOS compatibility sometime in late 1990 or early 1991, it would have quite likely prevented Windows 9x from happening, and instead of Windows NT we’d be running NT OS/2, according to the original plan. But that future never happened.
I knew you would crack the mystery preventing networking from running!
“To put the OS/2 2.0 pre-release in perspective, it came out almost simultaneously with Windows 3.0, a year before DOS 5.0, almost two years before the release of OS/2 2.0, and over three years before Windows NT 3.0.”
Did you mean NT 3.1?
Interestingly this was also around when PX00307 was written.
Interestingly you can see yet another reason why OS/2 1.0 targeted the 286. OS/2 2.0 is a more complex project than 1.0.
Cool find!
“OS/2 2.0 fully utilized the paging capability of the 386 processor. Virtual memory based on swapping uniform 4 KB pages was easier to implement than ” <– this seems to be missing some words.
"Although there perhaps wasn’t much point in it, the development tools shipped with the SDK could be run in a DOS box" – given how expensive a 386 would had been, it's not unlikely that a set of multiple developers wouldn't had had their own 386 computers, but perhaps rather write code and run the compiler on older 286 or 8088 computers and then tested out the compiled code on the 386 system.
A side track that I probably have been bringing up too many times already, is that there were a patch for Samba to give it NetBEUI capabilities. Unfortunately that patch was never merged to the main Samba source code and afaik also never updated to work with newer versions of Samba and whatnot, and everyone just recommended potential users to switch to another client rather than patch Samba. Given that the potential target for Samba with NetBEUI in 2024 would be vintage computing, to me it seems reasonable to get that patch going again. At least make the patch compile with any version of Samba even if it's a 20-25 year old version would be a good thing, I think.
Also re networking, I wounder how many of the SDK users would had had access to a compatible network?
Another side track is that I wonder if it really was a good idea to charge that much for the SDK, even back then? My impression is that although it probably didn't have much effect on larger software packages, it most likely hindered the development of all sorts of cool smaller utilities, and also fostered a culture where even the simplest small tool would be shareware where the developer would want you to pay $5 for for example a tool that would do CR/LF conversion on text files, or something similarly simple.
Another side track that would be hard to delve in to, but the result would be interesting, would be to find out approximately what percentage of shareware authors also were professional developers for more or less the same target platform as their shareware? I.E. someone working for a big company making a CR/LF converter in their spare time using their work computer, with permission from the company, rather than just being a hobbyist. I assume that most shareware authors on for example the Simtel archive and whatnot would be hard to reach today if they are even with us, but for some of them the names would likely be so unique that it's easy to make a qualified guess that they are the same person that is known to have worked for certain companies and whatnot, and by doing that find some approximate data. Like it isn't an actual research paper and thus the data quality doesn't have to be super great; it would just be nice to get a feel of who the shareware authors were, statistically speaking.
Maybe computing history is considered an actual research topic that people can get grants for to delve in to?
As I'm anyway straying more and more off topic, I might also bring up the possible research topic on what impact APIs, examples, cultures and whatnot related to certain operating systems had on the types of shareware/freeware/open source and for that sake software in general that was written. I.E. an API making certain utilities easy to write might have encouraged them, while a SDK with hard to understand documentation might have discouraged certain developments.
@MiaM: “given how expensive a 386 would had been, it’s not unlikely that a set of multiple developers wouldn’t had had their own 386 computers, but perhaps rather write code and run the compiler on older 286 or 8088 computers and then tested out the compiled code on the 386 system.”
In 1990 386 was not THAT expensive anymore, plus 386SX already existed, if I remember correctly. Plus, the toolchain’s ability to run in a DOS box doesn’t mean that it will run in pure DOS or OS/2 1.x, or that it will run on a 286. The author will have to conduct some tests and tell us 🙂
@Yuhong Bao: “Interestingly you can see yet another reason why OS/2 1.0 targeted the 286. OS/2 2.0 is a more complex project than 1.0.”
IMHO, there is no need to make things more complex if they are actually simple. Microsoft wanted to target 386 with OS/2 since the beginning, because they liked 386 much more than the “brain-damaged” 286, there were actual problems with 286 that 386 fixed, and they didn’t want to be burdened for years with backward compatibility issues stemming from an initial release crippled by supporting an inferior CPU. OTOH, IBM wanted to target 286 because they wanted their 286-based PS/2 systems supported. IBM were the stronger player in the duo, and logically they prevailed. Systems get more complex all the time, so the greater complexity of OS/2 2.0 is not a convincing argument.
@Yuhong Bao: “Interestingly this was also around when PX00307 was written.”
Microsoft knew they were angering IBM with their Windows 3.0; and they also knew that their collaboration with IBM was not to last long. They needed a contingency plan.
“I quickly discovered that DOS boxes just won’t work.”
“The DOS support in OS/2 6.78 seems fairly functional and complete. ”
How did you solve the problem? Can VirtualBox mimic a pre-Pentium MMX CPU in a modern system?
I was really hoping that you and the buyer of this might manage to connect, and I’m so happy to see that you did!
2nd paragraph under “32-bit Flat Model” appears to be incomplete.
Understandably, you spend a great deal of time on the extras outside of the core OS that were shipped in the SDK box, like the SDK toolchain itself & the pre-release LAN Manager (very cool). But I would be interested to hear if you noticed many differences in the actual OS between this 6.78 and the 6.123 that came after it. You mentioned the use of HLT. I can notice a couple of subtle graphical differences (more white dialog boxes vs. gray in later versions). What else?
As far as what might have been, I have a feeling that if MS and IBM hadn’t severed the JDA when they did, not only would a 2.0 GA have shipped to the public much earlier, I’m almost positive it would not have come with Workplace Shell. WPS feels extremely IBM-y and very NOT Microsoft-y. Whether they would have kept Desktop Manager as the shell, or come up with something different (ported Win3 Program Manager over?)…unclear. From what we know of the acrimony between the two companies (e.g., some of the completely unnecessary API differences insisted on by IBM, if rumors are accurate), IBM probably would not have been a fan of moving in the direction of having OS/2 look and feel even more like Win3. I also can’t imagine that Microsoft would have just accepted a brand-new shell developed wholly in-house by IBM that seemingly came out of nowhere. So even if both companies had managed to tough it out for a little longer, I have to imagine that differences in vision for the front-facing user experience would have proven to be a not-so-minor point of contention and so would have ended up straining the relationship just as much as (if not more so) it had been strained (albeit for different reasons) in actual history, perhaps *still* ultimately leading to their break-up even prior to a finished 2.0 commercial release. Or maybe they would have just tabled that discussion until right after shipping 2.0, shipping it with a largely-unchanged GUI, and then broken up immediately after that when disagreeing about what to replace it with.
I think I’ve said this before in other contexts, but I’m honestly shocked that 2.0 ended up being “only” about a year late. After losing the knowledge of and experience with the codebase that the Microsoft programmers undoubtedly brought to the table (not to mention the whole development ecosystem they had been building up around it this whole time), I could easily see it taking at least that long for IBM to get back up to speed, pick up the broken pieces, and get something shipped. But not only did they do that, they wrote an entire replacement shell, and I can’t imagine that the WPS was simple to develop! Since it wasn’t even on the roadmap at the point of the “divorce”, with it being started (as far as we know) from scratch that late in the game, I could easily see *just* the WPS project itself adding a whole additional year to development!
Yes. Not sure how I missed that, thanks.
You’re perhaps forgetting that in 1986, Microsoft already had a large part of OS/2 (or “Advanced DOS” or CP/DOS or whatever it was called) written. Some of the technology (like the segmented executable format) goes back to Multitasking DOS 4.0, circa 1983.
Yes, it’s possible to emulate a 386. It’s not at all fast, but it’s still faster than a real 386.
IBM also had to pull a 386 compiler out of their hat. I think you’re right that when everything is taken into consideration, OS/2 2.0 shipped on a surprisingly rapid schedule.
As it often is, the delay itself caused further delays. For example, in mid to late 1990, Windows 3.x compatibility would not have been a requirement. In 1992 it was.
Whether Microsoft and IBM could have worked together is an open question, but I suspect they could not have. Simply because Microsoft decided that just because they grew into a giant company primarily thanks to IBM didn’t in any way mean that they needed to stay loyal to IBM.
OS/2 6.123 looks visually different from 6.78 but at least my impression is that technically it wasn’t very different at all. The released OS/2 2.0 was quite different from 6.78, but the changes were relatively last minute. WPS came in late 1991, the new storage drivers weren’t even in the late ’91 OS/2 2.0 LA, Win-OS/2 was also a fairly late addition.
I would say that roughly from mid-1990 to mid-1991 there were not many changes at all, and that would have coincided with IBM taking over the development. Then starting in Fall ’91, big new features started getting added quickly.
“The 6.78 build of OS/2 2.0 feels surprisingly stable and complete. The cover letter that came with the SDK stressed that Microsoft developers had been using the OS/2 pre-release for day-to-day work.”
Which begs the question, why was 2.0 LA so unstable? Because, at least in my experience it is. Is it all the other stuff added between this build and GA?
OS/2 2.0 being delivered much earlier would definitely have helped it achieve wider acceptance back in the day.
However, I still can’t see it taking a lead over DOS and Windows. In many areas, 1-2 MiB 286s were common well into the 1990s. Windows 3.0 and its early applications could run fine in such a limited environment. Even OS/2 1.x, which required 3 MiB to run in an acceptable way on a 286, was out of scope. “Early” OS/2 2.0 with no WPS, which would require a 386 with at least 4 MiB of memory, would still face difficult competition from Windows 3.x for some time.
And in terms of the Workplace Shell, for me it was a very distinctive feature of OS/2 2.x. I absolutely loved it. And the more I read about it, the more unrealised potential I can see in it. When I switched to Windows 95 (because it ran acceptably with 4 MiB RAM, unlike OS/2 2.1), I immediately recognised several features of WPS “copied” into Windows 95, sometimes in a crude way. And I really hoped for a more refined, object-oriented interface in subsequent releases of Windows. Oh, I was in for a disappointment…
IBM had no use for a 32-bit OS for a long time because they offered few machines that could use one. The Model 80 was capped at 8 MB which was constrictive with OS/2 2.0. Most of the 1989 refresh were also capped at 8 MB unless one went all the way to the Model 90 (or the 95 in late 1990). IBM didn’t offer a wide range of systems that made sense with OS/2 2.0 until 1992. IBM would have preferred to slow the rate of increase of drive capacity and memory even further if Compaq hadn’t been taking over the market.
MS would have stayed partnered with IBM if IBM hadn’t insisted on Windows 3 not shipping. IBM could have survived on mainframe revenue while the bulk of 1990 was used to fix up OS/2 1.3 and then spending 1991 incorporating all the IBM wide unification that led to WPS. MS wasn’t sharing in that mainframe revenue so they needed to sell something else.
Hard to say without details. But the WPS was very new in 2.0 LA, and it’s very unlikely that it added to the system’s stability.
My experience from other projects is that if new programmers take over an existing code base, they’re quite likely to inadvertently break a thing or two before they learn how everything fits together.
On the other hand the 386SX was limited at 16 MB anyway.
@Michal Necasek: And porting this stuff to the 286 was fairly easy, unlike writing a 386 OS which would have been much more work.
Which also reminds me of this story: https://groups.google.com/g/comp.os.os2.advocacy/c/Z3pFyFanRn8/m/QadNvLspaiMJ
“Quarter century”? Knock knock! 🙂
“IBM also had to pull a 386 compiler out of their hat.”
Well, yes and no. It would actually not surprise me to learn that huge chunks of OS/2 2.0 still were built with & continued to depend on Microsoft 32-bit C (and perhaps even x86 assembler, for kernel-y bits) toolchains, even in the final shipping version. Who knows at what point they finally excised Microsoft compilers and assemblers as a dependency for OS/2 codebase…2.1? Warp? Maybe never? There’s certainly no reason that they would have needed to immediately pivot to their own compiler for building OS/2 itself, before shipping it. I also wonder if perhaps MS C was somehow covered by the terms of the JDA (since 16-bit IBM C/2 was apparently just rebranded MS C). (On the other hand, since MS would have had no incentive to polish up a final shipping version of CL386 & friends with full 32-bit OS/2 target support, nor support it for very long afterward even if they did, there was obviously a need for IBM to get something out to OS/2 app developers that they could use.)
It also wouldn’t surprise me to learn that parts of OS/2 continued to rely on MS C while others used something else. The build process for the entire OS was likely extremely complex and heterogeneous in nature. I have to believe, for example, that WPS was probably built with C Set from the get-go, even if other major components of OS/2 were not.
“[…] in mid to late 1990, Windows 3.x compatibility would not have been a requirement. In 1992 it was.”
Oooh, good point about Win-OS/2 also not originally being on the 2.0 roadmap, either. Another non-simple engineering problem!
“[…] the changes were relatively last minute. WPS came in late 1991, the new storage drivers weren’t even in the late ’91 OS/2 2.0 LA, Win-OS/2 was also a fairly late addition. I would say that roughly from mid-1990 to mid-1991 there were not many changes at all, and that would have coincided with IBM taking over the development. Then starting in Fall ’91, big new features started getting added quickly.”
Well, sure, but surely you mean that big new features started getting added quickly to versions being distributed *outside of IBM*. It’s not like they whipped up WPS or Win-OS/2 inside of a month, near the latter half of 1991, and then it just dropped out of nowhere like a miracle. I have to believe the decision to pursue those features was made many months prior, maybe even right on the heels of the MS divorce, and it took a *lot* of work after that decision had been made to get those features to the point where they could even make an appearance in a beta. In the meantime, you keep shipping betas without those features to developers so that they continue to have a platform that they can test their new 32-bit PM apps on.
Re compiler – absolutely yes. Sure, internally IBM kept using CL386 for certain bits of pieces (primarily MVDM I believe) because of inertia. But they couldn’t ship CL386 to developers, and they couldn’t tell developers “hey ask Microsoft for a compiler they won’t sell you”. So IBM had to come up with their own compiler that they could actually sell to developers, and they did — CSet/2.
So, yes, I believe IBM did in fact keep using CL386 until the end for some parts of OS/2 (and were even able to provide it as part of the OS/2 DDK), but that was irrelevant because IBM needed something external OS/2 developers could actually use. And those developers didn’t care at all what compiler IBM used internally. That’s aside from C++ support, which IBM was never going to get from Microsoft.
Re WPS, yes, certainly the development must have started some time before it first showed up. When exactly… that’s an interesting question. And I don’t know the answer.
“But they couldn’t ship CL386 to developers, and they couldn’t tell developers “hey ask Microsoft for a compiler they won’t sell you”. So IBM had to come up with their own compiler that they could actually sell to developers, and they did — CSet/2.”
My memory is getting fuzzy, but IMHO OS/2 Warp 3.0 contained some development tool from Microsoft – maybe an assembler, or a C compiler, or possibly a linker for 32-bit OS/2, complete with the Microsoft copyright and everything. If IBM could still distribute to the end users such a tool in 1994, then why could they not distribute the full toolchain to the developers?
vbdasc:
You’re thinking of LINK386, the linker. It’s not so unusual for older PC operating systems to include a linker that can assemble compiled object code into the right executable format for that platform; MS-DOS used to ship with LINK.EXE prior to version 5, for example.
Your question about distributing the full MS toolchain goes back to similar questions I raised in my last post. The linker included with 32-bit OS/2 does indeed bear dual IBM/Microsoft copyright statements, which does imply that IBM had access to at least SOME source code for MS build tools. Whether they had full access or not, not clear. My thinking is that, even if they did have full access, and even if the terms of the Joint Developer Agreement would have given them the right to redistribute it themselves, the Microsoft compiler not only had not left beta before the dissolution of the partnership, but was effectively a dead-end at that point as far as development on the OS/2 platform goes. Perhaps IBM could have decided to build on top of MS’s work, but it probably made more sense to just begin afresh rather than try to maintain somebody else’s code indefinitely (which they couldn’t wholly escape on the OS/2 side, admittedly!).
You know 1990 was not a quarter century ago? Time flies…
Yes, that was the linker (two actually, LINK and LINK386).
The linkers were part of the OS/2 source tree and IBM had full rights to distribute them. That was not the case with the C compiler, which I’m pretty sure IBM never had the source code for.
So your memory isn’t wrong, and IBM did not need to develop their own linker (though they eventually did anyway, it was called ILINK). But they did need a C compiler.
Interestingly IBM also had no assembler (until circa 1998 or so, it was called ALP) but people could keep using MASM 5.1 and 6.x without much trouble.
Ir:
“You know 1990 was not a quarter century ago? Time flies…”
34 years ago, a third of a century ago :O
Michal,
So, I’m curious what you make of the old 16-bit IBM C/2, which an older version of your site (https://www.landley.net/history/mirror/os2/history/exhibits) calls “rebranded Microsoft C”.
1) Has this been confirmed?
2) If yes, did Microsoft simply re-brand it for IBM, and IBM packaged it, without any access to the source code themselves?
3) Perhaps IBM did have the source for MS C 5.x, but not for subsequent releases?
4) If yes to above, what would have caused that to change, especially given that before everything in the relationship went kaboom, it would make sense that they were working even more closely than before?
IBM C/2 is absolutely Microsoft C. Look at it. Microsoft copyrights all over the place, identical options, CodeView, etc. etc.
How exactly it was done I don’t know. If I had to guess, Microsoft built it for IBM, and IBM never had the source code, although IBM clearly wrote their own documentation.
The C compiler was always Microsoft’s, not covered by the JDA, so if Microsoft said “no”, that was that.
It would be very surprising if IBM could not sell the compiler. All the previous agreements provided IBM with source code that could be modified before IBM sold the product. IBM would never leave themselves in a position to be unable to sell a product if IBM’s partner changed direction. If IBM did not offer the product, it was because IBM did not want to offer it.
The early 90s were a bad time for IBM software development for Personal Systems. IBM would announce a product, develop the product, and cancel the product as soon as IBM pivoted to a new strategy.
My experience with IBM is that they did get the source code, but it was placed into escrow and IBM couldn’t use it unless the company owning the source code went out of business and such.
In this case, yes, I expect IBM could keep selling the 16-bit compiler… but that did not solve the need for a 32-bit compiler.
One curiosity is that circa 2000, IBM started shipping a stripped down Microsoft C 6.0 compiler with the OS/2 DDK.
“After staring at instruction traces for a little while, I found the rather unexpected cause. In the DOSKRNL file (the DOS 4.0 kernel running inside OS/2 DOS boxes), Microsoft tried to be clever and used an invalid instruction as a fast path to access protected mode services. But there was a fatal problem: Microsoft used the 0F 7F opcode, which is not undefined on Pentium MMX and later — it is the MOVQ instruction. For that reason, launching DOS boxes in build 6.78 fails miserably on Pentium MMX and later Intel processors (except perhaps on the Pentium Pro).
“Rather interestingly, OS/2 2.0 pre-release build 6.123, which is only a few months newer, does not suffer from this problem. It uses the HLT instruction instead, which always causes a #GP fault in V86 mode, and works fine on modern CPUs. It is a bit of a mystery what motivated Microsoft to change the mechanism, since MMX processors were years away.”
Wonder if this is at all related to this story from Raymond Chen (https://devblogs.microsoft.com/oldnewthing/20041215-00/?p=37003):
“At this meeting, the Intel representatives asked, “So if you could ask for only one thing to be made faster, what would it be?”
“Without hesitation, one of the lead kernel developers replied, “Speed up faulting on an invalid instruction.”
“The Intel half of the room burst out laughing. “Oh, you Microsoft engineers are so funny!” And so the meeting ended with a cute little joke.
“After returning to their labs, the Intel engineers ran profiles against the Windows kernel and lo and behold, they discovered that Windows spent a lot of its time dispatching invalid instruction exceptions. How absurd! Was the Microsoft engineer not kidding around after all?
“No he wasn’t.
“It so happens that on the 80386 chip of that era, the fastest way to get from V86-mode into kernel mode was to execute an invalid instruction! Consequently, Windows/386 used an invalid instruction as its syscall trap.”
It is related, but maybe not directly. The invalid instruction used by Windows (and OS/2 MVDM) is ARPL in V86 mode. The problematic instruction in question here is used only by DOSKRNL (I believe) and does not use ARPL, obviously.
What I meant is that writing a 286 protected mode OS was already quite a complex project. Writing 386 paging code would have made the project even more complex.
“good point about Win-OS/2 also not originally being on the 2.0 roadmap, either.”
https://ftp.betawiki.net/docs/Microsoft_Systems_Design_Review_Dec_15_1989.pdf was doing the rounds on IRC today and is interesting on a few different points.
WLO is mentioned a little on 2-11 and much more at 2-30 and 2-35. It looks like at this point – December 1989 – Microsoft was planning on Windows API binary compatibility in OS/2 2.0. As far as I know, the reason that WLO programs needed to be relinked was to ensure all DOS services were implemented via Dos3Call since int 21h was not available in OS/2 1.x. This document seems to imply a plan to make it available, possibly selectively, in OS/2 2.0. I’m not clear on why a 386 was necessary for that.
Note though that these slides are MS, not IBM. Gordon Letwin’s later claim that IBM was firmly opposed to it and “kicked us out” is not necessarily incompatible.
Also featured on The Register:
https://www.theregister.com/2024/03/11/trying_ms_prerelease_os2_2/
Malcolm: Interesting. Of course, Microsoft’s WLO was a different strategy technically than what IBM themselves finally settled on, being something more akin to what IBM later tried with their limited Win32 re-implementation a-la Open32. (Though WLO undoubtedly offered greater coverage of Win16 than Open32 did of Win32…in part because Microsoft was the author both of it as well as the actual Win16 APIs, as well as due to Win16 just being a vastly smaller surface area to target compared to Win32.)
Granted, we only seem to have the equivalent of a slide deck here, but it’s not entirely clear to me what the plan was for making it possible for Win16 binaries to be able to run under MS OS/2 2.0 completely unmodified. Is your read that the intent was for the kernel, recognizing it to be a Win16 binary, would trap INT 0x21 calls, remap them to their equivalent 16-bit OS/2 APIs, and then stub in WLO to implement any calls made to Win16 functions? In effect allowing for a Win16 binary to basically run as a native 16-bit OS/2 task/process without invoking MVDM/virtual 8086?
IBM of course ended up taking a different tactic, treating Win16 apps basically just like DOS apps (though with some special sauce applied), running them within one (or more) 8086 VMs where effectively a full copy of real, actual Win3.x was loaded. Though arguably way less efficient, this probably also resulted in both grater stability as well as wider inherent app compatibility (who wants to be continually chasing the evolution of Win16 APIs at the lowest level, re-implementing them + any underlying “bugs” in them that app developers have grown to rely on!). This can’t have been the original plan, so again, I remain amazed that OS/2 2.0 managed to get out the door when it did!
Windows 3.0, whether in Standard Mode or 386 Enhanced Mode, was implemented as a DPMI client (KRNL286 or 386, etc.) and as a DPMI server (DOSX, etc.)
This made implementing Win-OS/2 significantly simpler than trying to implement WLO to get it to work: just add a DPMI server to OS/2’s MVDM, patch a few bugs in Windows 3.0, and then the full environment runs.
In retrospect, this was a better architecture to transition into from the perspective that it made multiple independent Windows sessions possible and ensured maximum compatibility, and ultimately was the entire architecture of Windows 95. The OS/2 and NT approach also chewed up a lot more RAM.
Both IBM and Microsoft (with NT) badly underestimated how scarce RAM would be in the early 1990s. A 4MB 386 was typical and a 2MB 386SX was a common entry level machine. These ran Windows 3.0, including in Enhanced Mode, just fine but were an absolute dog to run OS/2 2.0 on with any workloads other than some DOS and Win-OS/2 sessions.
I vaguely recall an epoxy shortage leading to high RAM prices. Microsoft accidentally ended up with an operating system that ran well in 2 or 4MB of RAM.
Nathan Anderson,
The approach you describe is basically how WINE works. Given how long development took of WINE and how buggy WLO was, Win-OS/2 looks like it ended up being the better approach.
Microsoft did eventually implement what you are talking about in the form of WOW in NT, and also in a completely different way on Windows 95. They had an absolutely ridiculous degree of compatibility testing and QA to get it all to work. Win-OS/2 and the MVDM was a much simpler design, by comparison, and still achieved the same level of compatibility. (Even things like DDE worked.)
And not to forget… Microsoft also had all of the Windows 3.x source code.
@Malcom whoa! You wrote YEdit!? That’s the #1 tool I install on all of my Windows servers first, since it’s the only editor I’ve got handy that works via SSH. Thank you very much for saving my bacon on so many editing-exe.config-file occasions!
Respectfully,
Brian the Ebay Guy
PS: DaveC and GordonL absolutely hated each others’ guts, per the standard folklore. Had the JDA not fallen apart, any theories on how that dynamic would have affected development of OS/2 3.0 (née “NT OS/2”)?
Joshua Rudd: “This made implementing Win-OS/2 significantly simpler than trying to implement WLO to get it to work: just add a DPMI server to OS/2’s MVDM, patch a few bugs in Windows 3.0, and then the full environment runs.”
Though I don’t know details, I’d always been under the impression there was a bit more to it than that, mostly based on how newer versions of Windows never “just worked” with the existing implementations & thus how IBM was forced to chase after Windows updates, both relatively major (3.1) and minor (non-WfW 3.11). (Not to mention of course the implementation of “seamless” sessions, which could have been avoided if WLO was handling the translation of Win16 to PM windowing API calls, plus things like DDE and shared clipboard, etc.)
“The approach you describe is basically how WINE works.”
That makes sense. I mean, clearly WINE attempts to clean-room-re-implement Windows APIs. But I tend to forget that it supports (and indeed started with) Win16 & not just Win32, and so the question of also having to translate direct DOS API calls that the app might make never even occurred to me.
I suppose had MS remained involved in 2.0’s development, perhaps they could have taken a hybrid approach?: run the process under real DOS within a MVDM session, but rather than also pile a full Win3 environment on top of that the way IBM did, have a loader stub that instead leans on WLO…that way, you’d still get native PM window painting and controls while also avoiding the DOS “problem” entirely. I’m not sure what kind of technical challenges would be involved with having what’s effectively a DOS process running within a virtual machine essentially making calls into Presentation Manager that exists outside of that VM, but assuming that’s a feasible strategy, perhaps this is what MS had in mind, which to Malcolm’s point might explain the 386 dependency.
Michal: “And not to forget… Microsoft also had all of the Windows 3.x source code.”
Well, I mean, so did IBM. 🙂 Though no disputing Microsoft would have had a way better understanding of it.
Brian L.: “DaveC and GordonL absolutely hated each others’ guts […] Had the JDA not fallen apart, […]”
First, thanks so much for stepping in and saving this piece of history!
Even assuming that’s true, Letwin, who had extraordinary tenure, left MS in 1993, and I haven’t been able to find anything to suggest that his retirement had anything to do with the dissolution of the JDA and (thus) of MS’s involvement with OS/2. So my guess is that it’s highly likely he still would have left MS at around the same time, though of course impossible to say for sure! Cutler came on-board in 1988, and I think pretty much went to work on NT straight away. So seemingly 2.0 and NT 3.0 were happening in parallel, and the impression I get is neither one answered to the other, so perhaps there was little need for (nor actual) day-to-day interaction between the two. Had Letwin stayed on and MS still remained involved with IBM, perhaps they would have just continued leap-frogging leading releases like that: Letwin starting 4.0 while 3.0 was being finished up, Cutler jumping ahead to 5.0 after 3.0 shipped, etc.
Also, Cutler has said that one of his stipulations when accepting the job at MS was that he refused to work with or answer to IBM! And from some of his old Usenet posts, it’s clear Letwin also had no love lost for IBM himself, so that was at least something that they shared in common; heh.
Nathan Anderson,
“Not to mention of course the implementation of “seamless” sessions, which could have been avoided if WLO was handling the translation of Win16 to PM windowing API calls”
This is how NT WoW16 is implemented. NTs MVDM kernel component creates the WoW16 process by loading KRNL386 as a DPMI client, but KERNEL, GDI and USER calls and the rest of WoW16 DLLs are mostly stubbed. All the translatable APIs are trapped by the MVDM and thunked into their 32bit counterparts. Also check the KRNL386 module only implements the Standard Mode API (No VxD/Windows386 stuff) and WoW16 will always report being running in Standard Mode.
This is different from OS/2, which implements basically a mostly complete VM a la VMware, including Video Drivers for their Seamless Window mode. Back then, one of the complains of the OS/2 Windows Compatibility is that it couldn’t run VxDs which some applications wanted to use (for example AutoCAD uses it to run Watcom “Windows Extender”, and PADS to run the Pharlap TNT-on-Windows component). The Netware for OS/2 experiment indicated IBM had plans to expand the MVDM to run entire OSs with drivers calling back into the host (aka Windows386). That never happened as OS/2 was already imploding at time of Warp3 , and Warp4 made no dent into the Windows 95 market share.
The story has been mentioned on Ars Technica:
https://arstechnica.com/gadgets/2024/03/unreleased-preview-version-of-microsofts-os-2-2-0-posted-to-internet-archive/
No mention about OS/2 Museum, though :/
Oh well, they’re behind the times 🙂
Calling it “unreleased” is a bit of funny…
I worked on OS2 for about 4 years in a joint IBM project.
The unopened box with documentation was really amusing and close to what we did.
We had a whole room full of these boxes which we received from IBM pretty much every week. The rule was that you were not supposed to dispose of the old versions without a shredder. We had no staff to do the shredding so we just stacked each new delivery on top of the last one.
As time went on and Windows evolved MS and IBM became enemies and the whole thing fell apart.
I think IBM spent about $1billion on the effort, their biggest failure up until that time.
@michael uffer: …and any idea where those old boxes full of docs and disks happened to have ended up???
(that was supposed to have a 🙂 at the end, heh; apparently this commenting system frowns on Unicode emojis)