After almost 30 years, several disks with ancient builds of OS/2 surfaced. In this context, “ancient” means older than the May 1987 release of the first MS OS/2 SDK. In fact these disks are so old that the one thing that cannot be found on them is any mention of OS/2 whatsoever.
For clarity and simplicity, the operating system on these disks will be referred to as “proto-OS/2”. Why not just use whatever name the OS referred to itself as back then? Because there were too many! The naming was so schizophrenic that it’s impossible to choose.
Just the easily visible messages refer to CP/DOS (or CP-DOS), ADOS, and DOS 5.0; ironically, DOS 5.0 is shown by the so-called 3xBox, the real-mode DOS compatibility session, although DOS5 was used to refer to the new protected-mode environment. Sometimes references to 286DOS and MTDOS (multitasking DOS) can also be found.
The name “OS/2” was apparently chosen by IBM only very shortly prior to the April 2, 1987 official announcement. Up to late March 1987, it was never used to refer to the product, at that point for nearly 2 years in joint development by Microsoft and IBM. But even then the development didn’t start from scratch and proto-OS/2 was derived from Microsoft’s (real-mode) multitasking DOS, eventually released in 1986 as “the other” DOS 4.0.
The available disks are from October 1986 and January 1987. They show a clear progression from multitasking DOS 4.0 to OS/2 1.0 as it was released in late 1987 (the oldest proto-OS/2 build predates the release by more than a year).
Let’s take a look at what was or wasn’t in these proto-OS/2 builds. The kernel consisted of IBMBIO.COM (later known as OS2LDR) and IBMDOS.COM (later known as OS2KRNL) just like in real-mode DOS, but these were “new” segmented executables (NE signature) and included protected mode support. Unlike later releases, but like real-mode DOS, all core drivers (keyboard, disk) were built into IBMBIO.COM. Like later releases and unlike real-mode DOS, proto-OS/2 had minimal reliance on the ROM BIOS at runtime and managed hardware itself.
At the same time, there were loadable drivers such as COM.SYS (serial port support), MOUSE0x.SYS and POINTDD.SYS (mouse support), or VDISK.SYS (RAM disk).
Proto-OS/2 supported roughly the same protected-mode API as the final release of OS/2 1.0 and was similarly split into multiple components implemented as dynamic libraries. These did not yet use the DLL extension and were named EXE instead. There is for example DOSCALL1.EXE, KBDCALLS.EXE, or BVSCALLS.EXE. Needless to say, this was rather confusing naming because these modules could not be run (“DOS1059: An EXEC failure occurred.”). The DLL extension was only introduced in April 1987.
Like the released OS/2 1.0, proto-OS/2 required at least a 286. Even in the October 1986 build there is a small amount of 386-specific code, evidence of Microsoft’s close relationship with Compaq and Intel (maybe too close—see below). Note that the Deskpro 386 was only introduced in September 1986.
Proto-OS/2 supported pre-emptive multitasking and multithreading, not standard OS features at the time. Since it was a 16-bit OS, it could handle up to 16 MB of physical memory (24-bit address space) and implemented memory management with segment swapping. There was a simple task switcher triggered by the SysRq key:
SysRq was more or less the equivalent of Ctrl+Esc in OS/2 1.0. There was no analog to Alt+Esc for directly switching between sessions.
Like later OS/2 versions, the proto-OS/2 kernel could be compiled with a built-in debugger. The debugger is very similar to the released versions, but very spartan: it does not even understand symbols!
There was a single DOS session usually called 3xBox (providing a DOS 3.x compatible environment). Note that this build predates even DOS 3.3 (1987) and is an analog of DOS 3.2.
There was error handling very similar to OS/2, with a special “hard error pop-up” session:
The protected mode shell, CMD.EXE, was very similar to COMMAND.COM from the user’s point of view. One notable addition was the DETACH command which could be used to launch a program in the background. No such concept existed in DOS.
There are almost no surviving utilities but it is expected that proto-OS/2 came with familiar tools like FDISK, CHKDSK, SYS, or FORMAT.
Sizzle
Some of the surviving disks from early 1987 show a curious boot screen:
“Sizzle” was what would nowadays be called a development branch of OS/2. It was a project to assess and improve the performance of OS/2. For a few months it was maintained separately from the ‘mainline’ OS/2 1.0 development.
One of the Sizzle disk includes a kernel debugger. That makes exploring the internals of proto-OS/2 considerably easier, even if the debugger cannot load symbol files and the user must manually refer to a map file.
Running Proto-OS/2
After almost 30 years, running proto-OS/2 is… challenging. There is a number of obstacles for both real and emulated/virtualized systems.
The first issue is graphics. On physical systems equipped with a VGA, proto-OS/2 will produce a blank screen. It simply does not work with a VGA (hardly surprising, since it predates the VGA!), although it is not entirely clear why. It does work with EGA, or a VGA card which can be switched into EGA mode. In an emulator it is likely to work with a VGA as a side effect of not quite true to life emulation.
The next issue is the keyboard. Proto-OS/2 uses the SysRq key as a session manager hot key. It is also new enough to support enhanced 101/102-key keyboards (where SysRq behaves differently), but uses a flawed method of detecting them. If the Num Lock state is on at the time when proto-OS/2 boots, the keyboard is considered to be an enhanced 101/102-key model. Otherwise it is assumed to be the original 84-key PC/AT style keyboard. If the keyboard type is not correctly detected, it will not have much effect on normal operation but SysRq will not work due to proto-OS/2 expecting the wrong state of the Alt modifier.
Another issue is the CPU itself. Proto-OS/2 works on 286 and 386 processors. On anything newer, it cannot start the DOS session (3xBox) and may occasionally not even boot up. The reason is a bit surprising: 386 LOADALL. It is well known that OS/2 1.x uses the LOADALL instruction on 286 systems in order to access extended memory from real mode, but even the May 1987 beta version of OS/2 simply switches to protected mode and back on 386 and later CPUs.
In proto-OS/2, on 286 CPUs the 286 LOADALL instruction is used and on 386 CPUs, the similar but incompatible 386 LOADALL instruction is used instead. This is evidence that Microsoft was a recipient of confidential Intel information.
What that means is that proto-OS/2 will only run on 286, 386, or IBM 486DLC (386 core) processors. It can be however tweaked to run on many newer systems by forcing it to think it’s running on a 286. In that case it will use the 286 LOADALL instruction which is emulated by most BIOSes. The system also needs to support 286-style mode switching with a triple-fault reset. With a modification to force 286 behavior, proto-OS/2 can run e.g. in VirtualBox, but it won’t run on Virtual PC for example.
All screenshots were taken on VirtualBox with adapted BIOS which provides rudimentary emulation of 386 LOADALL; that way there is no need to modify proto-OS/2 to make it think it’s running on a 286.
History
It is fascinating to see how historical material is surfacing after decades. Proto-OS/2 was mentioned in contemporary press (e.g. InfoWorld on Sep 15, 1986 in an article called “Microsoft Developing 80386-Based Windows; Firm Details 286 DOS Plans”, or Jan/Feb 1987 Programmer’s Journal in an article called “286 DOS Cometh”) but the software itself was never disseminated outside of Microsoft, or only provided to a very small number of OEMs, even though it was shown to journalists and potential customers.
Proto-OS/2 captures a snapshot of OS/2 development where the product is clearly recognizable yet noticeably different from the 1.0 release. It was Microsoft and IBM’s effort to reshape PC software, and although it ultimately failed, it had a major influence on the evolution of PC operating systems.
Many thanks to pcjs.org for providing these disks.
any chance you can release the floppy images? 😀
Never mind, they’re here http://www.pcjs.org/disks/pc/os2/misc/
“It was Microsoft and IBM’s effort to reshape PC software, and although it ultimately failed, it had a major influence on the evolution of PC operating systems.”
Some of it still lives in NT (even now in 2016) :-). Some of it short lived in Win9x family as the IO supervisor (Dragon), as you pointed in earlier articles. The way how VDMs were handled inspired new software writters to write hypervisors, and now it lives, at least as inspiration, in products like HyperV or XEN. *nix also received inspiration bits from OS/2. Projects that never materialized, but were the starting point of 20xx software products, like Taligent, OS/2 for PPC etc.
I think it was probably the IBM PS/2 that finally forced them to separate the drivers from IBMBIO.COM, right?
I found out that the version returned by INT 21 function 30 is also 5.0 (there is a SYMDEB on the SIZZLE debug boot disk).
Either that or MS OS/2 OEMs wanting to customize OS/2 without having to rebuild the ‘BIOS’.
I mean, for example disk was separated into DISK01.SYS and DISK02.SYS with the floppy and hard drive driver still in the same file.
Yes. NT is definitely a heir of the DOS and OS/2 legacy. Not in code or internal design but in philosophy.
Thinking about it, the decision to change NT from “NT OS/2” to Win32 probably came first, then the decision to create Chicago/Win95. It was Chicago/Win95 that caused most of the problems, including the dependence on DOS that allow Caldera to continue the lawsuit.
Which shows that MS probably should have considered the decision more carefully back in 1990 (DR-DOS for example already existed).
MS decision was the correct one. Caldera lawsuit did almost nothing to stop MS, and in these old times PCs were still underpowered to run NT + a VDM emulator to run the still numerous DOS software titles and existent DOS based bussiness systems. Win9x filled that gap well enough until PCs became powerful enough, and NT PnP WDM system was ready.
In any case, to me Win95 was stable enough, providing that you had the correct set of VxD drivers for your hardware. Win98SE introduced a big problem with WDM drivers, which basically needed an MiniNT kernel+HAL running on top of the VMM kernel to manage them, which could conflict with the existent VxD drivers in your system… So you had to choose between having a VxD driver only system with OnNow/ACPI/WDM disabled, or having a system with only WDM drivers, with no VxD/DOS realmode drivers, but OnNow/ACPI/WDM enabled. Ofc USB has been always a WDM driver, so you had to use PS/2 mouse/keyboard and disable the USB support to have your VxD only system, which was faster, stable and DOS friendly, but without all the new stuff.
When I said Chicago/Win95 caused most of the problems, I am in particular comparing it to OS/2 2.0 of course.
Well someone went off topic. Back on topic, does CP-DOS support PS/2 systems or only ATs ? Also what is BVSCALLS ? I recall OS/2 having functions starting with DOS, KBD, VIO and MOU.
Odd that it would use 386 LOADALL, lazy programming perhaps ? It’s no surprise that Microsoft was a recipient of confidential Intel information, I’m guessing they got pretty much everything and were likely the first to get it.
Only PC/AT and clones I think. Notice even VGA is broken.
@dosfan: BVSCALLS is the basic video system with BKSCALLS same for keyboard and BMSCALLS same for mouse while KBDCALLS, MOUCALLS, and VIOCALLS are the entry points for programming. Renamed to DLLs and with some adjustments in development, all 6 pieces remained in OS/2 1.x and 2.x before being turned into simple forwarders in Warp with the actual work all done in a combined DOSCALL1.DLL. DOSCALL1 was supposed to be smaller and faster. Frankly, I am surprised that any part of the proof of concept preliminary design remained largely intact through production and several later versions.
386 LOADALL is the obvious solution to the problem that had been handled by 286 LOADALL. Takes time to learn that other instructions can yield equivalent results.
These builds of CP-DOS predate the PS/2 announcement and contain no PS/2 support whatsoever. I don’t know how this was handled but it’s entirely possible that IBM was working on PS/2 support on their own for a while and merged the changes back only after the PS/2 platform officially came out.
As for 386 LOADALL, yes, it was lazy programming, but it’s exactly as Richard says. The Intel document describing 386 LOADALL even contains a section titled “Emulating 286 LOADALL with 386 LOADALL”. So I’d say Microsoft did what they’d been told by Intel. By May 1987 the 386 LOADALL was gone from OS/2.
You mean “VGA isn’t sufficiently backwards compatible with EGA to handle proto-OS/2” 🙂 Obviously VGA didn’t exist when this code was written.
So yes, AT compatibles only, notably including the Deskpro 386.
VGA was definitely in development by 1986 though.
The real excitement to me is football/pigskin. Of course adding DPMI was a big deal, but it really shows how cruiser (OS/2 2.0) was built out of OS/2 1.0
Are this version OS/2 Alpha based on Multitasking MS-DOS 4.00 in 1985.
Some of the ideas used in “CP-DOS” came from it, but not much else I think.
Do this version OS/2 work with VirtualBox or you need PCem to run this build.
“Based on” sounds too strong. “Derived from” would be more accurate. It’s like the next version of “mtdos”, kind of like multitasking DOS was itself the next version of classic DOS. Multitasking DOS 4.0 did not have threads, protected mode, up to 16 MB address space, etc. There are clear similarities but also big differences.
It won’t run in VirtualBox without minor patching. I have no idea if it runs in PCem, but it definitely works in PCjs. See article text for what the hardware requirements/restrictions are.
Perhaps the IBM’s designer of the BVS should know about / https://sites.google.com/site/stjones/detailedresume
FYI, for folks interested in playing with these disks, I finally added a complete client-side solution to PCjs for downloading them: just load a disk into a machine and then click the Save button. You can even make changes to a disk before saving it.
I’ve also made it easier to download and embed entire machines; that feature is a bit more bleeding-edge, may be browser-sensitive, and may not work with all machine types.
Details in the latest PCjs blog post.
Very cool. Thank you 🙂
Pingback: Playing Football | OS/2 Museum
Thinking about it, it is funny how OS/2 had to fix the problems of the DOS driver model one at a time. Ultimately if MS/IBM actually worked together and OS/2 2.x replaced DOS/Windows, I think a 32-bit dynamically loadable PDD model would have to be created at some point after OS/2 2.x.
It’s funny what IBM supported without dynamically loadable (or 32-bit) drivers. PCMCIA, USB…
Thinking about it, I assume that most users of S-100 systems were technical users who know for example how to modify the CP/M BIOS code, right?
Thinking about it, it probably boils down to people who worked on multitasking DOS 4.0 and probably never designed a 286 protected mode OS before being asked to design such an OS that was to be finished in a year.
MS Xenix 286 was a protected mode OS. I am not sure if any programmers moved from Xenix to the non-Unix protected mode OS project but the knowledge of how to access hardware from protected mode was documented. There were also some efforts to create methods to help DOS programs run on Xenix. MS was positioned to leverage two years of work to quickly generate a working prototype.
Xenix 286 was just a port of another operating system though.
Xenix 286 was a port, but the kernel was really a rewrite. The System III kernel was not all that modular. It is unclear how much work Intel did on the 286 Xenix, but Microsoft definitely had an example of a working protected-mode OS there. How much they looked at it is a different question.
As far as I can tell, Microsoft developers were definitely influenced by Xenix/UNIX, see C compiler, make and later NMAKE utility, various homegrown grep tools and similar. It is also well known that the Xenix C compiler/assembler/linker supported generation of DOS executables and this feature was presumably used internally at Microsoft.
But OS design influence was minimal except the DOS 2.0 period where Microsoft’s stated goal was to get DOS and Xenix closer to each other. For Windows 1/2/3 and 9x the systems were just too different. With NT the designers actively disliked UNIX and made a few blunders because of it (security design, cough).
Reading Letwin’s Inside OS/2 it is apparent that the designers knew UNIX but only occasionally used it for inspiration (hierarchical file systems, signals/Ctrl+C). In several areas (multithreading, dynamic libraries, GUI) OS/2 was also well ahead of UNIX and the designers had little choice but invent their own solutions. But in general, OS/2 was definitely designed as the next version of DOS (which is why it was called Advanced DOS, 286 DOS, or DOS 5.0) and not some kind of UNIX clone. The core developers like Mark Zbikowski were DOS-heads.
Pingback: Antes do OS/2 ser OS/2 | Retrocomputaria
The first EGA clones only came in 1986. OS/2 1.0 was released in 1987. On the other hand, I suspect that cheap Hercules clones were common even in 1986.
Thinking about it, I wonder if it was ever considered to save the high half of 80386 registers and use 386 TSS segments for example given that this build of CP-DOS already had a lot of 386 code.
https://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter “The first EGA-compatible board was Vega in December 1985, released by Video Seven and using C&T’s chipset.”