In response to a reader question, I started wondering how difficult it actually is to install OS/2 1.3 on a “big” hard disk, where “big” is defined as more than about 500 MB. In an attempt to reduce the number of potential problems, I skipped IDE and went straight for a SCSI setup, using an (emulated) BusLogic SCSI HBA with a 6 GB hard disk.
The short story is that it can be done, but it’s not entirely trivial:
MS OS/2 1.3 does not include a driver for the BusLogic HBA, but BusLogic provided one. The driver can be had for example from here, or from the vendor here (the “vendor” now being Broadcom, where BusLogic ended up after a string of acquisitions (BusLogic to Mylex to LSI Logic to Avago/Broadcom).
Installing the driver is easy enough; the file SPARE001.SYS needs to be copied from the archive to the OS/2 boot floppy. The virtual disk created by the OS/2 installer can be used for file exchange. I used the Installation Diskette B, but I believe Diskette A could have been used just as easily. Note that after the OS is installed, the driver has to be manually copied to the root directory of the boot drive, otherwise the installed OS cannot boot.
The first hurdle is in the initial install stage. This inviting dialog offers to take care of everything:
If you choose to accept the predefined primary partition, the install will happily continue, and you will end up with a non-bootable OS which crashes very early in the boot loader. The correct choice is specifying a primary partition size. Experimentation shows that 2,000 MB is a safe size; the partition could be smaller or very slightly bigger:
A boot partition smaller than 2GB works; again, the BusLogic driver SPARE001.SYS needs to be copied from the boot floppy to C:\ before the system can boot from hard disk.
Now that the OS is running, we can create an extended partition which covers the rest of the disk.
To actually use any of the additional disk space, it’s necessary to create a logical drive. So let’s try that and create a logical drive which takes up the entire extended partition:
After the obligatory reboot caused by changing drive letters, we have to format the partition:
Oops! HPFS in OS/2 1.3 refuses to format partitions larger than 2GB. For that matter, that’s probably exactly why the initial install attempt failed—the OS installed a too large partition and maybe even formatted it, but the boot loader couldn’t deal with it.
So let’s try splitting up the disk and creating a 2,048 MB partition plus two smaller ones:
Well… that didn’t work either. Asking FDISK to create a 2,048 MB partition resulted in FDISK in fact creating a 2,055 MB partition (the rounding is normal). Which FORMAT then naturally refused to format. Let’s try again:
Now that actually worked — the big logical drive could finally be formatted:
Note that for a 6 GB disk, a BusLogic HBA normally uses a “maximal” geometry with 255 heads and 63 sectors per track (typically also used for large IDE drives). In this case, geometry did not actually seem to cause any problems.
The real trouble was that HPFS (and FAT) has partition size limitations, and these are not reflected either in the OS/2 installation program or in FDISK. When reflecting these limitations, it is possible to convince OS/2 1.3 to use a multi-gigabyte hard disk.
Update: Spurred by reader comments, I set out to find out if HPFS386 makes any difference. I used Microsoft LAN Manager 2.1, from late 1991. The base OS is the same OS/2 1.3 used above, therefore the disk drivers are unchanged.
However, on this try I configured the VM with a 12GB SCSI disk. I quickly found out that OS/2 only “sees” about 8GB of it. Presumably the disk geometry is cut off at 1024 cylinders such that the BIOS can access the disk.
I created a 1,000 MB boot partition and installed the OS (no problem there). Then I created an extended partition to cover the rest of the usable disk space, and then a logical drive that takes up the entire logical partition.
As we saw above, HPFS refuses to format such a partition. However, HPFS386 supplies its own UHPFS.DLL, which contains both CHKDSK and FORMAT implementation with HPFS386-specific modifications.
And sure enough, with that UHPFS.DLL, FORMAT was able to do its job on a circa 7GB partition:
Here is what it looks like in FDISK:
The conclusion is that yes, HPFS386 really could handle larger partitions than plain HPFS could in OS/2 1.3. HPFS386 was reportedly limited to 8GB, but it is not entirely clear if the limitation was coming from HPFS386 itself or from the underlying storage subsystem.
Addendum: On a related topic, I wondered what would happen if I set up fault tolerance (specifically disk mirroring, aka RAID 1) that OS/2 1.3 provides. The setup program didn’t look too promising:
How will a 7028MB partition fit on a 4243MB disk? That sounds problematic. But I tried it anyway:
Well, apparently somehow OS/2 squeezed 7GB into 4GB. Or maybe the disk space shown was nonsense to begin with. The fault tolerance admin utility is not complaining (it shows a bogus error on an “unknown” drive but not on the actual C: and D: drives):
The mirrored disks are actually OK, and the big HPFS partition still has about 7 GB after mirroring according to CHKDSK. The drive capacity shown was incorrect, but the actual implementation appears to be working.
In a VM, disk mirroring noticeably slows things down (very unsurprisingly) but shows that basic fault tolerance really did work in OS/2 1.3. Besides mirroring, OS/2 also supported disk duplexing, which uses not only separate disks but also separate controllers.
Both mirroring and duplexing are something NetWare had supported years before OS/2, and Microsoft clearly felt they had to implement it as well if LAN Manager were to be taken seriously.
It is painfully obvious that OS/2 1.3 was not truly designed to be used with disks bigger than 4GB. The fault tolerance setup utility is not the only one showing difficulty, even good old DIR exhibits 32-bit wraparound and can’t show the free space on a 7GB HPFS volume properly. But for the most part, OS/2 1.3 can handle disks (at least SCSI) up to about 8GB in size.
>where “big” is defined as more than about 500 GB
>GB
Yeah, 33 year old software would classify that as “big”. 🙂
HPFS386 was supposed to support up to 8GB partitions. I would expect FDISK to support those limits. Not exactly a problem since IBM didn’t offer a 1GB SCSI drive for the PS/2 lineup until the enhanced Model 95 in 1992, let alone anything with a higher capacity. IBM did offer patches for 1.3 correcting a number of bugs regarding HPFS drives larger than 1 GB in 1992 and 1993 so pushing partition size might not be the best idea for reliable data storage.
Oops, thanks for that. Megabytes, gigabytes, terabytes, it’s hard to keep track!
HPFS386 is something I have not tried, and now I’m actually curious if it would work or not (work as in if it would be able to use larger partitions). I’d think the FORMAT utility was the same, but perhaps not. Note that FDISK creates the partitions just fine, it’s FORMAT that complains.
OS/2 2.x supports HPFS partitions up to 64GB I believe, so at some point the limit was definitely raised. But as you say, 1+ GB drives weren’t much of a thing in 1990-1991.
Since a cylinder is in the 8-9MB range a x/254/63 CHS configuration, I’d say 2045 or 2046 would be safe partition size. 2047 might be pushing it though.
Any possibility of a hex dump of the partition table from the virtual hard disk, Michal? It would answer that question.
I’d love to know more about HPFS386. I never had it back in the day as it was locked in the server product?
Apparently it uses memory above 16mb?
HPFS386 came with LAN Manager (I believe it showed up in LM 2.0). I don’t think it can use memory above 16MB (and seriously, back then 16MB was a huge machine) but it was able to use a lot of those 16MB for disk cache. It was also supposedly able to work with the file server such that there was a more direct path between the file server and the file system, eliminating some context switches. And HPFS386 also supported disk quotas and ACLs, which is something plain HPFS did not do. It needed its own CHKDSK utility for that reason.
HPFS386 did not need the file server though, it was entirely possible to use HPFS386 even without networking. But you couldn’t get it without LAN Manager (and later IBM LAN Server Advanced) so not a lot of people did that.
Given that NT’s pinball.sys HPFS driver don’t support volumes larger than 4GB, I would think that the limits for HPFS386 are the same.
The publicly announced limits were larger at “7.8 gigabyte”. See https://jeffpar.github.io/kbarchive/kb/086/Q86863/ Since the use of an array was needed to combine enough drives to hit that partition size, testing was probably minimal.
Apparently not. I updated the article; I was able to format a roughly 7GB HPFS386 partition. I did not test it extensively but HPFS386 definitely had different limits than plain HPFS in OS/2 1.3.
Thinking about it, it is funny how when 4Mbit DRAM and 4MB SIMMs arrive in 1989-1990, other platforms (like Macs and UNIX workstations) was ready for them but for the most part the PC world wasn’t.
The pee-cee world was never ready for anything. Hence the kludges.
Of which the Macintosh had its share too, memight add.
While it took a while before the Macintosh was able to remove 24-bit addressing, the Macintosh added support for 4MB SIMMs in the IIx ROM in late 1988. A/UX could already support them, and a 32-bit Memory Manager was added in the IIci ROM in late 1989.
The Mac IIx required special SIMMs with a PAL which cost considerably more than the standard 4MB SIMMs available to 486 systems. The Apple Tech Note #176 regarding memory includes an entertaining section entitled “4 Mbit DRAMs in Revolt” which explains how Apple’s support of the planned 4 MBit chip design failed in practice and the fixes required.
Yea, it has to do with how CAS before RAS refresh worked on the original Macintosh II. The SE/30 and IIcx fixed the problems in early 1989.