Years ago, feeling nostalgic, I had written a quick throw away thing about the old article from PC Magazine, 29th of May, 1990, detailing the coming future of Operating Systems, Microsoft OS/2 2.0. 14 year old me was blown away!

This release marks the last time that Microsoft would release an OS/2 beta to developers, instead with the runaway success of Windows 3.0, Microsoft would remove resources from the constrained OS/2, and refocus both on Windows 3.1, and Windows NT.

Thanks to one of my Patrons – Brian Ledbetter, the much-sought Microsoft OS/2 2.0 Pre-Release 2 is now available! So obviously the first thing to do was to re-create the original magical screenshot.

One thing of note is that thanks to some of the metadata left at the end of the disks we know when this disk set was made:

$FTIME = Wed Jun 22 09:00:56 1988
$DTIME = Tue Aug 15 07:48:10 1989
$PCTIME = Thu Apr 27 11:51:54 1989
$FREV = Wed May 31 09:17:24 1989
$DUP TIME = Fri Jul 13 16:02:27 1990

Given that the PC Magazine issue was published in May of 1990, it showcased version 6.43, shipped to devs early January of 1990, and timestamped 20/12/1989. I would speculate that it’s the Pre-Release 1.

This Pre-Release 2 set was made in July with the files being timestamped 01/06/1990, so physical releases every 6 months? I guess that makes sense when you look at how many disks have to be duplicated, boxed up and sent out. It’s one big win for digital downloads, or how Windows 10/11 can background download updates, or even entire OS updates (that are more like new installs) today. Mailing big heavy boxes must have sucked. And dealing with lost/damaged disks. Also as you can see on the box, it only contains 5 1/4″ disks, they didn’t even ship dual media.

Maybe the large box is a reaction to the first Pre-Release’s 16 disks & a few photocopied sheets mere 10oz. Maybe people were displeased that they didn’t get much printed ‘bang’ for their $2,600 – the price of the 2.0 SDK.

The disks were dumped with Kyroflux, and on several of the disks there is extra trailing information on the disks revealing data from when they were manufactured:

$TRACEBACK (tm) Ver 1.04
$OPER = operator
$STATION = 1
$STN LIST = 1 3 5 7 11 13 15 17 19
$WORKORDER = -1
$SYSTEM = 7
$PRODUCT = z:/product/110098449.p
$PTIME = ???
$FORMAT = /format/fmt12.f
$FTIME = Wed Jun 22 09:00:56 1988
$DRIVE = /drive/3xhd96sdsmt.d
$DTIME = Tue Aug 15 07:48:10 1989
$MODULE = /config/3xhdSDSmt.s
$MTIME = ???
$WINDOW MARGIN = 87.5%
$RETRY SETTINGS = 3,2,25
$FUNCTION = write/verify
$PRECOMP = /precomp/3xhdSDS.t
$PCTIME = Thu Apr 27 11:51:54 1989
$FREV = Wed May 31 09:17:24 1989
$DRIVESN =
$LOADERSN = 525-100-70
$DFCSN = 3402 SDSFC
$USTRING =
$TSTRING = TraceBack (tm)   (c) 1989 Trace Products All Rights Reserved.
$DUP TIME = Fri Jul 13 16:02:27 1990
$DISK NUMBER =  22 of 45
$SN = NONE

That’s right, this disk (Install 1) was manufactured on Friday the 13th!

Running strings against the DOSKRNL reveals this string:

MS DOS Version 4.00 (C)Copyright 1988 Microsoft CorpLicensed Material - Property of Microsoft

Not only is it a new OS/2, but a new MS-DOS! Neat!

 APPEND.EXE
 ASSIGN.COM
 COMMAND.COM
 EDLIN.COM
 GRAFTABL.COM
 JOIN.EXE
 SETCOM40.EXE
 SUBST.EXE

This is *NOT* a comprehensive version of MS-DOS 4.0. Then again anything to do with disks, you should be using OS/2. It’s more so commands needed for working inside the virtual MS-DOS environment. And yes, it doesn’t include any basic.

There is built in support for EMS, and there is an XMS driver, but it’s not activated by default. I didn’t bother trying Windows 3.0, but I did install Word for Windows, which has a runtime version of Windows 2.11

Trying to run the windows executable directly gives a weird error:

I went ahead and installed WLO, or the Windows Libraries for OS/2, and some things do run, and many more hang the system. I think its an issue in PM, and CAD (Control+Alt+Delete) does reboot the system.

It’s a shame Microsoft couldn’t get Windows as the UI to OS/2, it certainly would have had a far more viable lifetime. I’ve ranted about it before but IBM’s insistance of supporting the 286, releasing a $6,000 286 in 1987 basically ensured early OS/2 was facing the wrong direction technically, and by ignoring the existing Windows stack, it just delayed OS/2 being useful from the get-go.

Anyways…..

And running strings against the OS2KRNL reveals:

Copyright 1986 IBM Corp.
Internal revision 6.78, 90/05/09

And to further muddle the waters:

@(#)ldrste.c    13.125 90/05/09
@(#)ldrfixup.c  13.43 90/05/09
@(#)ldrsubr.c   13.116 90/05/09
@(#)pgset.c     13.64 90/05/01
@(#)selmgrc.c 13.76 90/05/01
@(#)vmalias.c   13.48  90/05/01
@(#)vmalloc.c   13.71 90/05/01
@(#)vmapi.c          13.50 90/05/07
@(#)vmfree.c    13.89 90/05/01
@(#)vminfo.c         13.33 90/05/01
@(#)vminit.c    13.60 90/05/01
@(#)vmshared.c 13.41 90/05/01
@(#)selkh.c 13.14 90/05/01
@(#)tklibi.c 13.42 90/05/09
@(#)inidin2.asm 1.86 90/04/27
@(#)selinit.asm 13.51 90/05/09
@(#)ldrinita.asm        13.47 90/05/09
@(#)selwrk.asm 13.51 90/05/07
@(#)vdmaa.asm         13.54 90/04/27
@(#)trap.asm    1.82 90/05/04
@(#)trap286.asm 13.43 90/05/04

If you were ever wondering what the names of the source was, here is the .c & assembly:

dbgee.c
dbger.c
dbgwp.c
dem.c
dyndto.c
dyndtr.c
em86.c
except.c
ldrgc.c
ldrinit.c
ldrmte.c
pgage.c
pgalloc.c
pgfault.c
pgframe.c
pginit.c
pgmap.c
selini.c
semalloc.c
seminout.c
semtools.c
semverif.c
semwrkr.c
smalloc.c
smsft.c
tkinit.c
tksleep.c
tkthrd.c
vdmapi.c
vdmctrl.c
vdmm.c
vdmmasrt.c
vdmmcrt.c
vdmmem.c
vdmmheap.c
vdmmisc.c
vdmpage.c
vdmprop.c
vdmtime.c
vmbmp32.c
vmdevhlp.c
vmkrh.c
vmksh.c
vmlocate.c
vmlock.c
vmob.c
----
demfile2.asm
demioc2.asm
demnls.asm
dhrouter.asm
dynci.asm
dyndtra.asm
em86io.asm
em86misc.asm
fsinfo.asm
gshare.asm
int.asm
kmodea.asm
ldrrsrc.asm
ldrrun.asm
monhigh.asm
npx.asm
pageio.asm
pga.asm
selmap.asm
selmgra.asm
selseg.asm
sftio.asm
sicg.asm
sig.asm
tkexit1.asm
tkmisc.asm
tkwksem.asm
vdhserv.asm
vmmisc.asm
vmname.asm

Neat!

I would imagine a lot of the v86 mode virtual device drivers came from Windows/386. But it looks like these were all written in C? Running strings against all the virtual device drivers reveals all C? I got zero hits for .asm

emm.c
emm1.c
emm2.c
emmctrl.c
vbios.c
vcmos.c
vcmosio.c
vdma.c
vdsk.c
vdskint.c
vdskio.c
vkbd.c
vkbdint.c
vkbdio.c
vkbdreq.c
vmbound.c
vmdevrq.c
vmevent.c
vmhook.c
vminit.c
vmlpen.c
vmmisc.c
vmpos.c
vmptr.c
vmrate.c
vmreset.c
vmstate.c
vmuser.c
vpic.c
vtd.c
vtdint.c
vtdio.c
vtdreq.c
xmm.c
xmmctrl.c

It’s not like any of this is ever going to see the light of day, but it’s all interesting, at least to me.

Let’s install!

I’ll have to update where I had found this, if it was the electronic documentation, or the one time I got to go through the printed documentation that the Microsoft version was adding True Type Fonts. Sadly I can’t find any evidence in the binaries.

OS/2 System Monospace Fonts
OS/2 Courier Fonts, (c) Copyright 1988 Microsoft Corp., Portions Copyright 1985 Bitstream, Inc.
OS/2 Helvetica Fonts, (c) Copyright 1988 Microsoft Corp., Portions Copyright 1985 Bitstream, Inc.
OS/2 Times Roman Fonts, (c) Copyright 1988 Microsoft Corp., Portions Copyright 1985 Bitstream, Inc.

  "PM_Fonts"           "SYSMONO"            "C:\OS2\DLL\SYSMONO.FON"
  "PM_Fonts"           "COURIER"            "C:\OS2\DLL\COURIER.FON"
  "PM_Fonts"           "HELV"               "C:\OS2\DLL\HELV.FON"
  "PM_Fonts"           "TIMES"              "C:\OS2\DLL\TIMES.FON"

Well, that’s sad.

As I had touched on earlier, These early OS/2’s have no user accessible way to call the legacy 16bit OS/2 API’s. At best you have simple text mode stuff, anything graphical, you need to port to Presentation Manager.

I was able to take the GCC port I did to OS/2 and re-link the objects ,and I was correct, it ran without any changes! I had compiled it using the December 1991 Windows NT Pre-Release’s CL386 compiler. So far so good.

I tried to use the 1991 compiler to build Sarien, and it instantly crashes. I also tried building everything but the Presentation Manager with GCC, and again instant crash. I was able to use the OS/2 2.1 v1.2 DDK, and get a working EXE, even using /Ox (maximum optimisations!). Clearly there is something fundamentally missing or I’m missing something fundamental.

While there is a HPFS installable filesystem, there is no CD-ROM IFS. Running strings against HPFS reveals this much when looking for C. There was no hits for .asm

execioh.c: calling strat2 with PIOH=%p
execioh.c: returned from strat2 with PIOH=%p
qdiskop.c: entered, ioh=%p lsnStrt=%lu csec=%u pbData=%p
unlckio.c:entered, pioh=%p
unlckio.c:retheaping lock handle %p

Even more strange, is that HPFS for OS/2 was still 16bit. I had hoped that even though this is a beta, that there would be a 32bit version of the filesystem. Sadly that kind of feature was reserved for Lan Server installs.

HPFS.IFS: MS-DOS executable, NE for OS/2 1.x (DLL or font)

Could you imagine shipping a 32bit filesystem to home/low/middle tier users today? Speaking of, let’s check the rest of the C:\OS2 binaries:

ANSI.EXE:     MS-DOS executable, NE for OS/2 1.x (EXE)
ATTRIB.EXE:   MS-DOS executable, NE for OS/2 1.x (EXE)
BACKUP.EXE:   MS-DOS executable, NE for OS/2 1.x (EXE)
CACHE.EXE:    MS-DOS executable, NE for OS/2 1.x (EXE)
CMD.EXE:      MS-DOS executable, NE for OS/2 1.x (EXE)
CREATEDD.EXE: MS-DOS executable, NE for OS/2 1.x (EXE)
E.EXE:        MS-DOS executable, NE for OS/2 1.x (EXE)
EAUTIL.EXE:   MS-DOS executable, NE for OS/2 1.x (EXE)
FDISKPM.EXE:  MS-DOS executable, NE for OS/2 1.x (EXE)
FIND.EXE:     MS-DOS executable, NE for OS/2 1.x (EXE)
HELPMSG.EXE:  MS-DOS executable, NE for OS/2 1.x (EXE)
MAKEINI.EXE:  MS-DOS executable, NE for OS/2 1.x (EXE)
MOVESPL.EXE:  MS-DOS executable, NE for OS/2 1.x (EXE)
PATCH.EXE:    MS-DOS executable, NE for OS/2 1.x (EXE)
PICICHG.EXE:  MS-DOS executable, NE for OS/2 1.x (EXE)
PICPRINT.EXE: MS-DOS executable, NE for OS/2 1.x (EXE)
PICSHOW.EXE:  MS-DOS executable, NE for OS/2 1.x (EXE)
PMCPL.EXE:    MS-DOS executable, LE executable
PMEXEC.EXE:   MS-DOS executable, LE executable
PMFILE.EXE:   MS-DOS executable, LE executable
PMSHELL.EXE:  MS-DOS executable, NE for OS/2 1.x (EXE)
PMSPOOL.EXE:  MS-DOS executable, LE executable
PSTAT.EXE:    MS-DOS executable, NE for OS/2 1.x (EXE)
REPLACE.EXE:  MS-DOS executable, NE for OS/2 1.x (EXE)
RESTORE.EXE:  MS-DOS executable, NE for OS/2 1.x (EXE)
SORT.EXE:     MS-DOS executable, NE for OS/2 1.x (EXE)
SPOOL.EXE:    MS-DOS executable, NE for OS/2 1.x (EXE)
SYSLOG.EXE:   MS-DOS executable, NE for OS/2 1.x (EXE)
TRACE.EXE:    MS-DOS executable, LE executable
TRACEFMT.EXE: MS-DOS executable, NE for OS/2 1.x (EXE)
UNPACK.EXE:   MS-DOS executable, NE for OS/2 1.x (EXE)
VIEW.EXE:     MS-DOS executable, NE for OS/2 1.x (EXE)
VIEWDOC.EXE:  MS-DOS executable, NE for OS/2 1.x (EXE)
XCOPY.EXE:    MS-DOS executable, NE for OS/2 1.x (EXE)

The vast majority of them are 16bit. The 32bit stuff is in the defunct LE format. This is why nothing from the GA (General Availability) versions will ever run on these betas, and why I was trying to make stuff available as linkable objects. And yes, my Sarien port is LE:

SARIEN.EXE: MS-DOS executable, LE executable

There is a LAN client disk set, so I guess you were expected to just go across the LAN.

The SDK & Toolkit for this beta have been around for a substantial time. The big difference is that we now have binary compatibility so we can run ALL the examples, namely the Open Dialog demo.

We take this kind of thing for granted today, common controls, but back in the early 1990’s this was a surprisingly lacking from many UI’s of the time. Since these beta DLL’s use a different format, this won’t run on the later betas, let alone the release. So, this is for those looking for secret hidden stuff.

Is it usable though? Well if your workload is OS/2 applications, ABSOLUTELY. If you want to do cute stuff on MS-DOS.. It’s all YMMV, but traditional apps seem to behave pretty well.

It’s a shame for some reason that overall, these early OS/2 2.0 betas were not all that wide spread, as they are just so interesting! And compared to the GA version of OS/2 2.0 these ancient versions with the 1.x Presentation Manager do feel a lot faster. Sometimes I miss the Workplace Shell, Other times I miss the old terrible Desktop Manager with its incredible simplification.

For those just wanting to mess with the Operating System, it really is a developer’s release so it’s pretty spartan. Sadly there is no XGA drivers in these early betas, there is 8514/a support but I had no luck with it. I suspect it’s probably something I had done wrong. I should also point out, if you are using 86Box, and are using a 486DX/Pentium be sure to enable the softfloat option.

Maybe a math co-processor really was a hidden requirement of these early OS/2 betas? So, perhaps more confirmation that buying an 80387 was NOT a waste of money. I should also add that when trying to compile PHOON, I did have to use /FPi87 or inline 8087 instructions, otherwise instant crash. I had thought it was a mixed FPU mode crashing the linking of GCC+MSC code but I tried a few combinations, none of them worked.

Once more again, I want to thank my Patrons for making this possible, and a big thanks to Brian Ledbetter for being so kind to preserve this incredibly rare, and historically significant software kit.

I’ve made my VMware image available, and 86box.