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.
raijinkai:
“Also check the KRNL386 module only implements the Standard Mode API (No VxD/Windows386 stuff)”
Does Windows 3.x have separate Standard mode and Enhanced mode APIs? AFAIK, they’re essentially identical (except, perhaps, for the memory allocation limit in GlobalAlloc and functions like GlobalPageLock, which, however, I doubt are/can be implemented in OS/2). As for the “VxD/Windows386 stuff”, I don’t think Win 3.x Enhanced mode’s KRNL386 supports any of it, except some obscure calls to use 32-bit protected mode segments (which, however, has nothing to do with VxDs). This is just IMHO, of course,
“and WoW16 will always report being running in Standard Mode.”
How do you ask the WoW16?
This is different from OS/2, which implements basically a mostly complete VM a la VMware, including Video Drivers for their Seamless Window mode.
Do you have any example of a 16-bit Windows application that runs in OS/2, but not in Windows NT?
If one calls GetWinFlags, it would return WF_ENHANCED or WF_STANDARD alongside WF_PMODE if Windows is not running in real mode. I haven’t checked if WoW16 returns those results.
Some functions work differently in Enhanced Mode like GlobalAlloc supporting 64 MB blocks. Some functions are specific to Enhanced Mode like OemKeyScan though that may not be part of KRNL386.
regarding DOSKRNL’s “MOVQ” issue, is it possible to patch it out?
but it seems that mvdm’s exception handler needs to be patched as well, but where’s it?
Side track: The problem with the latest comments not showing up on my side is happening again. http://www.os2museum.com resolves to 188.114.96.1. I can see the comments in the RSS reader that I assume accesses the site using the same IP (as it runs in the same web browser). Latest Firefox, this time running on Windows 10.
Am I the only one affected, or is it rather that everyone not using RSS not noticing this?
I highly doubt that it’s a problem on my side as it afaik has only ever happened on this site. Seems like some cloud propagation bug.
The last part of a traceroute to that IP shows this (hop number and ping time trimmed out for obvious reasons):
s-b2-link.ip.twelve99.net [62.115.123.170]
s-bb1-link.ip.twelve99.net [62.115.140.214]
oso-b1-link.ip.twelve99.net [62.115.116.100]
cloudflare-ic-372160.ip.twelve99-cust.net [80.239.196.115]
188.114.96.1
If the site runs on a free service then we’ll just have to live with it not being perfect. However if it runs on some paid service, even at the rock bottom price level, I think it might be worth contacting support about this, perhaps? Unless it’s an informed decision to have a service where comments propagate slowly in order to have a lower price or so? If that’s the case then that’s fine too as I’m not in a position to complain about details about an excellent blog that is provided to the world for free.
MiaM: could it be because there are more than 50 comments, and they were split into multiple pages?
Yes, and I don’t know. It didn’t seem like looking for it was worth the effort. But it is likely doable.
Ender: Bingo! Never realized that.
There seems to be a bug in the RSS feed where the link to where the comment appears is to “comment-page-1” even when the comment appears on page 2.
Michal: This must 100% for sure be a bug that can be fixed. Not sure how though. I made an attempt at googling for any solutions but I either got generic “rss is broken” results or if i try to narrow down the search I get no results at all.
As a work around maybe change some setting to allow a few hundred comments on the first page, if possible?
@Nathan Anderson,
Win-OS/2 didn’t have very many differences from stock Windows. In fact, the “OS/2 for Windows” would simply patch the executables or DLLs at runtime with the changes needed.
The most significant change was that running Win-OS/2 in 386 Enhanced Mode could skip loading VxDs (since OS/2’s DPMI server, well, doesn’t allow loading VxDs). Other than that it was some pretty minor stuff.
Yes, WINE predated Windows 95… and it took a long time until WINE achieved anything close to the level of compatibility that Win-OS/2 had.
Even Windows 95 and NT’s implementation (which is the same approach as WLO) had a lot of incompatibilities. Microsoft remedied this with a gigantic QA operation where they bench-tested all kinds of available software and then exepatch’d the bugs away so it would be compatible.
Well, honestly, we can see the approach Microsoft would have taken with a look at NT… which is basically the WLO approach. And yes, WoW16 calls directly into Win32 GDI, USER, etc. APIs (after thunking). The DOS “problem” isn’t entirely avoided since Win16 programs like to call Int 21h to do various things, but WoW16 just implemented enough of that for things to work.
Overall, I think the Win-OS/2 approach is the better one: better compatibility. (Any “issues” with seamless display drivers were fixed in the GRADD era, when a generic seamless driver existed, so any GRADD device would work fine with Win-OS/2.)
For a modern implementation of the Microsoft WoW approach, someone implemented WINE and part of a VDM on 64-bit Windows, at github.com/otya128/winevdm – he took the approach of emulation on the CPU layer and then using WINE to implement some of the 16 bit Windows system, and thunks to the host for the rest.
The WoW approach used less memory and ran faster at the expense of complexity. It helped that MS had the source for both sides of the operation and could makes sure that the correct values were passed along. IBM’s more correct but slower method kept users away and it was unlikely that anyone would wait 5+ years for improved drivers, faster CPUs, and more memory to make OS/2 usable.
In many respects, I think IBM and MS should have traded strategies for both running Windows 3 apps and getting an object oriented shell. MS had the solution that worked better with the more limited machines of the early 90s while IBM had the solution that would scale easier after 2000.
In addition to the WoW approach being faster, things like clipboard sharing and whatnot was likely easier to not have to treat like a special case.
The Int 21 API would be the easiest part to emulate, and you would have to emulate it either way as you can’t run an actual DOS accessing the same physical disk that’s also mounted in the host operating system. (Best regards from Captain Obvious 🙂 )
A bit of opinions, that no-one asked for 🙂
IMHO I think that there was too much focus on what should be possible to do with the desktop in the second half of the 90’s. The update that came at the same time as IE4, and also was default in Win98 IIRC, just slowed down low spec computers. Sure, there were positive things with the desktop update too, but those could had been achieved even without the resource hogging parts.
Also: Even today Microsoft haven’t (IMHO) got the desktop and related things completely right. An example is that you can pin explorer to the task bar and start explorer by clicking on the pinned icon, but you can’t use that icon to launch new explorer windows. Sure, in this particular case you can press win+e, but still. Also there is no seemingly easy way for the user to alter pinned icons on the task bar. I.E. you can easily pin things like your web browser, but you can’t pin “start Firefox with -profilemanager”, and you can’t pin “start OTVDM with reversi.exe”. There are ways to programmatically add pinned icons that send special parameters to applications and use selected icons and whatnot, like Firefox offering to ad an incognito icon to the task bar. But that seems like something that the end user isn’t supposed to fiddle with themself.
What Microsoft always got right with Windows is that they understood that users don’t want to browse around the file system to find the executables for each program, and they also understood that users are actually more task oriented than object oriented than UI people might think. I.E. sure it’s nice that you can click on a word document and have word open, but many people open an application and within it does whatever they are about to do. In particular this is true for web browsers – few if any have URLs laying around on their desktop that they click to go to certain web sites.
Do you have some numbers for that? Or was the speed and memory advantage more than outweighed by NT itself being slower and needing more memory?
Windows NT didn’t have to be fast; it only needed to run Win16 programs close to the speed of OS/2. NT did gain the advantage of being released after memory became a lot cheaper.
PC Magazine did a number of performance comparisons on Win16 programs on NT and OS/2. See May 17, 1994 which covered performance relative to memory and showed that IBM’s systems as shipped with OS/2 were very sluggish. The Win95 issue (Sep 26, 1995) has combined lines charts show performance relative to memory for Word and Excel on the whole group of systems.
Key takeaways: 4 MB OS/2 took many minutes longer than anything else. 16 MB OS/2 was a bit faster than 16 MB NT with 16 bit Word but slower with 16 bit Excel. 32 bit apps were much slower than the 16 bit counterparts for Word, Excel, and the 32 bit Mesa thrown in for good measure.
> An example is that you can pin explorer to the task bar and start explorer by clicking on the pinned icon, but you can’t use that icon to launch new explorer windows.
You can run a new instance by wheel-clicking or Shift-clicking the icon (also, Ctrl+Shift+click gives you an elevated instance, though that doesn’t work with Explorer).
> Also there is no seemingly easy way for the user to alter pinned icons on the task bar.
This is somewhat non-obvious, but you can right-click the pinned icon, then right-click the program from the menu and choose Properties there to edit the pinned shortcut.
Richard Wells:
Was that NT 3.1 or NT 3.5(1)?
Did they state which file systems they used?
One of my grieves with NT was how sluggish the computer became when you had loads of smaller files. Say for example that you have a Pentium II computer with 64 or 128 M RAM and a disk size of a few G. If you install MSDN you tank the performance severely just by having that many small files on disk.
(And then there is the problem that most operating systems still seem to suffer from in that they are really bad at estimating what to keep in memory. Operating systems can profile themself and the applications all day long but unless actual humans decide that certain things are more important the operating systems will never be able to properly prioritize what things users experience as more or less annoying having to wait for).
Ender: Thanks!
Interestingly the NT 3.51 HCL still listed PS/2 machines with 486SLC2 processors which are limited to 16MB of RAM.
MiaM:
The 1994 article compared NT 3.1 to OS/2 2.1. The 1995 article compared OS/2 Warp 3 with NT 3.51 and Win 95. File systems were not mentioned in the 1994 article though the disk access numbers make the most sense if NT 3.1 was using NTFS. One does not see a great jump in performance increasing RAM to 16 or 20 MB with a FAT drive. The 1995 article compares copy speed with XCOPY and download speeds over FAT, NTFS, and HPFS. The numbers are fairly close so I think the results are more limited by controller and internet connection instead of OS or file system.
PC magazine wrote about this, I found a couple of articles from june and august of 1990:
1) “Explore the depths and and Impact of OS/2’s new 32-bit API” https://books.google.com/books?id=u7WbsmbttwYC&lpg=PT101&vq=os%2F2&pg=PT368#v=snippet&q=os/2&f=false
2) “Taking advantage of the 386: the 32-bit version of OS/2” https://books.google.com/books?id=cSMUxSP5pKgC&lpg=PP1&pg=PT433#v=onepage&q&f=false
Contemporary of about 1993:
DOS 6.0+Windows 3.1 ran acceptably on a 386SX with 2MB of RAM in 386 Enhanced Mode, including running windowed DOS programs. With 4MB of RAM, it performed well, including plenty of spare RAM for SMARTDRV.
OS/2 2.0 in 4MB was unbearably slow, mostly because of the Workplace Shell. Replacing it with something like TSHELL (a bit of IBM Employee Written Software) made it run acceptably, including with full-screen Win-OS/2.
OS/2 3.0 in 4MB (released in 1994) was still unpleasantly slow.
NT 3.1 would not even boot in 4MB and was unusable in 8MB. It needed a 16MB machine to perform adequately. Whatever virtues early NT may have had, conserving RAM was not one of them.
Of note is that this Microsoft OS/2 2.0 beta seems to perform a lot better on a 4MB setup – presumably because it doesn’t have the overhead of the Workplace Shell.
Now, going back to this particular release in question, one thing that’s shocking is just how usable it is. You could use this for daily work, including running both DOS and OS/2 applications. (It can run Windows 3.0 in real mode and presumably could have been retrofitted to run something like Win-OS/2 fairly easily, although Microsoft’s direction was obviously to go WLO.)
It also has a capable networking stack, which makes it a great environment for multitasking DOS applications, with more RAM free than a Windows 3.0 Enhanced Mode setup would have had with the LM client loaded – and all of this in 1990. A 386SX with 4MB of RAM in 1990 was a powerful but not that expensive machine (about $1900, or $4,600 in present-day dollars).
Your other options at the time were OS/2 1.21/1.3 or DOS 4.0/3.3+Windows 3.0.
Yet despite this quite capable version, Microsoft instead fiddled around with a stopgap OS/2 1.3 release and then spent 3 years until NT 3.1 was released, which arguably was less usable than this release and required a lot more RAM. IBM spent 2 years to release OS/2 2.0, which didn’t really have any more features beyond this release other than a refresh to DOS 5.00 in the MVDMs, the Workplace Shell, and needed more RAM.
By 1993, it was clear computers were still shipping with 4MB or 8MB of RAM and were incapable of running NT and barely capable of running OS/2, and that created a market for Windows for Workgroups. In 1994 the typical new computer was a 486 with 4MB of RAM. The market for Windows 95 was created by that.
Joshua:
As a weird comparison of sorts, recalled from 30+ years ago:
A 286 with 1M (640k base, 384k extended) running Windows 3.x in standard mode, and with old MFM/RLL full height rather slow hard disks, took 1hr to install the then latest version of Excel, 20 minutes to start said Excel and 6 minutes to exit Excel 🙂
IIRC expanding to 2M (or rather 640k + 1M as with anything else than 1M that motherboard would only let you use the upper part of the first megabyte as shadow ram) did wonders.
Re workplace shell: IMHO the speed or lack thereof on a low spec computer seems like the result of “business people” making the decisions. Sure, it was probably good in many ways but at the time the annoying program manager / file manager of Windows 3.x was better.
(The weird thing is that it was technically possible to make an “object oriented” desktop with way less resources. Look for example at the initial Apple Macintosh, the Commodore Amiga and/or IIRC the Atari ST, which initially had 128k, 256k and 512k RAM. Sure, all of them had most of the operating system in ROM but even when including the ROM content it all summed up to way less than 1M. And sure, two of them didn’t have any multi tasking at all, while the Amiga had multi tasking but no memory protection and thus no performance vice costly content switching, but still).
(As a side track, the same things seems to happen all over again and again. It’s hard to understand how Microsoft managed to make the calculator in Windows 10 have a noticeable load/start speed. Sure there probably are some use cases where a larger user interface is needed, but for everyone else it’s a tiny bit of pain, enough that I consider copying the calculator binary from the install disc of some older Windows version).
Josh Rodd: IIRC, OS/2 1.3 was mainly an IBM product to meet IBM’s marketing requirements. MS spend 6 months after the release of 1.2 developing 1.21. MS then got their version of 1.3 ready a year after 1.21. OS/2 1.2 was everything that could go wrong in splitting development between companies and sites without a single strong leader.
MS did develop NT 3.1 slowly with years of betas. The actual release was only months after OS/2 2.1. If IBM was delaying their OS of the future, MS had no reason to rush an even larger OS to market indifference.
On the subject of 1990 era developer information. The Windows 3.0 DDK appears to have surfaced finally. Disks and documentation on BitSavers.
The Windows 3.0 DDK was interesting (particularly the documentation), which for some reason seems to explain some things that are notably absent in the 3.1 DDK, including a very good description of how 386 Enhanced Mode works.
On the subject of 1980s era developer information… the DOS 4.0 source were just officially releases, along with a pile of development notes / documentation on MT-DOS 4.0.