Archival Puzzles

Every now and then I attack the large amount of floppy disks in my basement and run a bunch of them through Kryoflux. This time it was a shoebox full of OS/2 related floppies. Among them was a very incomplete set of 10 floppies labeled “PRE-RELEASE IBM OS/2 2.0 32-bit Graphics Engine and WIN-OS/2 VERSION 3.1”, with the floppy masters most likely created on August 14, 1992.

What is this really?

Now, the labeling on those floppies is a bit funny. It’s obviously not a pre-release of OS/2 2.0 if the floppies are from August 1992 and OS/2 2.0 had already been released in March/April. At the same time the floppies don’t say “OS/2 2.1 pre-release”.

When I compared the floppy contents with existing floppy images in my archive, I realized that they (nearly) match two different sets: One that I thought was an OS/2 2.1 beta, and another that I identified as OS/2 2.00.1.

Upon closer examination, the supposed 2.1 beta and OS/2 2.00.1 images were 100% identical; clearly my fault. The images had come from an October 1992 IBM PDK CD, and on the CD they are rather unhelpfully labeled “Operating System OS/2 2.X”.

Since this is IBM we’re talking about, there’s both some measure of chaos and decently sized written record. Consulting the OS/2 V2.1 Technical Update shed some light on the confusion. Some.

OS/2 2.0 came out in March 1992 and version 2.1 in May 1993. But in the meantime, there were interim updates in the form of OS/2 2.00.1 (September 1992) and and Service Pak XR06055 (October 1992).

Some of the confusion stems from the fact that XR06055 was an update to be applied to an existing OS/2 2.0 install, whereas OS/2 2.00.1 was a preload on certain IBM systems, not available as a separate package, even though their contents were extremely similar. But because there’s no retail 2.00.1 media, it’s difficult to say “this floppy image is 2.00.1”.

An OS/2 2.0 system updated to XR06055 was by all accounts extremely similar to a 2.00.1 preload, although not identical; the XR06055 Service Pak came out a little later and contains additional fixes.

The output of the SYSLEVEL utility looks different on OS/2 version 2.0, 2.00.1, 2.1, and 2.0 with XR06055 applied. When the “OS/2 2.X” floppy images from the IBM PDK CD are installed, SYSLEVEL output exactly matches what the OS/2 V2.1 Technical Update says is OS/2 2.00.1.

Same or Different?

As if things weren’t confusing enough already, the physical floppies I have aren’t bit for bit identical to the floppy images IBM provided on CDs. And to be clear, the floppies aren’t just something that someone randomly copied, they are untouched mass-duplicated floppies. Well, except for the ones that someone overwrote in 1996 or so.

Here’s what the directory listing for Disk 13 looks like on the physical floppy:

         0  VOL 08/14/1992 22:26:00 DISK 13
    442084 ---a 08/14/1992 22:26:28 REQUIRED
    164076 ---a 08/14/1992 22:26:36 TIMESPSF
    172032 ---- 08/14/1992 22:26:46 WINENV
     98512 ---a 08/14/1992 22:26:54 INSTAID
     60020 ---a 08/14/1992 22:26:58 PMDIARY
    105700 ---a 08/14/1992 22:27:04 RAS
     50992 ---a 08/14/1992 22:27:08 FDISK
     43584 ---a 08/14/1992 22:27:12 EPM
     41924 ---a 08/14/1992 22:27:14 TIMES.BMP
     34356 ---a 08/14/1992 22:27:18 PMREXX
     26848 ---a 08/14/1992 22:27:20 TREE
     24800 ---a 08/14/1992 22:27:22 HELVG.FON
     23316 ---a 08/14/1992 22:27:24 RESTORE
     22148 ---a 08/14/1992 22:27:26 HELVB.FON
     32612 ---a 08/14/1992 22:27:30 DOS
     19040 ---a 08/14/1992 22:27:32 NEKO
     57800 ---a 08/14/1992 22:27:36 SOFTERM
     11340 ---a 08/14/1992 22:27:38 BIDI
      4816 ---a 08/14/1992 22:27:40 REXX
      2032 ---a 08/14/1992 22:27:40 WININIS
       108 ---a 08/14/1992 22:27:42 TOUCH

For comparison, this is the same disk provided as an image on an IBM CD:

     11340 ---a 08/14/1992 22:27:38 BIDI
         0  VOL 08/29/1992 20:13:04 DISK 13
     32612 ---a 08/14/1992 22:27:30 DOS
     43584 ---a 08/14/1992 22:27:12 EPM
     50992 ---a 08/14/1992 22:27:08 FDISK
     22148 ---a 08/14/1992 22:27:26 HELVB.FON
     24800 ---a 08/14/1992 22:27:22 HELVG.FON
     98512 ---a 08/14/1992 22:26:54 INSTAID
     19040 ---a 08/14/1992 22:27:32 NEKO
     60020 ---a 08/14/1992 22:26:58 PMDIARY
     34356 ---a 08/14/1992 22:27:18 PMREXX
    105700 ---a 08/14/1992 22:27:04 RAS
    442084 ---a 08/14/1992 22:26:28 REQUIRED
     23316 ---a 08/14/1992 22:27:24 RESTORE
      4816 ---a 08/14/1992 22:27:40 REXX
     57800 ---a 08/14/1992 22:27:36 SOFTERM
     41924 ---a 08/14/1992 22:27:14 TIMES.BMP
    164076 ---a 08/14/1992 22:26:36 TIMESPSF
       108 ---a 08/14/1992 22:27:42 TOUCH
     26848 ---a 08/14/1992 22:27:20 TREE
    172032 ---a 08/14/1992 22:26:46 WINENV
      2032 ---a 08/14/1992 22:27:40 WININIS

It’s pretty obvious that the entries are sorted alphabetically on the floppy image. That’s what one might get when copying the files from some existing source and doing the copy in alphabetical order.

On the other hand, the physical floppy is not alphabetically sorted, instead the entries have ascending time stamps. That’s what one would expect to happen when starting with a blank floppy and creating the files one by one. There are less than two minutes between the first and last entry; it’s entirely plausible that it might take that long to create the compressed archives on the floppy.

If I had to guess, the physical floppies reflect how the floppies were mastered. The images on CD were for some reason re-created about two weeks later. The timestamp of the volume label (August 14 on physical floppy, August 29 on the floppy image) tells the story.

This problem illustrates one of the difficulties with software archival. We have two sets of floppy images: One created from mass-duplicated physical floppies presumably distributed by IBM, the other floppy images provided as files on a CD by IBM. The images are different, even though they can be expected to be functionally identical. They both came from IBM and are therefore both equally valid, even though it is apparent that one set is older than the other and thus more “original”.

Back to the Version Zoo

So… even though they are not bit for bit identical, the floppies labeled “PRE-RELEASE IBM OS/2 2.0 32-bit Graphics Engine and WIN-OS/2 VERSION 3.1” are the same as the floppy images that I identified as OS/2 2.00.1. Is that even possible?

The likely answer is on page 289 of OS/2 V2.1 Technical Update:

A public beta-test version of OS/2 2.00.1 was released in September 1992, along with a public beta-test version of WIN-OS/2 3.1.

Okay, that actually explains things. My incomplete floppy set is clear that there were 14 system diskettes, same as the OS/2 2.00.1 floppy images. But then there were six additional “WIN OS/2 3.1” diskettes. Sadly the only two I have (Win-OS/2 disks 4 and 5) had been overwritten a long time ago.

Now, OS/2 2.00.1 actually already includes Win-OS/2… but it’s the version based on Windows 3.0. And as we now know, in September 1992 there was a beta based on Windows 3.1, delivered as a separately installable disk set.

In fact that same IBM PDK CD also contains 3.1-based Win-OS/2 floppy images, clearly created in September 1992. There is a bit of a mystery in that the physical floppy set had six Win-OS/2 disks, while the set on the CD has seven. Sadly the data on the physical Win-OS/2 floppies is gone, so I can’t compare the contents. There’s no real doubt that if not functionally identical, they were very close.

In any case, the OS/2 V2.1 Technical Update confirms that the “pre-release” OS/2 floppies (excluding the separately installable Win-OS/2 3.1 update) are in fact OS/2 2.00.1, which is exactly what the SYSLEVEL output also indicates.

For reference, OS/2 2.0 shipped with kernel revision 6.307, the 2.00.1 update with 6.427, and XR06055 with revision 6.466. Various pre-releases and OS/2 2.1 betas had different kernel revisions. That’s something for another time.

This entry was posted in Archiving, IBM, Kryoflux, OS/2, Pre-release. Bookmark the permalink.

30 Responses to Archival Puzzles

  1. Nathan Anderson says:

    Can we presume, even though the images themselves are not bit-for-bit between those on the CDs and the actual factory floppies due to the different order in which the files were written to the diskette, that the actual files present within each image are bit-for-bit identical between each other? The file count, names, sizes, and (other than the volume label entry itself) timestamps all look the same.

  2. I do remember that the GA having a 16bit graphics syslevel being a “big deal” that was going to be addressed with 2.1 and was in the xr6100 update. Although I don’t recall it ever making any big difference. Did the GA let you use 1.2/1.3 display drivers? I had CGA back then which was amazing that it even worked. I did later get an EGA card which was a welcome improvement.

    I think it’s the developer connection CD’s have a bunch of betas on them but I don’t recall anything all that exciting, although the first few ones have full products for the TCP/IP so things like X11 and NFS.

    I can’t imagine it being that surprising to find a Windows 3.1 beta support for 2.0, which would then have made it to the 2.1 GA. There was some thing about 3.11 being released thereafter that broke 2.1 for Windows and the eternal cat and mouse with Win32s and Warp.

    In retrospect IBM should have just let Microsoft use their Windows on OS/2 software and dump the idea of Presentation Manager. Instead it just gave Microsoft the proof of concept of how to build Win32. It must have been earth shattering in that 1991 joint meeting when NT OS/2 was demod and IBM realised that they had dumped cruiser.

  3. Michal Necasek says:

    Yes, the files are in fact 100% identical, just in different order. Basically it looks like the floppies were created, then the files were copied off somewhere else, and then new floppies or floppy images were created from those files.

    It may or may not be a coincidence that the same PDK CD also contains all the individual installation files because it is supposedly possible to install the OS/2 2.00.1 set from the CD.

  4. Nathan Anderson says:

    One minor correction: it’s not XR06605, but XR06055. XR06055 numerically comes before XR06100 which was “ServicePak 2” for 2.0, which shipped after 2.1 did in 1993.

    I know, I know…IBM didn’t always get sequential version numbers correct…there was the whole 6.605 thing — which might be how you mixed up the syslevel for 2.0 SP1 come to think of it, heh — and then the weird bit where 2.00.1 apparently lists its own syslevel as XR02010 (which is same as 2.1 GA) instead of the more logical XR02005 (claimed by some IBM docs). But in this case, they got it right.

  5. Michal Necasek says:

    Thanks, I fixed the XR06605 -> XR06055 thing. I just can’t read.

    And yes, 2.00.1 lists its SYSLEVEL as XR02010, same as 2.1, the difference is the “previous” CSD level (XR02000 for 2.00.1, XR02010 for 2.1).

  6. Michal Necasek says:

    I think by 1991, IBM and Microsoft were so thoroughly fed up with each other that it barely mattered.

  7. I haven’t been able to find it again but I used to have 2.0 on a CD-ROM. I just remembered that it was white., and all the art work was black. It had the diamond logo and I think it just said OS/2.

    I don’t know why, but I used it on a lot of machines instead of Warp, when I didn’t care about running Windows.

    I haven’t seen any one else have one since

  8. Michal Necasek says:

    Could it have been 2.00.1? The distinction wasn’t exactly obvious.

    I think I’ve seen similar CDs, though I’m pretty sure it was OS/2 2.1, not 2.0. Have to check if I can find one.

  9. Nathan Anderson says:

    Jason, I’ve never ever ever seen OS/2 2.0 at retail offered on CD-ROM. So if you actually have one, I’d love photographic evidence. 🙂

    Though there are some sources that list an IBM U.S. part number for such a thing (old versions of Tim Sipples’ OS/2 FAQ v2.0), I can find no evidence of its actual existence.

    Furthermore, in the OS/2 2.1 Technical Update document that Michal linked to in his post, Table 31 on page 300 shows only 2.1 (at least officially) is installable from CD-ROM, and in multiple other places in the document, it is strongly suggested that 2.1 is the first version to have such a feature:

    page 6: “Installation from CD-ROM – OS/2 2.1 can now be installed from CD-ROM. This is a major improvement, and can save much time and energy.”

    page 17: “Although installation of OS/2 2.1 from diskette is fundamentally similar to installation of OS/2 2.0, there are enhancements and special features, and a new CD-ROM alternative has been provided. […] Differences in OS/2 2.1 installation from OS/2 2.0 include: • Installation of OS/2 2.1 from CD-ROM”

    later on the same page: “OS/2 2.1 introduces the ability to install from CD-ROM.”

    THAT SAID! Michal has mentioned both in the past and in this article that he has an old IBM OS/2 PDK CD (pre-dating DevCon) that has a 2.00.1 build that’s installable from CD. This despite the fact that the table on page 300 of that document suggests otherwise.

    I also have a restore CD for an IBM PS/2 Ultimedia system that contains a copy of OS/2 2.0 GA (XR02000, March 1992) which installs from CD. The installer bootstrap is custom and very clearly made to only work with an actual PS/2 system, but I was able to modify the bootdisks to get it to install within a VirtualBox VM. As far as I am aware, this is the only CD-based install variant of actual 2.0 GA that exists in any form.

    IBM was clearly toying around with CD-ROM install even before 2.0’s final packaging; there were releases of OS/2 2.0 betas that were apparently released on CD-ROM in limited quantities by IBM Europe for their European DAP (Developer Assistance Program) in late ’91 / early ’92. This likely means it was the LA release. Apparently there are different variants of the Ultimedia restore CDs as well: one that predates the one I have and is the 2.0 LA, and another that was shipped with systems purchased later in the year and which contains 2.00.1. Crazyness.

  10. Michal Necasek says:

    Do you have any idea if those 2.0 betas were actually installable from CD, as opposed to having been delivered on CDs in the form of floppy images? That might be unclear if “beta on CD” was mentioned in passing somewhere.

    And yes, IBM was clearly working on installing from CDs before 2.1, and there were working examples, but noting provably “released” before 2.1.

  11. Nathan Anderson says:

    Michal, good question. I assumed it was installable from CD given the context, which was a discussion that started off with griping about all of the pains of doing an install from so many floppy diskettes where just one imperfectly-magnetized sector can derail the entire installation. It was a Usenet thread: https://groups.google.com/g/comp.os.os2.misc/c/F6g8JySDrLo/m/EgoHSvbeekoJ

    I also found this article, which is kind of odd since it talks about “spring 1993” and then goes on to describe the development of the PDK disc that I think you have & have been referring to: https://technologyevangelist.co/about/stories/first-ever-os-installed-from-a-cdrom/ But of course the timelines don’t really match up here. For one, spring 1993 would have been just before 2.1’s release, which of course we all know is installable from CD-ROM (and this certainly wasn’t a last-minute development). For another, the PDK with 2.00.1 came out in autumn of 1992. And finally, there were installable-from-CD releases of the Ultimedia load of OS/2 from spring 1992. So…I really am at a loss for what this article is talking about. At best, I’m guessing that memories just aren’t as sharp lo these many years later.

  12. Michal Necasek says:

    The Usenet discussion is pretty vague. They could have been talking about distributing the OS on a CD-ROM and making floppies from that — I suppose the advantage would be that one bad floppy doesn’t kill everything.

    The article definitely does not add up, the PDK came out in 1992. However if it had started with “spring 1992”, it would make a lot more sense.

    I can confirm that “Scott Schweitzer ([email protected] or just SCHWEI at WATSON)” was active on OS/2 discussion forums in July-September 1992 and talked about PDK CDs. I could not find any discussion about installing OS/2 from CD-ROM prior to 2.1, even though that PDK CD clearly could do it with OS/2 2.00.1.

  13. Nathan Anderson says:

    Well the original poster didn’t want to make floppies from a CD, he wanted to be able to “XCOPY” an entire OS/2 system directory structure from a CD to a hard drive. The respondent who mentioned the European OS/2 beta on CD, though, may not have been directly addressing that. He didn’t really say either way.

    Yes, the article would make *more* sense if it said “spring 1992”, but would make perhaps arguably *even more* if it said [any season] *1991*. The IBM Ultimedia System CD 1.0 came out spring ’92 but was mastered before that in preparation for the M57’s release, as we know from this February 1992 presser from IBM which plainly says the first version of the CD contained OS/2 2.0 LA on it: https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/9/897/ENUS192-059/index.html&lang=en&request_locale=en

    (you can check out the screenshots of the final install from somebody who has both the 1.0 CD as well as an M57 machine to install it on…it’s definitely the LA: http://www.supervinx.com/OnlineMuseum/IBM/8557/M57slc/)

    Perhaps the blog headline is just purposefully hyperbolic, but if it’s really claiming that the OS/2 included on the autumn 1992 PDKs was the “first ever OS installed from CD”, well, it missed that claim to fame by at least 6 months. (Not to mention there were other shipping OSes distributed on CD before OS/2…SunOS apparently had its first CD release with 4.1.2 in December 1991. But blog author could argue that “first ever x86-PC OS installed from CD” was implied.)

    I have the 1.00.1 pressing of the M57 System CD, which came out only a month or two later (kinda funny that IBM didn’t just wait…) and was updated to contain OS/2 2.0 GA instead. The boot diskette contains an installer response file/script (OS2SE20.RSP) and RSPINST.EXE which in turn loads 2.0 GA straight from the CD to the hard disk, so it’s a little different than a “retail” style install, but as far as I’m concerned it still counts as counts as an “OS Installed From [a] CD”.

  14. Michal Necasek says:

    Wow, IBM shipped 2.88M floppies with the M57. Good times. The OS/2 boot floppy says it needs CD P/N 41G8370 but I don’t see that in the photos anywhere, that’s odd?

    There is a difference between “preloading” from CD-ROM and “installing” from CD-ROM. I don’t know how many people back then distinguished the two cases but nowadays a restore CD is not understood to be the same as an OS install CD.

    I wonder if the Ultimedia OS/2 CD was done independently and differently from the PDK CDs. Hard to say without having a way to see what was on the Ultimedia OS/2 CD and especially on the boot floppy.

  15. Nathan Anderson says:

    There is often such a fine line between “preloading” and “installing” that it can be hard to judge between them. Heck, Microsoft has basically switched over to an installation system for Windows for the past decade+ that strongly resembles a preload (with their .WIM images). In this case, IBM even avoids calling it a “Restore” CD and instead calls it a “System” CD.

    I had not previously taken a close look at that OS/2 Installation Diskette until you pointed it out…

    The software set I have only came with 1 CD and 1 (ED) floppy. The floppy in question is the Ultimedia Installation Diskette, also pictured in that gallery. Whatever the equivalent of that OS/2 Installation Diskette is, I don’t have that (nor whatever its accompanying CD is). The Ultimedia Installation Diskette, however, is paired with the System CD. When you boot off of the diskette, it’s just like booting off of a regular OS/2 Installation Diskette except that since it’s an ED disk, they’ve managed to cram the Installation Diskette + Diskette 1 onto a single disk, so there is no prompting to swap to disk 1. (They also purged all of the non-PS/2 drivers from the disk, such as the various *01.SYS files, IBM1S506.ADD, and IBM1FLPY.ADD, to squeeze some additional room out of it.)

    After the usual OS/2 logo + copyrights and “Loading, please wait…”, it chains off to an intermediary custom Ultimedia installer instead of the regular OS/2 one. This installer will partition the drive only if it hasn’t already been partitioned, and will format the first primary partition (as FAT, since it’s intending to lay down a dual-boot setup) also only if it hasn’t been. It then “installs” things in the order of DOS, then Windows 3.0, then OS/2. For DOS and Windows, my examination has led me to conclude it is simply copying files over and then laying down the DOS boot sector afterward, but for OS/2, it runs the standard OS/2 installer in “response file” mode (technically it’s a separate executable, RSPINST.EXE, instead of the usual SYSINSTx.EXE, but the ability to modify Diskette 1 to install via a response file using RSPINST instead of a series of prompts also exists in retail OS/2).

    After OS/2 is done installing, the Ultimedia installer then copies over extra Ultimedia-bundled apps. The Ultimedia installer itself has a plain-text config file, separate from the OS/2 installer’s response file, that guides this process. So it’s not merely laying down a monolithic image to the hard disk.

    If you boot the Ultimedia Installer on a system that has an installation already on it, rather than give you the choice to do the equivalent of what today would be called “restore to factory default” (completely wipe the disk and reload everything from scratch), instead it only offers to allow you to either uninstall or re-install DOS, Windows, or OS/2 *individually*! So if you don’t want a dual-boot system and want to free up some hard drive space, you can selectively uninstall whichever OS you don’t want. But then you can boot the Ultimedia installer later and re-install that same OS without reformatting. If you want to force its hand to do a complete from-scratch reinstall of everything, though, you have to exit to an OS/2 command prompt and manually reformat the hard drive yourself!

    (I found a Flickr with a screen capture of the installer offering the removal options on a machine that’s already been installed, here: https://www.flickr.com/photos/peterl/albums/72157650264746479)

    At no point does the Ultimedia installer check to make sure that you are installing this suite to the proper model of machine. The only thing preventing one from installing to just any old PC is lack of drivers, but those can be easily added to the boot floppy in the normal fashion (delete unused drivers to make space, copy the ones you need over, edit CONFIG.SYS); in this way (+ a quick edit to the OS/2 installer response file, to tell it to install VGA instead of XGA video drivers), I got it to install within VirtualBox just fine. I have even managed to split it out into 2 separate HD floppies in the usual Installation Diskette -> Diskette 1 fashion (which was needed when I tried to do the install to an emulated PS/2 in 86box, since the only MCA machines it had profiles for were Models 70 and 80, neither of which had 2.88 floppy support).

    On the CD itself, OS/2 2.0 code is in the expected location for installing from CD, HDD, or network (OS2SE20 with the various DISK_## subdirectories).

    Sadly, there is no .DSK image of the Ultimedia Installation Diskette present on the System CD. So if you lack the boot diskette, you’re kind of screwed. And boy oh boy was that ED diskette a pain to deal with…I did not own a 2.88 drive, so it was quite an adventure first hunting down a reasonably-priced used one, and then second finding a machine that I could *actually* use it with. But that’s another story for another time, and what’s important is that I finally managed to image the darn thing.

    Circling back around to that OS/2 2.0 Installation Diskette you pointed out…the IBM announcement for the M57 does say this:

    “The OS/2 (R) delivered on the Ultimedia compact disc (CD) is the limited availability edition of OS/2 Version 2.0. […] The PS/2 Ultimedia M57 SLC customer is entitled to the update to the OS/2 Version 2.0 general availability edition at no additional charge. The registration card in the OS/2 Version 2.0 limited availability edition documentation provides complete information for the user to obtain the update to OS/2 Version 2.0.”

    This makes me wonder if, rather than shipping a whole updated Ultimedia System CD, a special, standalone OS/2 2.0 GA on CD-ROM was sent out to these early customers who claimed their copy, and perhaps this installation diskette belongs with that.
    Wouldn’t that be interesting! (I mean, I certainly don’t see them shipping out the upgrade in the form of nearly 20 diskettes to owners of a machine whose fancy new CD-ROM drive was a headlining feature.) Too bad we have yet to see the actual CD.

    The 1.1 version of the System CD that includes OS/2 2.00.1 and Windows 3.1 is available on archive.org, here: https://archive.org/details/ibmultimediacd-roms — it looks like IBM expanded the amount of bonus software by that point, since there is more than just the one CD now. Unfortunately, whoever uploaded this DIDN’T IMAGE THEIR INSTALLATION DISKETTE ARGH.

    I can also provide a copy of my 1.00.1 diskette and CD, and I’m gearing up to take some time in the coming weeks to put in a serious effort to *finally* get some of this stuff properly imaged and uploaded to places like IA and such.

  16. Michal Necasek says:

    I found that archive.org Ultimedia thing, but couldn’t spot any OS/2 files on any of the ISOs. Did I just miss that?

    From what you’re describing, the Ultimedia CD is really a lot more like a restore CD, although a somewhat clever one. The PDK OS/2 2.00.1 installer is different, it is a true CD-based OS/2 installer. There are two 1.44M (or actually two 1.2M) boot floppies, after that the CD kicks in and the normal OS/2 installer starts, only without prompting you to swap floppies. So I’d say the claim about the PDK having the first CD-based installer for OS/2 is not wrong.

    Microsoft’s NT betas from around the same time had CD installers too, although the early ones were incapable of installing on a clean hard disk, something the PDK had no problem with. If we go by official release dates then OS/2 2.1 was still out before NT 3.1. The PDK might really be the first CD-ROM based installer of a released PC operating system.

    I’ve had the awful “now I have the installation CD, but no floppy to boot from” experience a couple of times. Solaris did that (floppies in the box but no images on the CD), I think maybe even some misguided Linux distros did. IBM interestingly always had the floppy images on the CD, and IIRC Microsoft did too with NT — or if there weren’t images, there was at least a utility that created the boot floppies.

  17. Nathan Anderson says:

    You must have just missed it somehow. OS2SE20 is right there on IBM_UCD_101.ISO.

    Interestingly, on this 1.1 CD on archive.org, *I’m* now just noticing something myself: directories PRLD_1 and PRLD_2. These don’t exist on my 1.00.1 disc. PRLD clearly stands for “Preload”. Maybe these are just here because, as you’ve noted before, 2.00.1 was only released to OEMs as well as used by IBM internally for preinstallation on their PCs, and perhaps these are supposed to be the contents of the floppies that ship with such a system whose job is to kickstart the re-install of OS/2 from the restore partition on the hard disk.

    (While it seems that other PS/2 systems — especially those that did *not* have a CD-ROM drive — that shipped with OS/2 preinstalled used such a scheme, I’ll note that at least on 1.0 and 1.00.1 versions of the Ulti System CD, no such partition is ever created by the installer. The restore partition stuff must not have come into being until OS/2 2.00.1.)

    Heh, I guess we will have to agree to disagree about whether at least the older versions of Ultimedia Installation are, in fact, a CD-based installation of OS/2. From my perspective, the Ultimedia installer shells out to the OS/2 installer, which sources all of its files from a CD…I’d call that installation from CD. 😉 Only after a standard install is completed and control is returned to the Ultimedia installer does it sprinkle some customization pixie-dust atop that install.

  18. Michal Necasek says:

    Thanks, I did miss that, I was thrown off by the “Ultimedia Applications” label.

    So this looks like OS/2 2.00.1 (need to double check SYSLEVEL) but it’s not the same that was on the PDK CDs. The release on the PDK CD is revision 6.427 (92/06/03), whereas the Ultimedia CD is 6.454 (92/09/21). It looks like they used some more or less random internal build for the Ultimedia CD. Actually the revisions are all over the place on the Ultimedia CD, the drivers are also revision 6.452 and 6.346 at least. The PDK release consistently shows revision 6.427 in drivers and DLLs.

  19. Nathan Anderson says:

    So in addition to leaving out both the Ultimedia Installation Diskette image and the ISO for the Nautilus disc (even though they provided a JPG for it), the *other* other sin that the uploader committed was mixing up the picture files for the Applications CD and the System CD. The IBM_ACD_101.ISO is in fact the “Applications CD” and the IBM_UCD_101.ISO the “System CD”…it’s the JPGs that are swapped around (IBM_ACD_101.JPG has a picture of the “System CD” contained in IBM_UCD_101.ISO and vice-versa). That is undoubtedly what led to your confusion. 🙂

    That’s interesting that the 2.00.1 build doesn’t match between the PDK and the Ultimedia 1.1 CD, and furthermore that the Ulti one seems to be a mish-mash. I just noticed that the 10/92 PDK disk is also up on IA (https://archive.org/details/IBMOS2ProfessDevKitBeta), so it might be fun to install both the 2.00.1 build from PDK and the 2.00.1 build from Ulti 1.1 and compare them side-by-side. (Though I don’t anticipate very many surface-level details will be readily apparent.)

    That no Ultimedia Installation Diskette is provided with the Ulti 1.1 ISO on IA shouldn’t end up being an impediment to installing OS/2 itself…lack of that diskette will just prevent one from installing the whole suite (DOS + Win31 + OS/2 in dual-boot with custom Ultimedia add-ins) in one go using the custom Ulti installer front-end.

    Earlier today, I successfully installed a non-Ultimedia-ized OS/2 2.0 GA while using my Ulti 1.00.1 CD as the source for the install, inside VirtualBox and standalone on an HPFS partition, thus proving that 2.0 was not that far off from being able to install from CD-ROM out-of-the-box. This is possible because 1) the files in the OS2SE20 directory are indistinguishable from the files on the 2.0 GA retail 3.5″ diskettes, and 2) the standard SYSINST2.EXE attended installer already had a feature that allows one to redirect it to source the installation files from any arbitrary but valid path, so you don’t need to resort to a response file in order to install OS/2 from something other than floppies. This feature was put there to allow for sourcing installation files from a file server over a LAN, but it works equally well for redirecting it to look at any source…even a CD.

    See page 105 / chapter 8 in the IBM Redbook for “OS/2 2.0 Remote Installation and Maintenance” for details (http://www.tavi.co.uk/os2pages/pdf/gg243780_OS2_V2_0_Remote_Installation_and_Maintenance.pdf — there’s even a mention about CD-ROM install and about the Ultimedia M57 System CD specifically at the end!)

    OS/2 2.1’s installation from CD feature clearly leans heavily on this remote install feature of the installer and just builds on it / tweaks it slightly. For the CD install version of Diskette 1, CONFIG.SYS sets OS2_SHELL environment variable to “SYSINST2.EXE D:”. This would seem to guarantee failure if the CD-ROM drive is enumerated as some drive letter other than ‘D’, but there’s also a CDROMINST environment variable that gets set in CONFIG.SYS and that is checked by SYSINST2 (confirmed by searching through the 2.1 EXE), so I imagine that plays into how it behaves.

    What I did was take plain-jane OS/2 2.0 GA Installation + Diskette 1, added IDE CD-ROM drivers to Diskette 1 (which turns out to be a bit tricky…the 2.1 + Warp ATAPI drivers actually do work with the 2.0 GA kernel, *provided you are booting from a hard drive*, but for some reason if you load the exact same driver when booting 2.0 GA from floppies, it TRAPs…so I substituted in the XR06100 kernel & loader on the diskettes which worked around that problem), and set OS2_SHELL in CONFIG.SYS to “SYSINST2.EXE D:OS2SE20”. Without the extra support in 2.0 GA’s SYSINST2 (undoubtedly triggered by the CDROMINST variable I saw on 2.1) for auto-locating the CD-ROM drive letter, this didn’t work unless I had FDISK’d the hard drive in advance with a single partition in order to ensure that the CD-ROM was assigned ‘D’ instead of ‘C’. But it did work after that, and installed an indistinguishable-from-retail copy of 2.0 GA direct from the CD!

    (The only other problem I ran into was that although it copied the driver files to the hard drive, the installer did not properly add BASEDEV statements for OS2CDROM.DMD or IBMIDECD.FLT in the CONFIG.SYS file used by the GUI stage of the installer…even though it did copy over the IFS=CDFS.IFS line, which makes this omission even stranger. So after the text-mode stage was finished, I had to re-boot from the installation disk, escape to a command prompt, edit C:CONFIG.SYS to add those lines, and then allow OS/2 to boot from the hard drive after that to allow the GUI install to finish.)

    Now that I’m thinking about it, installing 2.00.1 from the newer Ulti System CD could probably be accomplished simply by booting from the same diskettes that I make from the images provided on the PDK CD…hmmm…

  20. Michal Necasek says:

    Ahh, so the ISOs on archive.org are mislabeled. Good, that means the IBM labeling was not crazy 🙂

    The PDK OS/2 install is definitely, shall we say, optimistic — if the CD isn’t where the installer expects it to be (D: drive I guess), the installer goes into some kind of a loop, there’s no error recovery. And yes, that PDK CD on archive.org should be the right one (I have my own but it looks the same).

    It makes sense that if the IBM installer was able to install over the network, it should be relatively easy to make it install from CD. But clearly not too easy, because the installer still needs to make sure the CD is accessible after booting from hard disk.

  21. @Nathan sadly it’s been well over a decade since I’ve had the CD in my hands. I don’t think it was retail I got it at one of those 90’s CD-ROM hut things in the $5 bin or something to that effect. I just remember the silkscreen being white, and looked unlike any other OS/2 CD-ROM id ever had, but going through the install process it was just 2.00 although I can’t remember much of anything else.

    I used to live in the Ft Lauderdale/Miami area and there was a lot of ‘IT’ fallout when IBM moved the OS/2 team to Texas for the OS/2 PowerPC deathmarch. Although as many IBM’ers I ran into NONE of them kept any of the betas or tools.

    In retrospect I should have taken a job at Citrix, it was those critical years when they were left in the lurch with Citrix Multiuser and they were scrambling for their ‘South Beach’ project a multi-user version of Windows NT 3.5

  22. Nathan Anderson says:

    Jason, I have a feeling you are talking about & recalling a special promotional pressing of OS/2 2.1 for Windows, and not 2.0. I don’t know who the intended recipients of this were nor why they merited a promotional copy, but it appears to be a fully-licensed copy, not a demo, and it was shipped out not in a box with printed manuals and such, but in a CD-sized cardboard sleeve with no floppy disks or other printed literature (save the EULA) included…you were expected to make the boot floppies yourself from disk images. So clearly this was cheap for IBM to produce (no manufacturing of huge printed manuals, no big boxes, no floppies, no license paid out to Microsoft for the copy because no included Windows 3.1, etc.).

    The CD looks very much like how you describe: rather than black text on silver (unprinted) with the OS/2 logo printed in a monochrome color (which could be either blue, red/salmon, or green, depending on the particular edition of 2.1 purchased) which is how most OS/2 2.1 retail CDs were, this copy was instead all-black (including logo) on white. Picture here (URL taken from os2world.com gallery wiki page): https://photos.google.com/share/AF1QipOHcSzGgcb4YRM9MK4I3MNefaU2rdvX433V4xfuHmts-ye5UttegEylmvgozhIOxQ/photo/AF1QipMDGbA4QfHYqcIlEKYvj72FoN9at3Xes7Z-w9A5?key=MjJSSWZ3UmZxaUlrb3JqWnhxMnA2SGxKaVNnOUdn

    (Fun fact: retail OS/2 2.1 for Windows CD labeling looked identical to other OS/2 2.1 CDs save for the green OS/2 logo and the IBM P/N. No mention of “for Windows” anywhere on the disc, unlike this one!)

    Michal, funnily enough, I recently stumbled back upon an e-mail thread between us back in 2017 where you mentioned the following:

    “Here’s another minor mystery. Later DevCons contain a set of OS/2 debug kernels. It’s a selection generally matching OS/2 releases. But there are a few that I haven’t identified:

    6.307 – OS/2 2.0 GA
    6.427 – OS/2 2.00.1
    6.454 – ???
    6.466 – ???
    6.514 – OS/2 2.1
    6.543 – OS/2 2.0 SP XR06100
    6.617 – OS/2 2.11
    8.162 – Warp 3 red spine
    8.200 – Warp 3 blue spine (?)
    S.624 – OS/2 2.11 SMP

    “It appears that the 6.466 kernel is from Service Pack XR06055 but I haven’t confirmed that yet. The 6.454 kernel is a bit mysterious because I can’t find any references to it except in APAR lists. It looks like it’s from September 1992.

    “Later: OK, confirmed that 6.466 is from OS/2 2.0 Service Pak XR06055 (Oct ’92). Still no idea about 6.454.”

    …well, I guess the mystery behind 6.454 has now been answered: this was the build used on the last version of the Ultimedia M57 System CD. 🙂 (And possibly copies installed on other PS/2 models and/or by other OEMs?)

    Expanding on my parenthetical above, I did manage to succeed in installing vanilla (not-OEM-customized) OS/2 2.00.1 from CD using both the October ’92 PDK as well as the Ulti 1.1 System CD as sources, though both of them had different issues during installation unique to each of them, interestingly. I’ll detail those problems later, but suffice it to say for now that there are aspects of the 6.427 build on the PDK disk that feel “unrefined” compared to the build on the Ulti disk.

    You also had this observation:

    “The PDK discs are extremely confusing. They call everything ‘beta’, even things that are ostensibly not. […] The OS/2 2.00.1 files look like the release too, the build level matches, and the timestamps do too I believe. There is 32-bit GRE, like there was supposed to be.”

    I’m now not so sure about this…based on my experiences during the installation, I wonder if 6.427 was in fact technically a beta (even if ultimately a very highly refined / close-to-release one), and 6.454 ultimately the version that got distributed to OEMs for actual inclusion with shipping machines. Probably the best way to ascertain this would be to get our hands on some other 2.00.1 OEM media samples to compare.

  23. Michal Necasek says:

    Yeah, the 2.00.1 questions are tough, because finding surviving media is so hard. All I can say is that the PDK version does not look like a random build at all, it’s all very consistent with nothing hinting at a beta. Then again, it would have been a very late beta so who knows. And yes, nice to find why the 6.454 kernel was a thing.

    I have one of those “promotional” OS/2 for Windows CDs, and I dare say my scan of it looks a little better. I too thought of that same CD when I read Jason’s description.

  24. Nathan Anderson says:

    The only thing giving me pause about the PDK build being a beta build is the fact that 6.427 is what’s published as the official 2.00.1 internal build # by IBM in their “OS/2 Warp Generation, Volume 1” document.

    I haven’t put the actual OS through its paces yet after installation, but there were some very obvious quirks/problems specifically during the GUI part of the install of the PDK build that raised eyebrows…things in the “this is so obvious how could this have been missed in a shipping version” category, honestly:

    I’ll capture some original screenshots later, but the top horizontal black border of the Transferring Files progress bar is just…gone. Completely missing. Either it’s not getting drawn, or something that is the same gray color as the dialog itself is painting over it. Very bizarre. This doesn’t just happen during initial installation, but carries over to whenever you run Selective Install later to add or remove features, so it’s clearly a bug (albeit merely a cosmetic one) in this particular build of the installer itself.

    The first screen you are greeted with during any 2.x installation is the initial choice of “Learn how to use a mouse” or one of three installation options (preselected features, all features, or let me choose). The second screen after that is “System Configuration” where you confirm or override the hardware drivers (mouse, keyboard, display adapter, etc.). And then finally at the end of install, right after you pick your printer and it installs printer drivers, it will then as the last step install the display drivers for the adapter you chose.

    Well, in the PDK build, not always but more often than not, after the installation has completely finished up, the “System Configuration” dialog will make a reappearance at the end right AFTER the display drivers finish installing! But then right in front of it, the “installation is complete…press Enter to restart” dialog pops up. Regardless of whether “System Configuration” re-launches or not, if you press OK or hit Enter at that point, all visible windows will clear, and then…nothing. It never restarts. You have to C-A-D (at which point the fully-installed OS does actually boot, thankfully).

    I mean I know that fit and finish is not always IBM’s forte, and that these are relatively minor things, but I just can’t fathom that this installer passed testing and got shipped this way. None of these problems are present in either the preceding version (2.0 GA) or in the 2.00.1 build on the Ultimedia system disc, so they’re regressions that happened after 2.0 shipped and that at the very least got fixed before the Ultimedia build shipped.

    That’s not to say that the Ultimedia install did not have its own problems…well, one glaring one, specifically: the installation of display drivers as the last step completely hangs and never completes (or even copies over a single file). I have a theory on this one, though: I note that on the PDK CD, every directory for the install source files is consistently named as they are throughout the entire CD (and network) installable era of OS/2: the same as the volume label of the corresponding diskette, with an underscore (_) standing in for a space (DISK_9, PMDD_2, etc.)…but with the weird exception that the display driver subdirectories are missing the underscores! They’re DISP1 and DISP2 on the PDK disc. However, on the Ultimedia disc (and every other OS/2 CD I’ve ever seen), it’s DISP_1, DISP_2, etc. as one would expect.

    Now, because there are no diskette images on the Ultimedia CD to kickstart a CD install of OS/2 (since it expects you to use the Ultimedia installer front-end which runs through a response file), I used the PDK boot diskettes to install this Ultimedia build. Even if the PDK build of the installer knows to look for a “diskette” named DISP1 etc. for display drivers, I don’t see exactly how that could have carried over to the GUI portion of the install since (as far as I know) the installer is unpacked afresh from the files on CD to the hard drive, not copied from the Diskette 1 floppy. But I suppose it’s possible the use of these diskettes are somehow involved.

    Working around this issue to get a working installation was interesting. Simply rebooting at this point leaves you with a system that absolutely doesn’t boot. I had to hunt down a process killer utility, open a command prompt window at the beginning of the install (thankfully an option), allow the install to proceed up until it hangs while trying to install the VGA driver, kill the hung DSPINSTL.EXE process, and then manually respawn DSPINSTL & go through the video driver install that way. One weird quirk, though, was that pointing it to the DISP_1 directory on the CD would cause it to come back with “cannot find file [email protected]”. There was a compressed DSPRES.DLL on Display Driver Diskette 1, but it was named DSPRES.DL_, and of course I can’t rename a file on a CD, so (*sigh*) I had to copy contents of DISP_1 to a temporary directory on the hard disk, rename DSPRES.DL_ to [email protected], and point the display driver installation to THAT location, and THAT WORKED. ¯\_(ツ)_/¯

    How CD-based installation works with 2.00.1 is a bit interesting. As expected, it is based on the source media redirection support in SYSINST2 that was originally built for doing installs over a LAN, but rather than modify SYSINST2 itself to specifically add support for looking for the CD-ROM drive as 2.1 did, SYSINST2 is essentially unmodified from 2.0 GA, and instead IBM built a shim utility, CDINST.EXE, that is set as OS2_SHELL instead. This utility determines which drive letter the CD-ROM was assigned and then merely runs SYSINST2 with the parameter “x:\DISKS”, where ‘x’ is the CD-ROM drive’s letter.

    And, yes, the PDK does stuff the OS/2 install source files on the CD in \DISKS for some reason, and yes, CDINST.EXE has “\DISKS” hard-coded in the EXE. (again, *sigh*) Which became a problem when I wanted to install from the Ultimedia CD, since its installation source files are in the much more orthodox location of \OS2SE20. So I had to change OS2_SHELL to instead launch SYSINST2 directly (as per normal) and hard-code in the D:\OS2SE20 path in CONFIG.SYS, as I had done for the 2.0 GA install.

    One nice thing I noted was that 2.00.1’s SYSINST2 fixes the bug that 2.0 GA’s had where it doesn’t copy over all BASEDEV entries from Diskette 1’s CONFIG.SYS to the temporary CONFIG.SYS that bootstraps the GUI part of the install. So I didn’t have to manually edit CONFIG.SYS after the text portion finished to add in the CD-ROM drivers. (You’d think this bug would have affected at least some network installs with 2.0 GA…)

  25. That promotional scan looks EXACTLY like it, other than it was 2.0xxxx

    Looking at the 2.10 it’s like it was added to the template after the fact, but that’s how I remember it.

    I remember hoping it would be full of all kinds of OS/2 stuff but I can’t remember anything which makes me think it was a bare standard install that once you make the floppies it just meant less disk shuffling.

  26. Nathan Anderson says:

    Well, it couldn’t have been EXACTLY like it except for the 2.xx version bit, since there was never a 2.0 “for Windows”, and the “for Windows” text takes up a fair amount of the face of that disc (and doesn’t look at all like the fuzzy “Version 2.10” bit). 🙂

    The printing of the “Version 2.10” text is that way because it looks like they used a printer that couldn’t do a “good” solid grey color. It got approximated with dots of black with space in between them (not unlike the stock desktop pattern on the original Mac!). I have other examples of IBM CD labels with grey printed in the same shoddy way.

  27. well obviously not for windows but defiantly in that style. Or my mind has totally lost it as it been 20+ years ago, and I just remember going thru the hell to make disks only find it was 2.0x

    I don’t even remember if I even installed from the CD, for all I remember it could have been some broken one with bad path names but good floppy images. I do remember it being quite unique as I never could find any other 2.0x on CD-ROM it was super rare.

    The OS/2 for Windows came in the black cardboard sleeves when they were trying to do some OS/2 logo like it was flight wings IIRC. They were giving it away like crazy but compared to Windows NT 3.5 which had networking, multimedia and dialup/lan TCP/IP it was so limiting.

  28. John Horvath says:

    I uploaded two additional ultimedia restore cds to the internet archive. One of them appears to have the limited availability version of os/2 on it. Also interesting is the read me document that explains the limitations of the LA version. I also uploaded images of the boot disks including beta copies. They are at https://archive.org/details/ibm-ucd-111

    These disks may help clear up some of the information in the comments above.

  29. Michal Necasek says:

    Cool, thank you! I’ll have a look at the images soon…

  30. Michal Necasek says:

    Yep, the M57 CD indeed has OS/2 2.0 LA (level 6.177) on it. What’s on the CD looks like unmodified 6.177, though they seem to have thrown in some updated printer drivers. The boot floppy is very custom and appears to be a Model 57 restore floppy more than an OS/2 installation boot floppy. That is, it can install (restore) OS/2, but it can also do lots more.

    The IBM_UCD_111 CD looks like it has standard OS/2 2.0 GA on it.

    2.88M floppy images are not seen very often…

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.