As previously mentioned, IBM’s OS/2 1.0 and 1.1 is extra unfriendly to modern hypervisors. To recap, there is a curious difference between IBM’s and Microsoft’s kernels in OS/2 1.0/1.1 with regard to mode switching.
For reasons that aren’t very clear, IBM’s kernels implement only 286 style mode switching: In order to get from protected back to real mode, the processor is reset and the BIOS told where to resume execution. On the other hand, Microsoft’s kernels have had (faster) 386-specific code ever since the first OS/2 SDK beta from April 1987.
To make matters more interesting, the OS/2 kernel is also famous for using the undocumented LOADALL instruction when running on a 286. Yet IBM’s OS/2 did run on 386 AT clones of the era. How is that possible?
The crucial ingredient is the BIOS. The 386 BIOS must support the 286-style mode switching, which is standard functionality. The same logic used for 286s also works in a 386 BIOS—all the BIOS needs to do is check a special flag and divert execution very early during initialization.
The less obvious component is LOADALL emulation. BIOS developers soon realized that a 386 can relatively easily emulate a subset of LOADALL functionality used by OS/2 and other software. In those cases, LOADALL is only used to adjust segment bases which can be accomplished by switching the 386 to protected mode, loading segment characteristics as directed, and then switching back to real mode. It took Intel several years to even acknowledge the existence of this technique, and it could hardly be called well documented, but it works on every 386-compatible processor.
IBM OS/2 1.0 in VirtualBox 4.3
VirtualBox 4.3 can finally run the historic IBM releases of OS/2 1.0 and 1.1. The following was tested on VirtualBox 4.3.8 running on a Mac.
It’s best to create a new VM from scratch. The guest OS type should be “Other OS/2”. RAM size should be set to 8MB (OS/2 1.0 blows up with more memory than that). For OS/2 1.0, disk size may be set to just 30MB as this version does not support partitions larger than 32MB (OS/2 1.1 no longer suffered from this limitation). The virtual disk should certainly be no larger than 500MB to avoid problems with BIOS/IDE geometry mismatch.
Before attempting to boot IBM OS/2 1.0 or 1.1, the VM behavior needs to be tweaked:
VBoxManage modifyvm <vm> --triplefaultreset on
Without this setting, the VM will terminate when OS/2 causes the CPU to triple fault. In the typical case, a triple fault is a fatal error indicating that the guest OS is beyond help, but with IBM OS/2 1.0/1.1, “crashing” the CPU is part of normal operation.
The OS/2 installation floppies of course also need to be patched, otherwise OS/2 will crash with division by zero. If everything worked, a screen like this should appear:
When initializing the fixed disk, an error may show up when performing a format:
If this occurs, use a bootable DOS floppy and format the partition which should already have been created; when the OS/2 installer is restarted again, use the existing volume rather than reformatting it again. It’s not clear whether this is a bug in the OS/2 installer or in VirtualBox.
The rest of the installation should be a matter of feeding the diskettes to the installer as directed, and accepting the largely sensible defaults. If everything went well, the VM will show the Program Selector a few seconds after the final reboot:
And just to show that yes, this is really IBM OS/2 1.0:
Note: On hosts without VT-x or AMD-V support, VirtualBox will complain that OS/2 guests require hardware virtualization. However, that does not apply to OS/2 1.x (but it is true of OS/2 2.x). The complaints can be circumvented by setting the guest OS type to ‘Unknown’ or ‘DOS’.
It would be interesting to know which other modern hypervisors (i.e. something able to run modern 32-bit and 64-bit OSes, rather than a 286 emulator), if any, are capable of running IBM OS/2 1.0/1.1. VirtualPC 2007, which is otherwise a very faithful representation of a real PC, is known not to run the old IBM OS/2 releases.
I like your articles about virtualization very much.
Do you know whether it is possible to use Linux with KVM to run OS/2 3.x?
I don’t know, sorry. And until kvm is shipped with Windows and OS X, I don’t care much 🙂
I was under the impression that KVM only emulated modern hardware and lots of old OSes would not work on it, but http://www.linux-kvm.org/page/Guest_Support_Status suggests that DOS 5 will run on KVM. Perhaps KVM supports anything that QEMU supports?
Wonder whether the LOADALL emulation is implemented in the BIOS or in the hypervisor itself.
Virtualbox doesn’t emulate a 286 so if there is any LOADALL emulation it’s going to be in the bios.
Also, to pat my own back a little, MESS runs every OS/2 1.x in the 286 emulation and 1, 2, 3 and 4 in the 386 emulation (PCem probably does too, though).
I couldn’t get my OS/2 2.0 running on KVM, and instead use Qemu.
Great stuff and it really works, thanks!
But how to get mouse support? Choosing Microsoft Bus Mouse seems not to work. I wasn’t trying to connect a real Microsoft Serial Mouse to COM1. If I remember correctly the serial port drivers from 1.0 were not without complications.
I usually steal MOUSEA05.SYS from MS OS/2 1.1. The problem with the IBM one is that it only works on PS/2 Model 30 (not on AT compatibles), if I remember correctly.
Thanks, it fortunately works this way. UNPACK MOUSEA05.SYS C:\OS2 from OS/2 1.1 disk 1 done, and after modifying CONFIG.SYS and rebooting I can now access the menu in Program Selector correctly which wasn’t working also with keyboard before. So now mouse operates in MS Word text mode as expected. I didn’t want to install DisplayWrite 5/2 (here in Germany called ‘PC Text’) for just editing some text files. So how about communications or networking. LAN Manager or LAN Server was first supported in OS/2 V 1.1. Can you give an advise for a working native OS/2 program beyond OS/2 C-Kermit 5A(190). I’m not sure if early Netware Requester from SFT Netware 2.1 provided needful support.
That’s a really good question. I have a feeling that by the time any usable networking software was done, it already required OS/2 1.1. That’s definitely the case with LAN Manager (and LAN Man 2.0 required at least OS/2 1.2).
From what I can tell, the Novell NetWare Requester also required at least OS/2 1.1 — apparently the issue was missing named pipe support in OS/2 1.0, and even some OS/2 1.1 releases (see InfoWorld, June 4, 1990, page S10).
I’ve had good experience using networking (TCPBEUI) with OS/2 1.3; it’s possible to talk to a modern NAS etc. It should have worked in OS/2 1.21 as well, but the AMD PCnet driver seems to require 1.3 for some reason.
Unfortunately I had the same experience with PCnet NDIS drivers. So my idea came to use Novell ODI drivers. But missing named pipe support cannot be a reason in this case. If you’re talking about Versions 1.2 or 1.3 of Netware Requester it’s definitely a requirement. DOS had no named pipe support and was supported by NetWare from early days. I only found this note from Novell here: http://support.novell.com/techcenter/articles/ana19930905.html – So I will have to dig into my old Netware disks.
Let me know what you find. From what I know, it took Novell quite a while to release a Requester for OS/2, so I’m a bit skeptical that they had anything really supporting OS/2 1.0.
Incidentally, I looked at LAN Manager 2.0 again and it seems I may be able to get it to work on OS/2 1.21, but there’s a big catch — it does not include TCPBEUI which makes it more or less useless on a contemporary network. Even 10 years ago it was very hard to work with NetBEUI only 🙂
Sorry, but I only found ‘Novell Netware Requester for OS/2 v1.3’ from March 1991 here on disk. Requester v1.2 released in May 1990 was the first one with full named pipe support. Requester v1.1 from July 1989 had limited named pipe support (Network World, June 14, 1989 page 2 and 48) and was a separate package for $200. And there was really an Requester v1.0 from early 1988 without named pipe support that could run with OS/2 1.0 SE – but also a separate product from Novell.
Hi Michal,
I’ve got it to run following your instructions!
http://i.imgur.com/MOrwnnu.png
For those having trouble with the Python script, search for “B8 F4 01 BB C8 00 F7 E3 F7 F1” with a hex editor. Replace “F7 F1” with “90 90”.
Nice!
I’m sorry for the off-topic, but I noticed a little mistake in your article about running OS/2 v1.x in Virtualbox. You wrote that OS/2 1.30.1 or higher will always install and work without patching, but this is slightly incorrect. I found a version of OS/2 EE which says that it’s version 1.30.1, build 7.220 from March 1991, CSD level WR05015. And it requires patching. It seems that the division-by-zero bug was fixed sometime after build 7.220, but before build 7.224 (June 1991), because the bug is not present in builds like 7.224MS, 7.229 etc.
Fair enough — if there are multiple 1.30.1 versions, they may behave differently.
I should’ve mentioned that I’m only aware of two builds used in 1.30.1 versions – build 7.220 used in IBM OS/2 EE (and maybe SE) 1.30.1 and build 7.224MS used in Lan Manager 2.1 and above. Build 7.229 (October 1991) is used in IBM OS/2 1.30.2, CSD level XR05050/WR05050. Build 7.224MS works without patching, build 7.220 doesn’t.
What is the CSD level for the IBM 1.30.1 build? (The CSD information in the MS builds is useless since it didn’t change between their 1.3 updates, so I’m not even asking). Right now I have just XR/WR05050 (1.30.2) and WR05000 (1.30.0) disks at hand.
Hmm, maybe it’s IBM’s 1.30.2 that doesn’t need patching and 1.30.1 still does.
I’m aware of the following variants of OS/2 1.3 (perhaps there are others, I don’t know)
IBM 1.30 EE, WR05000, build 7.84 (December 1990), needs patching
IBM 1.30.1 EE, WR05015, build 7.220 (March 1991), needs patching
MS 1.30.1 (LM 2.1x,2.2x), XR05015, build 7.224MS (June 1991), doesn’t need patching
IBM 1.30.2 SE/EE, XR/WR05050, build 7.229 (October 1991), doesn’t need patching
As we can see, the CSD level corresponds exactly to the 1.30.x version, therefore it’s useless even for IBM OS/2.
You mean that with IBM every point release has a different CSD level? Well, that’s a lot better than MS where several different releases have the same version and CSD 🙂
Yes, exactly. About MS, I’d guess that they forked the OS/2 code at build 7.224 and from that point on, developed their fork independently from IBM. As a consequence, the minor OS version and CSD level of MS OS/2 were frozen, probably to avoid name collisions with IBM. As we know, exery MS OS/2 1.3 version contains a file named LEVEL8.XXX, which uniquely identifies it. Therefore, there is no confusion.
Hi, again the mouse! Are there any mouse driver for IBM OS/2 VM? I know MOUSEA05.SYS from version 1.1 is ok with MS OS/2 1.0, but not works with the IBM version 1.0
MOUSEA05.SYS dated 8-08-88, 16,950 bytes, works for me in an IBM OS/2 1.0 VM.
Where did you find it? All 1.1 versions I looked for I found only MOUSEA05.SYS dated 02-20-89, 17462 bytes ( except beta versions that does not have this driver).
Looks like it’s from the MS OS/2 1.05 SDK (Aug ’88). The earlier 1.03 SDK (Mar ’88) did not ship MOUSEA05.SYS yet.
I can’t understand for the part patching the ibm os/2 1.0, im stuck in this part for couple of hours already still can’t figure it out how to patch the img file using the python script. Even i search others website too they didn’t told that how to patch the img file. Anyone can help me out?
@Bryan:
Replace “B8 F4 01 BB C8 00 F7 E3 F7 F1” with “B8 F4 01 BB C8 00 F7 E3 90 90” in Install.img with a hex editor.
@Bryan @Fifo: For posterity’s sake, it also seems to be the same hex sequence that needs patching in all versions of OS/2 prior to MS 1.30.1 and IBM 1.30.2. Only confirmed (as in, hex sequence adjusted as described and OS/2 successfully boots from the install floppy and starts installing) for MS 1.21, but given that the hex sequence shows up (the number of times it appears varies from 1 to 3; it seems to appear more often in the later releases) in the install.img images for all pre-M1.30.1/I1.30.2 versions of OS/2, and nowhere else, I’m feeling fairly sure that it’s the same he-who-must-be-patched in all of these.
On the other hand, this is on a fairly slow (by today’s standards; it’s a 1GHz AMD A6 Temash, but I don’t know exactly what he considered as “slow” when he wrote the earlier blogpost) host machine, using software emulation, and he did say in his earlier blogpost on the subject that even an unpatched install might sometimes succeed on slower hosts (I’m not sure what he was counting as “slow”, though).
On the other other hand, it did boot and install without throwing any errors, which is not the behaviour one would expect if I had edited the wrong hex sequence by mistake…
Add-on to my prior comment: the 1GHz AMD A6 Temash is the CPU. The machine itself is an Acer Aspire V5 laptop dual-booting Windows 8.1 and Ubuntu 16.10 (VirtualBox is running on the Windows personality).
And I did end up reinstalling it because I chose the wrong kind of mouse during installation, but that’s not exactly the kind of error/mistake that counts for the purposes of this discussion, now, is it? 😛
Also, VirtualBox
a) now has a specific type for “IBM OS/2 1.x”
and
b) recognises that 1.x does not require hardware-assisted virtualisation, no longer complaining about it for 1.x VMs on non-hardware-assisted-virtualisation-capable hosts.
Don’t know when this was added (I’m using VirtualBox 5.1.18).
“Slow” is defined as “slower (when emulating) than a circa 33 MHz 486” or whichever machines the problem first started popping up on in 1991 or so.
@Michal Necasek: Ah, thanx. 🙂
Also, in order to have VirtualBox mouse support in pre-1.30 OS/2, you have to not only manually copy the driver from a preexisting installation of 1.30 (copying it from the installation floppy containing it causes OS/2 to lock up during the boot process), but also modify the C:\CONFIG.SYS file (which is, fortunately, fairly straightforward, at least once you get it open in the OS/2 text editor) to tell OS/2 to load the newer driver instead of the one that was installed during setup. Since I couldn’t figure out how to open CONFIG.SYS in the text editor directly, I did this by copying CONFIG.SYS to a file named CONFIG.TXT, editing the requisite lines in CONFIG.TXT, and then copying it back over CONFIG.SYS.
In OS/2 1.2/1.3 it’s entirely possible to edit CONFIG.SYS with the GUI E.EXE editor. Perhaps not trivial without a mouse 🙂 Back in the day Microsoft had KB articles about editing OS/2 CONFIG.SYS to change the mouse driver, since some of Microsoft’s own mice were not supported out of the box.
For hardcore old-schoolers, there is always EDLIN in the DOS session.
>For hardcore old-schoolers, there is always EDLIN in the DOS session.
Yeah, well, I’m not very old-school. 🙂
Pingback: Ancient NetWare OS/2 Requesters? | OS/2 Museum