In a fascinating example of poor timing, disk images of OS/2 2.0 pre-release level 6.605 from July/September 1991 were missing for over 25 years, only to show up literally one day after after the 25th anniversary of the OS/2 2.0 release (big thanks to a very helpful reader!).
Let’s go back to the odd numbering for a moment. The build “levels” of OS/2 2.0 started apparently at 6.00 and went all the way up to 6.307 for the GA release (though the 6.2xx range may have been skipped entirely). The 6.605 pre-release from September 1991 became available between 6.149 (July) and 6.167 (October). It is not known what possessed IBM to assign it a completely out-of-sequence number. It is known that 6.605 is very close to 6.149 but contains additional fixes to work better with LAN Server (LS) and Extended Services (ES) pre-releases.
For reference, OS/2 1.0 used internal revisions 3.xx, version 1.1 used internal revisions 4.xx, and OS/2 1.2 used 12.xx. The fact that OS/2 2.0 used the 6.xx range probably reflects the fact that its development started after OS/2 1.1 but before 1.2.
Even though the 6.605 disks are clearly labeled 7/91 (July), they were just as clearly finalized in September 1991. It is possible that 6.605 was somewhat unplanned because the next level (6.167, or OS/2 2.0 LA) was the first to contain the Workplace Shell (WPS), and putting that together may easily have taken longer than anticipated.
The upshot is that 6.605 was in fact the last OS/2 2.0 pre-release which didn’t use the WPS and instead utilized the same old Desktop Manager as OS/2 1.2/1.3, which makes it the closest surviving relative of the MS OS/2 2.0 SDK:
The look and feel was not quite the same as OS/2 1.3 and in fact was a cross between OS/2 1.3 and Windows 3.1.
When booting up, 6.605 also looked rather similar to OS/2 1.3:
In general, OS/2 2.0 Level 6.605 looked very much like OS/2 1.3 with just one slight difference—32-bit kernel (though in reality there was a bit more than that). It is important to note that although the kernel was 32-bit with support for large memory, 32-bit applications, paging, and all those goodies, it was in fact a 16-bit/32-bit hybrid. Device drivers in 6.605 are essentially taken wholesale from OS/2 1.x with minimal changes, and therefore 16-bit. Somewhat ironically, there was a new class of 32-bit device drivers in OS/2 2.0—virtual device drivers to support DOS sessions which typically ran 16-bit code. IBM never fundamentally changed the driver architecture, although starting with OS/2 Warp Server for e-Business (version 4.5), there was limited support for 32-bit drivers, most notably filesystems (JFS).
OS/2 2.0 GA got a new disk subsystem with modularized architecture (ADD, DMD, FLT modules); there was no sign of that in 6.605, or for that matter in 6.167 or even 6.177. There was just one monolithic DISK01.SYS driver like in OS/2 1.2.
The 32-bit kernel was able to support VDMs (Virtual DOS Machines), a major new feature of OS/2 2.0. And one notable visual difference between 6.605 and OS/2 1.3 was that “DOS Window” icon (DOS windows were something OS/2 1.x could never do). The DOS window looked like this:
What is worth noting is the amount of free DOS memory—over 627K. That was another improvement over OS/2 1.x which, on top of all other problems with DOS compatibility, also struggled with leaving enough free conventional memory in the DOS box.
There were familiar settings for DOS sessions:
The layout was not the same as in OS/2 2.0 GA but the basics were there. The DOS sessions could switch between full-screen and windowed operation, supported copy & paste in both directions, and generally provided good compatibility with existing DOS applications. And of course multiple DOS sessions could be preemptively multi-tasked.
Microsoft and IBM threw in a bunch of little goodies that made the OS more pleasant to use:
The Enhanced Editor (EPM) was IBM’s, a step up from the very basic E.EXE. Reversi was the same Microsoft game which made its appearance in Windows 1.0. Solitaire was IBM’s, very similar to the Windows game but independently developed. The set of utilities and games shipped with the OS changed quite a bit between 6.605 and the final release.
And there was a nice little tutorial for first-time users:
For obvious reasons (WPS), the tutorial needed to change quite substantially for the GA release.
Besides the user interface, there was another thing that OS/2 6.605 shared with the earlier MS OS/2 SDK releases but not the final version: the executable format. 6.605 still used the LE format of 32-bit executables, while OS/2 2.0 used newer LX. What that means in practice is that 6.605 can’t run executables designed for the released OS/2 2.0 and vice versa. OS/2 6.605 does not recognize LX binaries at all and considers them to be DOS programs, whereas OS/2 2.0 GA actively refuses to run LE binaries.
One significant new feature in 6.149/6.605 was MOST, or Multiple Operating System Tool:
MOST allowed multiple operating systems to coexist on the same disk, and also allowed OS/2 2.0 to be installed into an extended partition (typically drive D: or higher). Needless to say, MOST was quickly renamed to Boot Manager and that’s how it was known.
MOST made it easy to dual-boot between DOS and OS/2. The obvious step is then trying to run Windows 3.0 installed on the DOS partition inside an OS/2 DOS box:
Since there was no special support for Windows yet, Windows 3.0 only ran in real mode. But it did run, even in a DOS window. A sign of things to come.
It’s probably fair to say that OS/2 2.0 level 6.605 from September 1991 was the last pre-release very similar to the MS OS/2 2.0 SDKs, both visually and technically. The next pre-release, 6.167 from October 1991, looked and felt very different and was much closer to the final GA release from March 1992.
I wonder if the DOS is based on 4.01 or 5.0.
How to tell easily? Without using the version number, because that’s faked anyway…
See if DOS=HIGH works, for example.
Well LOADHIGH is there so it is based on DOS 5. Also with 642,944 bytes free the VDM DOS must be using the (virtualized) HMA.
Would it be possible for you to share those old disks with us? Even if you would rather not share them publically (for whatever reason), it would still be greatly appreciated if you sent them to me privately.
I’m personally interested in having them for testing the old pre-release OS/2 versions under emulation, as well as keeping them around for when my PC emulator’s 386 emulation is complete enough to handle it (currently correcting more instructions as well as adding support for 386 features such as descriptor tables, paging, and protected mode exceptions).
Plus, it’s quite an amazingly interesting product in its own right, even for that one pre-release version of it.
Well that was unexpected, and fantastic too!
I would imagine the MS SDK should produce executables for this system? Just as the old 16bit network clients ought to work.
Cool to finally see this version!
Yes, it does, up to a point. The 6.605 pre-release can run executables produced by the Summer ’90 MS OS/2 2.0 SDK tools, but there are clearly differences and lots of the sample programs (as well as CV386, sadly) crash sooner or later. I haven’t tried any network stuff; I’m sure something worked but not sure what.
Definitely very cool to see this version. And I’m sure the older pre-releases are out there somewhere, too. And someone might also have the IBM pre-release development tools. The thing is that the MS OS/2 2.0 SDK was an SDK and it always came with all development tools, but IBM ran things differently and made it possible to get just the OS itself, which is probably what many users did.
Who’s “us”? Anyway, I don’t have the disks and their owner asked me not to share the disk images, sorry!
As far as testing goes, this pre-release is not too different from the released version. The core kernel implementation is the same. And yes, OS/2 2.x is a great test of x86 emulation 🙂
Ah yes, high memory support is there, and so is UMB support. So it’s some form of DOS 5.
Out of curiosity, does it run MS Flight simulator 4 in a window? I think that was their ‘torture’ test of the day, as it was buried on some Win32 test thing somewhere that also had minimal versions of Word & Excel for NT.
Interesting that they went so far as to create a tutorial for the “Desktop Manager” UI…
Does that mean that they intended to release OS/2 2.0 with that UI at one time, or was it something “left over” from OS/2 1.x development?
Releasing 2.0 with DM would surely have made some sense in 1990/1991, reducing the fairly steep for the time system requirements and being more consistent with what Windows looked like at the time. WPS could have been left for 2.1 or even 3.0. I can imagine that having basically the same UI as OS/2 1.2 had in 1989 might have lead some to question “what’s new?”, even though 32-bit applications, multiple VDMs and Win-OS2 would still have been “killer apps” for 2.0. Microsoft did get away with using the same UI all the way from Windows 3.0 in 1990 to NT 3.51 in 1995.
The WPS certainly wasn’t the original plan for OS/2 2.0. When exactly the decision was made to use the WorkPlace Shell as OS/2 2.0 UI is hard to say, but probably not long after IBM took over development. So perhaps late 1990, maybe even early 1991. Of course according to initial plans, OS/2 2.0 should have been already released by then.
As you say using the same UI for Windows NT didn’t seem to hurt it much. And users seemed to appreciate the DOS support and 32-bit API, even without the WPS.
Thanks for look. I remember 6605 was a bit of a problem child for those upgrading from it; never would have guessed that the executable format changed.
Thank you Michal for your great posts on OS/2! It sure brings back fond memories!
At that time I was working for IBM with OS/2 developer relations, and I remember downloading the OS/2 images from our internal repositories, creating all the disks, and then installing the betas. I can’t remember how many hours it took, but it was a lot. And disk space was limited at that time, so it was an adventure.
Once again. Thanks!
Mats
I tend to assume that OS/2 2.0 would have been released in late 1991 if MS did not turn it into a entire fiasco, following a yearly schedule.
It looks to me like these betas would need 15-30 MB disk space for the images, and I know that in 1991 that was not little. Not when one might have a 40-80 MB hard disk.
I think I read in the anti-trust exhibits that MS was targeting 60MB or larger hard disks for OS/2 2.0, which would have been common by 1993-1994.
The problems with disk size were caused by IBM itself. The Model 90 shipped with an 80MB hard drive in late 1992; a time when even cheap 386SX clone desktops were readily available with more than 100 MB hard drives and competing EISA servers were commonly offered with gigabyte drives. IBM tried to slow the progress of technology to preserve the mainframe costing market share while making OS/2 a poor choice for the hardware IBM shipped.
Hehe, nice!
The thing is, back when OS/2 Warp came out, driver support was horrible – internet connections weren’t that fast back then, downloading a driver for being able to use SVGA with 640×480 @ 24Bpp was a reeeal hassle 🙂
Though, i think OS/2 was better than Windows back then, even if it took 8 MB (!) RAM to run it somehow smoothly…
Regards
IBM was selling high end machines with 80MB in 1992? Yikes. I know Apple with shipping LC series Macs with drives that small during that time period, but they were clearly being built to a price-point.
Love the font in the DOS prompt.
Does the desktop manager use the same format for program groups and icons as progman.exe in Windows 3.1 (pif and grp) ?
@Mats Petterson:
Do you happen to still have the floppies containing the betas by any chance?
Interesting that in 6.167 and later versions, the amount of free DOS memory shrank to about 600 KB. Was that due to the added support for Win-OS/2, perhaps?
OS/2 was ahead of its time. But the user market was going cheap and cheap meant Windows. So what was a developer to do? Develop Windows apps of course! But Windows was fairly unreliable as a development platform. Solution: run windows under OS/2 and develop that way. When Windows would crash out with a blue screen it was just simply kill the remnant windows process from the OS/2 layer and restart. No more 2 minute reboots and the like to get windows back up from scratch. Good times until Windows eventually matured with Win95.
No, not the same. There is no .PIF equivalent because that was (also) meant for running DOS applications under OS/2. That mechanism simply didn’t exist in OS/2 1.x. In OS/2 2.x it was done very differently.
I don’t know how much the price was a factor and how much OEM preload deals. Once people bought a new PC with Windows on it, the incentive to look for another OS was very limited. For OEM preloads pricing was a factor, but Microsoft’s strong-arm tactics probably much more so.
And yes, OS/2 2.x was definitely great for Windows (and DOS) development, much more forgiving than the real thing.
Maybe there’s more than meets the eye with this release.
My untrained eye tells me that there might have been several different and maybe fighting groups trying to up-end one another.
Clearly this whole numbering fiasco meant one group wanted to be at the final release against another.
The fact that 6.149 (July) was Program Manager Based and 6.167 (October) was Workplace OS, but yet 6.605 (September 1991) was still PM is a testament to the fact that the PM group “kept on going” while the rest of IBM had already decided to scrap most of Microsoft code base.
That would resolve the numbering issue and the drastic changes between similarly numbered released.
As for the numbers, one must realize that at that time, the reigning Windows was 3.0 and IBM wanted to one-up Microsoft with a OS/2 4.0, but reason prevailed and it was correctly numbered 1.0.
The reason .PIF couldn’t be used under OS/2 was that the extension was instead given over Picture Interchange Format because everybody needed mainframe graphics a lot more than better DOS VM configurations. I forget which INI file stores the equivalent information; the OS/2 install I normally double check things on isn’t working.
Pricing: DOS + Windows tended to be about $50 cheaper than OS/2 for OEMs; that is, $50 versus $100 though that varied as IBM changed market strategy including times when IBM refused to let anyone else install it. IBM’s decision to make add-ons like the initial multimedia release cost more than the base OS/2 probably slowed uptake.
Not only was DOS + Windows cheaper, Microsoft made sure that if OEMs also wanted to preload OS/2, DOS + Windows was going to cost them more.
That sounds like a lot of extrapolation from very little information.
@Necasek: is that admiration I hear? 😉
Seriously, while admitting that it’s pure speculation, I think Carlos could be on to something.
Pingback: OS/2 2.0, Xmas ’91 Edition | OS/2 Museum
Interesting. I still have my OS/2 disks. They look just like the ones above.
@Andrew: So are they the same build?
Very interesting, and nice piece of history you have brought forward here. Thanks!
It would probably have been much easier to sell OS/2 as an upgrade (and “better Windows than Windows”) if they had kept this closely looking/feeling GUI on OS/2.
For Microsoft it was probably a good thing that IBM changed the GUI on OS/2 2.0 to a totally new one. Even if a better GUI (I like WPS and used it on OS/2 2.11 and Warp 3 at the time), it really alienated a lot of existing Windows 3.x users at the time.
For IBM it would probably, from a sales and marketing point, been much better and easier to sell OS/2 if they kept the familiar Win3-GUI instead. Now it ironically became Windows NT that benefited from that strategy of being a “better Windows than Windows” (even if that was IBM’s marketing departments slogan for OS/2 to try to sell it).
That OS/2 2.0 debacle is more complex than that though. One thing to remember is that this build is just after the MS OS/2 2.0 SDKs in 1990.
Id recently gotten GCC & GAS to run on the December 1991 pre-release of NT.
I tried to build it using the Microsoft tools but it fails. Was there a 32bit version of Microsoft C/386 in this version?
Also I wonder if link386 from this one could handle 386 Xenix OMF files like the Visual C++ 1.0 linker can?
I’d have imagined someone would have built a native GCC on OS/2 first that didn’t rely on a.out binding.