The lost history of PReP: Windows NT 3.5x and the RS/6000 40p

The following is a guest post by PA8600/PA-RISC! Thanks for doing another great writeup on that PowerPC that was going to transform the industry!.. but didn’t.

The history of the PReP platform from IBM is quite interesting, not only because of its place in the history of Windows NT but also the history of the PowerPC architecture in general. When the PowerPC platform was new, IBM (just like a few other vendors, notably DEC) had grand plans to replace the x86 PC  clone market (they helped create) with PowerPC. Of course thanks to various factors such as Apple’s refusal to play along, the launch of the Pentium Pro CPU (and the later Itanium disaster), and high cost, this plan never ended up panning out. Later IBM PReP machines were designed for AIX and Linux use only, and they were sold as regular old RS/6000 computers.

Still, Microsoft being Microsoft and willing to port their OS to literally anything hedged their bets and made MIPS, PowerPC, and Alpha ports of Windows NT (along with a PC98 release for Japan only). In the guest post about Solaris for PowerPC I made, I talked about the history of IBM’s PReP platform some more so you should go read that post if you want an initial rundown on PReP’s flaws and history. But I have learned a bit about the Windows NT port for PowerPC, and I discovered a rare version of it as well. By now everyone with a PReP machine (or PPC Thinkpad) has run Windows NT 4.0 on it, and if PReP machines are emulated it’s guaranteed this will be the second most run OS on it aside from AIX of course.

IBM also made a half-baked OS/2 port for PowerPC as well, and then there’s the previously mentioned Solaris port. All of these are rarities and it’s worth documenting. With how rare PReP machines are and their high prices on eBay when they do turn up for sale (or their tendency to be snapped up fast), I think it’s fitting to write perhaps the most in depth look at PReP hardware that anyone has seen.

Windows NT 3.51: “The PowerPC Release”

It’s commonly accepted that Windows NT 3.51 was the first release for PowerPC hardware and it was even called this within Microsoft. Featuring HALs for most of the early PReP machines including the Moto Powerstack, the rare FirePower machines built for NT (which used Open Firmware), the Power Series 6050/70 (and maybe 7248), and the unobtanium IBM 6030, it’s pretty much what you’d expect for a first release for PPC. It’s a polished, solid OS that’s arguably faster than NT4 on the same machine. Aside from the red boot screen (on my Weitek GPU), it’s pretty much Windows NT 3.51 but on the PowerPC. It’s like running NT 3.51 on MIPS or Alpha, it’s interesting but more software will likely run on 4 anyhow (especially on Alpha).

One interesting quirk of Windows NT for PowerPC is it does not report the CPU type of your machine. It simply reports “PowerPC” and what machine you’re running it on. It does not tell you that you’re running it on a 601, it tells you that it’s running on an IBM-6015.

Unsurprisingly Visual C++ 4 works on PowerPC Windows NT 3.51 as well. This is no shock, Visual C++ 4 was designed to work on 3.51 as well as NT 4.0. The same goes with many of the pre compiled programs. One advantage Windows NT 3.51 offers over 4.0 is that it is simply faster than 4.0 on the PowerPC 601.

There’s not much else about Windows NT 3.51 for PowerPC quirk wise that hasn’t been said elsewhere about NT 4. It runs in little-endian mode (one of the few PPC OSes to), it has 16 bit Windows emulation that’s slow, and it needs specific PReP machines to run. One interesting series of articles about the “behind the scenes” of the port worth reading is the Raymond Chen article series, and this discusses the quirks of programming a PowerPC 60x CPU in little-endian mode as well. It can be installed with the same ARC disks NT4 uses, and of course the same SMS and firmware disks will work. In fact QEMU at one time was capable of booting the IBM firmware image from these disks.

Here’s something I’ve found out from research however. There was actually a limited release of Windows NT 3.5, it’s been dumped, and it is a real operating system. It also requires a very specific model of RS/6000 to work, and one with a interesting history giving it a unique place among the PReP machines. While I was unable to make it work in the end, I did discover and document a lot of interesting features of PReP machines.

Enter Sandalfoot: The IBM 7020/6015 (and demystifying PReP machines)

To understand the HCL and weirdness of Windows NT for PowerPC (and why it won’t run on Macs), we need to take a look at one such machine it runs on. This is my RS/6000 40p, a machine that was given several brand names by IBM and used as a development platform for PReP software and operating system ports. This is also perhaps the most historically significant RS/6000 model from the era. While it wasn’t the first PowerPC RS/6000 (that honor goes to the 250), it was the first to use the PCI and ISA busses and it was a few months ahead of both the initial PCI PowerMacs and other PReP boxes. It’s also one of the few true bi-endian machines as just like other PReP machines, the MIPS Magnum, HP’s Integrity, and modern Power8+ machines it has OSes for both endians available.

In 1994 (presumably October 28, if the planned availability date is correct), IBM released the RS/6000 40p (announcement letter here, codenamed Sandalbow) and the Power Series 440 (codenamed Sandalfoot). Both are near-identical machines with different faceplates and boot screens. The RS/6000 ranged in price from around $4,000-6,000 and was designed to be an entry-level AIX workstation, bundling a copy of AIX with each machine. As an AIX machine it’s relatively slow and fits the entry-level badge quite well, but thanks to the 601’s POWER instructions it served as a transition machine over to the later 604 AIX machines. Unlike the later PowerPC 603 and 604 machines, it featured POWER instructions allowing it to run both legacy AIX POWER software and later PowerPC software. The Power Series was presumably sold to those wanting a PReP box for Windows instead.

Since IBM PReP hardware is so obscure and undocumented, I’m going to document this as best as I can being the owner of an IBM Model 6015/7020. The machine features a 66mhz PowerPC 601 (similar to that of the Power Mac 6100 and RS6K 250), PCI and ISA slots, and IBM’s “Dakota” PReP firmware (more on the boot process here). It uses an off the shelf NCR 53c810 SCSI controller, Crystal CS4321 sound chip, an Intel 82378 PCI bridge, and a NIC can be inserted into the ISA slots (mine has the famous 3com Etherlink III). The Super-IO chip is also off the shelf, and is a National PC87312VF. The clock IC is a Dallas DS1385S, a close relative of the Dallas DS1387 (with internal battery). At least some of the IBM custom ICs are the chipset ICs and those are also documented. A Linux 2.4 dmesg can be found here.

Mine is also maxed out at 192mb of RAM, however there are some solder pads for more and the chipset is limited at 256mb. This makes me wonder if the system was based on a reference design of some sort. There was an ultra-rare 604 upgrade as well, but considering how there are more 7248 and 7043 machines in the wild I can assume many customers just waited for that instead due to its superior AIX performance.

If the idea sounds familiar (off the shelf chips + RISC CPU) it’s because it was the very same idea used to create the two other non-x86 Windows NT platforms. The Microsoft Jazz MIPS platform most MIPS NT boxes were influenced by was infamously based on the same idea of a “PC with a MIPS CPU”. To a lesser extent, this was also seen on the DECpc AXP 150 and other EISA/ISA/PCI based Alpha machines designed to both run Windows NT and DEC’s own OSes. Crazy undocumented custom hardware and expansion busses were thrown out the window in favor of industry standards. In fact when I posted a photo of the motherboard to a chat full of PC nerds, they stated it looked remarkably like a normal PC motherboard. The whole industry would later adopt PCI and sometimes ISA on non-x86 machines to cut costs and reuse the same expansion cards.

The main difference between the RS/6000 40p and the Power Series variant is the boot ROM logo and chime. The RS/6000 and “OEM” systems used a boot ROM that featured the PowerPC logo and just a beep, while the Power Series machines featured a logo more closely resembling the PowerPC Thinkpads complete with the chime. One can boot firmware from a floppy as well by typing in the name of the ROM image in the prompt and pressing enter, and watching as it reboots once the firmware is loaded into RAM. Here’s a video I filmed demonstrating this, along with some other quirks including there being two SMS keys: F1 for a nice flashy GUI SMS and F4 for a text based SMS, along with F2 for netbooting (with the right NIC of course).

The Sandalfoot machines were LPX form factor machines, featuring a riser card and generic sheet-metal case popular with prebuilt machines from this era. The LPX form factor was wildly popular in the mid 90s due to its versatility, seeing use by both IBM and DEC for their RISC machines, various PC builders, and even Apple for the clone program and clone based Power Macintosh 4400. The Sandalfoot machines also drove home one of the core goals of the PReP project, which was to build a PowerPC platform using as many off the shelf and PC style components as possible instead of using lots of custom ICs like Apple did. I dug out one of my cameras to take a few high-res photos of the motherboard of this computer to illustrate this. Compare this to the motherboard of the Power Macintosh 6100 or even the 601 based 7200 and notice the bigger heatsink and use of fewer custom ICs (Apple loved those).

There were three main GPU options: the famous S3 Vision864, the Weitek Power 9100 (or P9100 for short) as a higher end option, and IBM’s own GXT150P. The S3 was the entry level GPU and the Weitek was a higher-end and faster GPU. The GXT150P is beyond the scope of this because it is unsupported on the other PReP OSes, only AIX. The other two video cards are essentially unmodified Diamond PC cards with the BIOS chips missing.

The Sandalfoot machines are perhaps the most important PReP machines due to their role in PReP OS development. Both OS/2 Beta 1 and Windows NT 3.5 were written for this machine in particular as it was one of the first PowerPC machines to support PReP and feature PCI/ISA slots, unlike the NuBus Macs released a few months earlier or the first PPC box: the MCA based RS/6000 Model 250. They also often shipped with the well documented and emulated S3 Vision 864 video card, a common GPU family in PCs of the time to the point where it was even included on some motherboards and emulated in too many PC emulators/virtualization programs to count (notably 86box/PCem). In fact it’s successor (the 7248) featured one soldered to the motherboard.

Windows NT 3.5: Failed Install Attempts

An oft repeated quote about Windows NT 3.5 for PowerPC is this one from Paul Thurrott’s Windows site:

Windows NT 3.51 was dubbed the Power PC release, because it was designed around the Power PC version of NT, which was originally supposed to ship in version 3.5. But IBM constantly delayed the Power PC chips, necessitating a separate NT release. “NT 3.51 was a very unrewarding release,” Thompson said, contrasting it with Daytona. “After Daytona was completed, we basically sat around for 9 months fixing bugs while we waited for IBM to finish the Power PC hardware. But because of this, NT 3.51 was a solid release, and our customers loved it.” NT 3.51 eventually shipped in May 1995.

I think a more accurate thing to write is that there simply weren’t many PReP boxes out in late 1994. Windows NT 3.51 supported the Motorola PowerStack series, the IBM 6050/6070 (and maybe the 7248, which came out in July 1995), and rare FirePower machines. Windows NT only features HALs for the 6015 (Sandalfoot/Power 440/RS6K 40P), 6020 (Thinkpad 800), and the 6030 (a rare IBM machine that likely was only sent to a few developers). By 1995, there were more PReP machines on the market and this made the NT 3.51 release logical. NT4 even supported a few servers, mainly the RS6K E20, E30, and F30.

Windows NT 3.5 was most likely a limited release for testing purposes on the Sandalfoot machine as it’s HCL file declares it as “Build 807” with a date of October 18, 1994. The date seems to be around a week or two before the first 40p machines at least shipped. Some more files were modified later on and the folders were created on November 9th, 1994. Hardware support is very barren, and the readme file even has a section dedicated to quirks of the 40p along with a list of supported software for the x86 emulator. This might have been considered a beta as well, as an announcement letter for the Thinkpad 800 (6020) explicitly mentions Windows NT and that this version might be a beta for developers. It also talks about a Windows SDK for it and a Motorola compiler used to build 3.5 software.

However the real problem for me has to do with getting a video card. Windows NT 3.5 for PowerPC does not support the Weitek P9100 GPU that came with many RS/6000 branded machines, and neither does OS/2 for PowerPC. It only supports the S3 Vision 864 and 928 video cards. It’s listed in the setup options, but choosing it causes a txtsetup.sif error. I’m going to assume that the development units came with the S3 video card instead. My box contained a Weitek card which works for AIX, Solaris, and Windows NT 3.51/4. I bought a card from eBay to use with NT 3.5 and the OS/2 port.

 The readme also features an ominous warning with the S3 video cards, that only revision B3 is supported and that 928 cards need 2MB of VRAM for anything above 256 colors. My revision of the card I ordered was B4, so I took the risk of seeing if it worked with my system. I also removed the ROM chip as the system initializes the video card itself and that having a ROM chip can cause the system to not complete the self-test or display video. As the IBM Weitek card lacks a BIOS, I did this.

Despite the scratches on the card from possibly coming out of an ewaste pile, the card worked fine in both a PC I inserted it in for testing purposes and the IBM system. I now had a 40p with a GPU much more well supported among non-AIX or Windows NT operating systems.

Anyhow, let’s talk about the install process in closer detail here. Windows NT for PowerPC installs in a similar manner to Solaris for PowerPC on the IBM PReP machines. First the floppy disk boots ARC, then when you choose to install it the machine copies the ARC bootloader/firmware to the hard disk so it can load it from there at each boot. The floppy disk can also be used to load ARC if the loader is damaged on the hard disk. Keep in mind, on IBM machines ARC is not stored in the ROM unlike on many other ARC capable machines so this has to be done. The Firepower machines do something very similar by using an Open Firmware shim, and unsuccessful attempts at emulating PPC NT have exploited VENEER.EXE to attempt booting instead of using the IBM firmware. It fails because they’re not emulating the hardware, just trying to find a quick way to just boot NT.

Once this is done, the installer loads up and installs just like every other NT install. It checks the HAL by reading the machine ID, what video hardware the machine has, and whatnot to prepare the installer. You need a IBM 6015, 6020, or 6030 according to the HALs it has and only the S3 video cards are on the HCL.

Or that’s what should happen. I first tried using ARC 1.51 as it worked for 3.51 and was greeted with a HAL error BSOD:

I first attempted to use older ARC boot floppies and I got somewhere, the BSOD changed to the classic 07b, and then I got nothing else. Using ARC 1.48 and 1.49 gave me this, I got some i/o error with ARC 1.46 (the first 3.51 ARC floppy), and any previous ARC floppy is most likely undumped. I’m assuming either the error is due to an ARC mismatch, a weird firmware mismatch/hardware revision mismatch, or some incorrect SCSI ID Solaris style. There might very well be some weird forgotten trick to making it work (maybe a Windows expert could dig through the files and find some weirdness), but I’m going to move onto another obscure PPC rarity:

OS/2 PowerPC Boot Attempts: Beta 1 and the Final

Recently the OS/2 Museum site dumped Beta 1 for PowerPC. It’s an earlier version of OS/2 for PowerPC that insists on a Sandalfoot machine with an S3 GPU. Unlike the other OS/2 PowerPC disc, it features a verbose boot featuring the kernel it uses. If you want to really see OS/2 for PPC working, try it on a 7248 or read this post about it.

This failed to boot, throwing up an error about mounting the disk or something. I did record it doing something at least however, an improvement over the Weitek which just does nothing at the PowerPC screen. I tried several things including removing the external SCSI CD drive and that didn’t fix much. It also declares 88c05333 an unknown PCI device.

So I decided to try the “final” build. The final build requires a 6050/70, and some people did get it working on the PPC Thinkpads. I decided to see what it’d do on my machine. Unsurprisingly it did absolutely nothing but give me a blank white screen and sometimes a 00016000 error (for a trashed CMOS). If anything the 6015 loves to trash it’s CMOS contents for absolutely no reason, especially when OS/2 is involved.

Anyhow this was very anti-climatic, as the OSes I threw at it found reasons to not work on it whatsoever.  I weeded out the GPU being at fault by testing Windows NT 4.0 and finding out that it works just fine with the GPU, however I seem to have fewer resolutions available than what the Weitek card allows. It did change the boot screen font, making me wonder if the red boot screen is a GPU driver quirk.

However changing the device IDs with OS/2 PowerPC Beta 1 got me somewhere, as I now got a screen about the HDD failing to write. I formatted the HDD to FAT using the ARC diskette, then I nuked all the partitions, but not much else changed. I’m not sure what the error means, but it was a letdown.

Unless these OSes require some long lost firmware, I’m wondering if there’s else that’s causing issues with installation. Either way, it was a letdown. Nothing I tried worked and I spent hours messing with everything from SCSI IDs to using different drives.

Remember to upgrade your SSD firmware!

I kid you not. I had this older SSD that would just lock up after a few hours of usage, no matter what OS I’d be running.  Resetting the machine would just hang as the SSD would just disappear from the computer!

Even a fresh install of Windows 10 would hang after the install, and while it was initializing itself with the “It’s taking a bit longer than expected, but we’ll get there as fast as we can” message!

Its taking a bit longer because the SSD crashed!

Unacceptable!

Well it turns out that these things have their own processors, operating systems and well they are not just passive storage devices but machines in their own right.

crucial SSD firmware updater

And in my case it turns out that my SSD was running version 9.  The latest version is version 70!

Needless to say, not only does the new version have a noticeable difference in performance, but more importantly it’ll run for hours now without crashing the SSD (which is what I imagine was happening before).

I can only imagine how long it’ll be, until there are user mode programs to load into storage, and when we cross the line with internet connectivity requirements, anti-virus and firewalls needed for storage.

YUCK!

So my old machine’s 16GB memory limit is becoming a problem

MacPro guts

And like a sucker I saw this 2010 MacPro for sale, $300.  It was running OS X 10.13 aka High Sierra, and I though oh cool it’s obviously able to run the latest OS, and even better with 32GB of RAM, and apparently the single processor model can go up to 48 or 64GB of ram giving me that breathing space I need.

So I happily get the machine, put in some new SSDs, and spinning disks, and decide that I’m going to split it up half for OS X, and half for Windows 10.  Sounds easy right?  And for the hell of it, I wanted to install a copy of 10.6.8 (Snow Leopard), since it’s the last version with Rosetta, and I’d love to compare GrandPa’s G5 to this 2010 space Odyssey.  Snow Leopard installs just fine, but the real fun comes from High Sierra and it’s APFS.  I installed & licensed a copy of Windows 10 Pro onto the Mac without issue, installed the bootcamp drivers, and.. well it installs Okay but drivers are a whole different story.

Apparently there is an ongoing war between Apple and ATI regarding bootcamp drivers, so the Apple UEFI cards won’t work with the stock drivers under Windows.  You can go and look for patched ATI drivers over at bootcampdrivers.com, although I had no luck with the Radeon HD 5700 that was in this machine, as it’s GPU never showed up in the Windows 10 device manager.

I still wanted to get accelerated graphics, and I decided to keep the old ATI card in the machine so I wouldn’t’ lose boot graphics from the UEFI ROM, but a card that needs additional drivers is fine, which opens the door to Nvidia.  I wasn’t ready to spend a fortune on a card, and I wanted one that didn’t draw that much power, so the 1030 was a perfect fit being cheap and not requiring additional power hookups.

GeFroce 1030

I just went with the cheapest one I could find retail.

Naturally the NVidia cards work fine in Windows, but of course Apple won’t use any stock plain PC cards.  But thankfully NVidia has ‘internet’ drivers that cover quite a few of their cards, including the 1030-1080’s. I had further issues with the built in audio drivers, which Windows always prefers to load some generic “High Definition Audio Device” driver, but it never makes any noise.  So I bought a cheap external USB Sound Blaster Play! 3 dongal, which works fine.

Old Xeon in MacPro

And then there is the fun with VMWare, I upgraded both VMWare Player to version 14, and Fusion to version 10.  And yeah, the Xeon W3565 is far too old.

No new VMWare for you!

Although my version 10 key of Fusion works on version 8, just as VMWare Player 12 works fine on Windows 10.

And if that wasn’t crazy enough, in the bootcamp boot driver selection, the High Sierra volume cannot be selected.  Even if you install onto a HFS+ volume, upgrade a 10.6.3 volume or whatever you do, High Sierra converts the filesystem into something that bootcamp doesn’t understand, so the only way to boot between the OS’s is to hold down the option key, and select the OS from the ROM, which thankfully after an update understands and boots APFS.

You think it’d be easy to just push an update to the bootcamp boot tool, but apparently it isn’t.

I don’t know why, but for all the money Apple is sitting on, they really don’t feel that together or with it.  I know in the whole ’99-05 time period they were not only fighting for their lives, but the whole OS 9 to OS X transition phase, just felt so much better done.  Ever since 10.4 it feels like things are just subtracted, nothing really useful added.  First Classic support, then PowerPC, then Rosetta.  Going from 10.7 to 10.13 really hasn’t been all that exciting.  Which has been the general state of things, with everyone for the most part just running VMS or Unix.

Adding an Xserve RAID

Xserve Raid

So yeah, I wanted to get a ‘real’ SAN for a while, but they always cost too much.  So I just decided to look for something older, like a MSA-1000, which are surprisingly still expensive.  Failing that I thought about how I could get that MacPro 2010 for ~$300 so I said what the heck and picked up a super cheap 7TB fully loaded out Xserve RAID.

I got a PCI-133 LSI Logic “LSI7202XP” Fiber Channel card for my G5, as I figured that this stuff was of the same era, may as well configure it with a PowerPC.

Configure the LSI

After setting the LSI to 2GB and in point to point mode, the system needed a reboot, and it would report a link on the FC adapter. Great.

To actually configure the array, you need the Xserve RAID admin tool, along with a working copy of Java on your machine.  I downloaded version 1.5.1 which is thankfully still on Apple’s site. It runs fine from OS X 10.5, although the readme does make mention of 10.2, so perhaps it’d run there, although I didn’t feel like booting into 10.2 to find out.  By default the password for read only access is ‘public’ and for admin control it’s ‘private’. Yes just like SNMP community strings.

Finding the array

You need to connect the Xserve RAID to an Ethernet network.  I’ve only used the MSA’s and they let you configure them over the FC, but no so with Apple, it’s a Bonjour enabled service, so you don’t have to setup the Ethernet, just plug it in, and that’ll be good enough.

Creating the array is straight forward, however the SAN with it’s two controllers aren’t redundant, rather it’s really 2 SAN’s in one chassis with a left & right hand side.

A new disk appears!

So the solution is to use 2 connectors to the dual card, I have 2 DAC cables so I’m set.

But for now it’s just more so messing with the unit.  I’ll probably just set it in JBOD mode, and pass it up to something like Solaris 10 with ZFS exports.

Converting a Physical disk to a Virtual disk with Qemu’s qemu-img on Windows

Just because even, I forget from time to time.

You need to do this as administrator, even better if the disk doesn’t have a drive letter or mounted in any way under Windows.

Fujitsu MPB3021AT

In my case I picked up a 486SX with an aging Fujitsu disk.

qemu-img.exe convert -f raw -O qcow2 \\.\PhysicalDrive2 fujitsu_MPB3021AT.qcow2

And as fast as your machine can read the disk, you’ll have your Qcow2 disk image. As of Qemu 2.9.0 the formats include:

  • blkdebug
  • blkreplay
  • blkverify
  • bochs
  • cloop
  • dmg
  • luks
  • nbd
  • null-aio
  • null-co
  • parallels
  • qcow
  • qcow2
  • qed
  • quorum
  • raw
  • replication
  • sheepdog
  • vdi
  • vhdx
  • vmdk
  • vpc
  • vvfat

Which is quite a list.  Obviously since I’m reading a physical disk, the format is RAW.  I just output it to Qemu for my personal ease.

Also, once the image was created, I could quickly run it under Qemu, and discover that yes this was a machine running Windows 95.

qemu-system-i386.exe -hda fujitsu_MPB3021AT.qcow2 -soundhw es1370 -vga cirrus

So, there you go from a “dead system” to at least fully recovered data in minutes.  KVM may get all the press excited but it’s nothing without the awesome support of Qemu!

So I started to look at the SCSI passthru on Basilisk

And personally I’ve never seen the appeal for such things, but apparently for the world of emulation accessing physical media is a big deal. Of course what I didn’t think about was rescuing old machines by re-installing the OS under emulation, or copy protection.

The first thing I looked for was a GPL project that has SCSI disk support and isn’t too complicated.  The Previous project sure fits that bill, scsi.c is not even a thousand likes, and even better it works!

The only two major hurdles I ran into is that the Mac is sending a page request of 0x30 which as far as I can find is not listed anywhere else.  I ended up just making one up as a reply to see if it mattered.

The other is that it’s scatter/gather based, so when it’s going to read or write several contiguous sectors, it’ll blast down up to 256kb worth of data to be read or written to.  The ability to know that a large operation was in progress was already in Previous, it just wasn’t set to loop.  I guess the NeXT isn’t as aggressive, or it’s SG operations are better contained in the SCSI controller.

The final hurdle was in the Apple partitioning software.  I’ve been down this road a long while ago.  But the disktools from A/UX 3.0.1 doesn’t care about vendors and will thankfully format anything.

SCSI disk files

SCSI disk files

So not as exciting as talking to a real SCSI disk, but it’s safer.  I suspect that accessing a raw NT device name ought to work  I can test that on VMWare, but the trick is finding something that can read HFS and prove it’s a good exercise.

Another ‘feature’ I put back in is the ability to disable the math coprocessor on the 68040.  It feels more stable to rely on Apple’s old emulation code, but maybe that’s me.

As always files for this are on sourceforge.

Blinking lights…

I almost cannot believe I’m going to post this, but so many of my machines don’t have LED’s to blink for hard disk activity it is driving me nuts.

Well thankfully, for windows there is a solution:

diskled

So what it does, is it’ll poll  \PhysicalDisk(_Total)\% Disk Time every 30ms, and if it’s doing something it’ll blink the icon colour.

Why is this cool?

It’ll even work with RDP.  So your server can be on the other side of the world, and you’ll know what’s going on.

It's cooler than it looks

It’s cooler than it looks

 

I was looking back at old posts

And I saw my old look at Mach+Lites.  And of course there was a qcow disk image associated with some ancient version of Qemu which I can’t run on Wine on OS X.  So I figured with a bit of fun I’d update the disk image to work with Qemu 1.7.0.

Luckily Qemu 0.15.1 works just fine for it’s qemu-img.  So a quick

qemu-img convert -f qcow -O vmdk mach.img mach.vmdk

and I had my image.  I’m not sure of what the NE2000 parameters that Mach can use to enable the network, but I do recall it was easier to just rebuild Qemu around them.  However this time, I switched to the Mach kernel that utilized Linux device drivers to get a working network.

I updated the hard disk file here.

Screen Shot 2013-12-27 at 12.16.18 AM

For the two or three people who care about BSD evolutionary dead ends.

Upgrading through OS/2; Version 2.0

Well here we go, ‘A better dos then dos, a better windows then windows, better OS/2 than OS/2!’ … The 32bit version of OS/2 had been under development for quite some time, and now it was finally time to ship.. The year was 1992.

I’m going to switch from VirtualBOX to Virtual PC, as the screen redraws were just too slow on VirtualBOX.  Virtual PC cannot boot 1.0, 1.1 & 1.2 however it can run OS/2 1.3.  Thanks to Qemu’s qemu-img tool, I could quickly convert the VirtualBOX hard disk image into something VirtualPC can understand.

qemu-img.exe convert OS21.3.vmdk -O vpc OS2-13.vhd

And to test things, I first booted it on Virtual PC.

Ok, everything looks fine, let’s upgrade!

The OS/2 installer had grown so big, that now it required two diskettes to boot up.

Also back was a graphical splash, the colored OS/2 logo that in a way reminds me of the 4 panes of the windows logo.

And back to the blue on grey installer… Notice 15 diskettes! It’s grown massive!

Another amazing thing for OS/2 2.0 is the boot manager.  It lets OS/2 boot from extended partitions, and even secondary drives! As long as the boot manager is installed first.  I know some people that bought OS/2 only to manage multi-booting installations.  IBM could have sold this thing as a separate product.  Alas, since we are upgrading our way through OS/2 we have no need for it, so we just keep on upgrading our C drive.

If only there was a FAT to HPFS conversion utility.  But again, please don’t format my C drive!!!

Now we just feed diskettes to the installer..

And now we can reboot into the GUI!

And let the install continue.  I can’t help but think that I’ve done this before..

Unlike last time, I’ll actually have something to migrate..

Well the migration tool gives me a good feeling for finding my OS/2 programs.  Maybe they’ll even run!

Let’s trust the installer…

Now this confuses me, first it said (and quickly) that it migrated my existing printer, then it wants me to add another…?  I just know I’ll get two printers.  Now I feel like Arthur ‘Two Sheds‘ Jackson.

So a reboot at the end, and into the GUI:

Notice how OS/2 2.0 throws the tutorial in your face… All the while the desktop is building in the background so you could ‘multitask’ doing the tutorial while your hardisk is frantically building the desk.. And I see the two printers… sigh.

As you can see Word and Excel are still working.  And unlike a stock OS/2 2.0 installation it’s preserved the 1.x color scheme.

If you’ve never used OS/2 2.0 it comes with FAR more applets then the prior versions.

No doubt IBM was trying to address people like me complaining.  PM Terminal was nice in that it supported Xmodem, Ymodem & Kermit.  Not to mention you can send a ‘break’ easily over a menu.  It’s handy for things like cisco routers.  The seek & scan files is AWESOME really where was this in the world of Windows?  Why was this so … hidden.  Kind of strange that such a great tool was hiding.

Also someone got the memo about games.  You see if people can’t play in your environment they’ll go elsewhere.  After all even in the office it’s not all work.. There is a lot of people that attribute the success of Windows 3.0 to it’s Solitaire.  You see it’s shuffle algorithm is broken, cards tend to ‘clump’.  So as you play and sort, the cards start to appear in a better and more orderly manner.  And people like to win.  I know it’s a cheap thing, but heh the Chess in OS/2 is pretty good, as is the Solitaire.  I don’t know if making them ‘broken’ and letting people win more often would have sold more installs.  It reminds me of “The Story of Mel

In the same way, being ‘good’ and ‘correct’ doesn’t win you spaces in the market place.

Also this is the appearance of Neko for OS/2.  Not to mention a Jigsaw puzzle, one of those annoying number scramble things, and .. Reversi!

OS/2 2.0 finally allowed users to do wallpaper! ..

The downside is that OS/2 relied on it’s own bitmap format that of course was incompatible with the Windows bitmap format.  Nor did it support things like GIF/PCX that were common at the time.

Another thing IBM included was a copy of Windows 3.0 that could run under OS/2 2.0 in either full screen or ‘seamless’ mode.  There was no denying it, but after the launch of Windows 3.0 the avalanche of Windows programs was.. incredible.  And to not support them would mean death.

Some say that OS/2 did such a great job of support Windows that it just encouraged people to not write OS/2 software.

The ‘killer’ feature in OS/2 was this:

That little checkbox, “Separate session” became the #1 feature of OS/2.  You see Windows applications could happily overwrite each other, and memory protection became a big problem for Windows.  The easy way to crash it out was to launch a lot of any application.  Even well behaved applications would eventually bleed the system resources out, and again instabilities would strike.  In Windows 3.0 the USER, GDI & KERNEL modules all shared stack & heap, so exceeding the 64kb stack wasn’t too hard.  Even things like Program Manager and high color icons could do this quite easily.  However with OS/2’s “Win-OS/2 separate session checkbox, it meant that this application would get it’s own copy of Windows running.  Suddenly you could run Word for Windows & Excel for Windows in separate VMs, along with say some game, and the game wouldn’t crash all three out.  And if you were a programmer, it meant your compiler,editor could run outside and protected from the program you were developing.

And with seamless mode, instead of a separate screen, now your Windows applications could run on the OS/2 desktop.  This kind of partitioning wouldn’t make it’s way to Windows NT until version 3.5 in 1994.

You can only run 12 OS/2 sessions, but you can run WAY more DOS sessions.  I just got bored of clicking and rearranging.  I wouldn’t even think of running 20 MS-DOS prompts on Windows 3.0 ..

And unlike the OS/2 prompts the DOS boxes can go between full screen and windowed mode.  Another great thing is that they support DPMI & VCPI.  So you can run dos extender software.  Another great thing, is that *SOME* hardware calls could be passed down from a VM into your hardware.  It is possible for Doom 1.1 on OS/2 2.0 to work with a soundblaster.

Really.

(SET BLASTER=A220 I5 D1 P330 T3 and use the fixpack for OS/2 2.0 … but really it works!)

Sadly DOOM didn’t run in a window, and honestly a picture of doom is.. well.

 

gratuitous.

But why not.  It’s actually running under OS/2.  It’s something that a lot of computers in 1993 had issues running, even in plain MS-DOS.

At this point OS/2 1.0 feels like a tech demo, 1.1 – 1.3 are just toys.  Really you can see the frustration in the IBM/MS alliance as a 32bit OS is what people wanted to make, not the 16bit stuff.  It’s all goes down to the poor design of the 80286 CPU, and too many people selling them as ‘useful’ things.  Even as early as 1992 microkernel/personality people should have really taken notice in OS/2 2.0.  The key to the future was in virtualization, not in personalities.  Or more so, with things like Win-OS/2 paravirtualization, which is specialized kernel assists and drivers enabling the guest OS to bypass typical emulated hardware for IO and transfer raw datablocks in/out for things like video/disks & networks.

As awesome as OS/2 2.0 was, there is one thing you may notice here clearly lacking.

Networking.

OS/2 2.0 included *NO* networking support at all.  It was expected that people would use separate addons, even going as far to coax support for network cards in the DOS sessions and loading isolated Netware reqestors.  And of course adding these network requestors was widly varied, and there was simply no good universal way to do it.  Microsoft clearly learned the lesson about this with Windows for Workgroups & Windows NT.  It was a real pleasure with Windows 95 & Windows NT 4.0… But it was 1995-1996 by then.

Well, Next stop is OS/2 2.1!

Spot the difference….

Picture A

Picture B

I know, it’s hard they both look identical.  Well they kind of are, Picture A is the installed OS/2 2.0 image that I’ve been playing around with.  It’s a 500MB IDE disk formatted with the HPFS filesystem.  For the heck of it, I used the qemu-img tool to convert it from a qcow2 into a vhd (qemu-img convert 500M.disk -O vpc 500M.vhd) and then tried to boot it up on Virtual PC.  I know in the past it’d fail with some weird error as something on HPFS wouldn’t transfer and it’d be the end.

But it worked!

This is really a great victory for Qemu!