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.
I really think Windows 3 and therefore your Excel would have benefitted from a 386 (when equipped with 2M or more), even if it was only a slow SX. The whole memory management and even disk access (especially on WfW 3.11) on the 386 was just so much better. But… with only 1M RAM, it would not have changed at all, as that was not enough to start in 386 enhanced mode.
For EGA vs VGA… hmm, not much difference for an application I guess. As far as I remember, 16 colors were the “usual” Win 3 setting even on VGA cards, as it needed less memory and was a bit faster overall (but maybe that depends on the particular hardware and driver).
Producing a 386SX for starters, instead of the more prestigious (and premium-priced) 386(DX), I don’t know if that would have been a good idea. Yes, you’d have still somewhat better performance and more instructions than your old 286. Yes, you’d have the cheap existing peripheral and memory chips readily available. But it still would have to be more expensive than a 286, without being the (widely appreciated) milestone that the DX was.
Selling it at a loss? Hm, amortization of the development and cash flow for further new products surely also demanded the “premium first” approach.
Memory really was a huge problem. 386 software was bigger, and the page tables took space too… and the more RAM you had, the bigger the page tables had to be. 1MB was enough to get something like EMM386 running, but the benefit was questionable because by the time you got the memory manager going, there was nothing left for EMS/XMS.
Many developers found that replacing well written 16-bit code with 32-bit was not fun, the 32-bit code tended to be bigger and often slower. Which is why 32-bit ruled for porting of 32-bit software from other platforms, where the alternative was completely rewriting the whole lot. Plus, a lot of the 386-only software really needed a fast CPU to be usable at all.
This might be a dumb question, but do you need to have a page table with a 386 in protected mode? I would think that just have GDT/LDT and for each process just have a single descriptor for code and a single for data would be enough (plus descriptors for shared things, obviously).
Bonus question: Do you need to use the page table for all of memory, or can you use it for parts of memory? In particular can you just have a page table that covers the first 1M (or 1M+ 64k to emulate A20 switched off?) in order to run DOS 16-bit code with emulated UMB and/or EMS, but still not use the page table for protected mode code?
In practice something like OS/2 or Windows 3.x would use the page table anyways to be able to, ehh, page memory contents to/from disk.
(Gosh, this reminds me of the somewhat annoying know-it-all type of people who go on all day about that paging and swapping are different things…).
@MiaM
You can run either with paging off or on. There is no way to enable paging just for some of the memory or just for some of the tasks (unless you are willing to turn it on and off on every task switch). However, the ability to run DOS programs in parallel with protected mode applications is probably worth it
No, you don’t need to use paging in protected mode. But then you can pretty much forget virtual memory. With the 286 it was hard enough, but at least the segments had to be 64K max. On the 386 the segments were much bigger and doing segment-based virtual memory was completely infeasible. You also could not do multiple DOS boxes because that requires paging.
Paging is either off or on, so you can’t have some paged and some unpaged memory (sure you could run some code with paging and some without… and it would probably get really hairy really fast, and slow things down). And yes, paging was in fact highly desirable for virtual memory, which was a must back then.
Large pages can save a good deal of page table entries (and TLB entries) but those didn’t exist until the Pentium, and 2MB/4MB pages would not have been that useful in the late 1980s, as they would have been a bit too big for most purposes.