Hard Drives and Drivers on PCs and Macs

The following was written in response to questions a Mac user asked about hard drives and drivers on PCs.

I'll do a simple summary first. When dealing with a Mac prior to the Blue & White G3, they have up to 4 MB of ROM with a whole bunch of common code that every Mac program can use. The ROM also takes care of the little details of talking to all the hardware, so most programmers and users never have to bother with it.

The PC doesn't have a big ROM with lots of code in it, so any operating system that runs on a PC has to take care of everything on its own.

Beginning with Windows 95, much of the detailed knowledge formerly required to install Windows on a PC was no longer needed. Windows would take care of it for the user. But it's taken until Windows XP to get to the point where it all really goes on "hands free". Everything worked very well on my PC when I installed XP. For the first time with Windows, I didn't have to tweak and twiddle to optimize it - but I did anyway. The neat thing is that I can, and I didn't need to use the command prompt at all.

Now more advanced info.

The ROM (or Toolbox ROM) in a Mac contains much of the basic functionality of the Mac System. It's customized for each model so that the hardware interface looks pretty much identical to the System software on each Mac. That's why you can generally install a System on a drive in a IIci then be able to use it to boot up a Mac II.

The part of the ROM that communicates with a hard drive expects to be able to use the same commands to work with any hard drive. The disk driver that gets installed into it's own special partition takes care of the "translation". The System and the ROM are never bothered with knowing anything about the physical layout of the drive, other than the amount of space available. Apple's HD SC or Drive Setup program gets that info and then sets up the driver appropriately for that drive. Third party utilities do the same.

Until Windows for Workgroups 3.11, the DOS/Windows combination always used the BIOS for access to the hard drive. WFWG introduced "32-bit Disk and File Access", which the user had to manually turn on with a control panel that had separate selections for Disk Access and File Access. When both worked, it sped things up quite a bit; if only one worked okay, there was no point to turning on just one.

Windows 95 and newer use full 32-bit access to the hard drives and most other types of drives by default. Some 16-bit drivers for certain hardware will work in Win9x and WinMe, but WinNT/2000/XP need 32-bit drivers. If there is a hardware conflict or you have to boot in Safe Mode, they'll "dumb down" to 16-bit mode using the BIOS, but it's incredibly slow.

Other than for the various problems PCs have had over the years keeping up with changing hard drive technology, there's been no need for any driver software to be in a specific location on the hard drive. Any other drivers for peripherals (or things that used to be peripherals but are now integrated into the motherboard) are loaded by the operating system similar to extensions and control panels on a Mac.

The Macintosh was developed with little RAM (128K) and little storage (400K floppy disk), so to be able to have the graphical user interface and also to be able to communicate with the various hardware of the computer, the logical place to put all that common and always needed code was in a (relatively) big ROM. That way it needn't be included on every bootable floppy, where it would have taken up half the disk.

By 1984 the IBM/AT was available with a 1.2 megabyte floppy disk, a 20 megabyte hard drive, and 640K RAM. The Mac was designed to run one operating system, and all apps were expected from the beginning to use all that ready made code in the ROM. A Mac programmer didn't have to bother with writing code to send the correct data to the video system or other peripherals; the ROM or an INIT took care of that.

The PC, with it's simple BIOS, allowed wide open hardware options, but that also brought with it the responsibility of each device maker to write a DOS driver that would load into memory without conflicting with something else. Filling all the expansion slots and making it all work was often a challenge for the best PC tech.

Windows 95 changed that. It didn't need anything from DOS except to "hand off" control once the IO.SYS file was loaded from the drive. Even before Win95, Windows NT only needed the IO.SYS file to get booted; everything from there on was taken care of by Windows. Win 2000 and Win XP are the same way.

The limited BIOS allowed the PC platform to be very flexible in running software, but it also put the full burden of making sure the bells didn't whistle and the whistles didn't bong on the programmers. :) Of course, that also means that all the code that provides the Windows GUI is part of Windows and takes up space on the hard drive - and then space in RAM when the PC is running.

Today's Macintosh is little different from today's PC. Since the Blue & White G3, the Mac has been using a tiny ROM who's only job is to get the initial hardware startup squared away and then go looking for the "ROM", which is now a file on the hard drive, to load into RAM which then takes over and loads the Mac OS.

It's very much like how the PC BIOS initializes and does basic tests on the hardware and then goes looking for IO.SYS, which then hands over control to Windows. The main difference is that the IO.SYS file is very small, and the Mac ROM file is a few megabytes now.

Except for the CPU and the chipset, modern Mac hardware is from the same parts bins as a modern PC: IDE hard drives, PCI bus, USB ports, video controllers, etc. Apple has contributed the 1394 "FireWire" port, but it's been much easier on Apple's bottom line to adopt the other pieces from the PC world where the massive production makes them cheap.

The benefit of adopting all this and going away from having the ROM in an unchangeable chip is what gave the Mac the flexibility to adopt/adapt the BSD operating system and the Aqua interface while doing away with any restrictions of having an unchangeable ROM that constantly had to be "spackled over" with patches from extensions when new features or a new look to the interface was desired.

Here follows a history of the PC platform's trials and tribulations with the hard drive through the years. Reading it is optional.

Since the IBM PC was introduced in 1981 and the Mac in 1984 (and the PC was in development in the late 1970s), things naturally were more "primitive". Small hard drives that would be practical for use in a desktop computer didn't even exist until around about the time of the PC's introduction, so it wasn't even possible to build support for them into the initial design.

DOS was pretty much "ruled" by the ROM BIOS, the PC version of the Mac's ROM. (Since shortened to just BIOS with the advent of the Flash reprogrammable chip.) BIOS means Basic Input Output System.

And it started out really basic. When DOS wanted to read or write to a floppy, it called the routines from the BIOS. Everything in or out from basic peripherals was run by code called from the BIOS and processed by the CPU.

Fortunately, IBM made a space in RAM where "option ROMs" could "plug in" and be called either by software programs or by standard commands sent to parts of that space in RAM. Video cards were the first devices to use that space, then hard drive controllers.

Early PC hard drive controllers typically supported from as few as one to somewhere less than twelve specific models of drive, mostly because that's all that was available at the time and partly because PROM chips (Programmable ROM, write once only) cost a lot and using the smallest that would fit the code was cost effective. So with the hardware setup, the user booted from a DOS floppy, then ran DEBUG, and then entered a command to access code in the controller's ROM. Select the right options, manually enter all the Bad Block data from the list printed on a label on the top of the drive then sit back, and wait for it to be formatted. Then the user could set up one or two partitions with FDISK, reboot, then FORMAT the partitions, then use the SYS C: command to transfer over the three system files (IO.SYS, MSDOS.SYS, and COMMAND.COM). IO.SYS and MSDOS.SYS had to be in specific locations at the beginning of the drive or DOS couldn't boot.

All was well and happy in PC Land until 1984. It wasn't the introduction of the Mac that shook things up (as far as the low level hardware went); it was the IBM AT with the 80286 CPU and the introduction of CMOS RAM to store certain parameters about the hardware, like how much RAM was installed, the type of video card (color or mono), and, most important, the number of heads, cylinders, and sectors per track of the new IDE hard drives. Again, there weren't many models of drives available, and most would fit a short list of parameters which amounted to around 47 different selections.

Then things got hairy - really hairy. Drive manufacturers began to ignore the list of common parameters and started making bigger drives. To fix that, some third party companies wrote software that could make a drive that was the same size or close to one of the hard-coded BIOS types and "translate" the parameters so that when the BIOS called for data on a certain sector, the software would interrupt the BIOS call, get the data from the drive, and then hand it to DOS while making it look like all was normal. This worked quite well, except that if the drive was moved to another computer, it was unlikely that any of the data on it could be read because it would all be in the wrong sectors.

Soon the PC makers added a user customizable hard drive entry to the BIOS, so the actual drive parameters could be entered and the translation software was not needed. All was well again, and DOS (plus Windows 3.0 running on top of it) could rely on the solid old BIOS calls again for any size and type of hard drive. (I'm leaving out SCSI on the PC here. That's a whole 'nother tale.)

The PC world ticked along happily until hard drives passed the 512 MB mark. There was a "little" problem in most of the different brands of BIOS - even if the user entered the correct drive parameters or the BIOS autodetection could properly see the drive's parameters, the BIOS would fail to inform DOS about anything more than 512 MB.

The software workarounds with the same problem of not being able to move a drive to a different PC had to be dug up, wiped off, and polished again. Sometimes, depending on what tricks the software had to do, it could be removed with the data intact after updating the BIOS or upgrading to a new motherboard with a BIOS that eliminated the 512 MB limit. It was always a sticky thing, waiting for successful completion.

Wash, rinse, repeat. The BIOS programmers at American Megatrends, Phoenix, Award and the smaller companies did quick fixes for the 512 MB limit. Unfortunately, they didn't foresee the next file system Microsoft would unleash. In 1996, FAT32 smashed the old FAT16 2 GB hard drive limit, so they only fixed the BIOSes for drives up to 2 GB. The BIOS overlay software companies rejoiced at the shortsighted PC world and made a boatload of money again.

Do it again. They "fixed" the 2 GB limit and replaced it with an 8 GB limit. See the previous paragraph.

At each of those limits, there were a few PCs with a BIOS that could not be worked around with any sort of software trickery, so they either got upgraded motherboards or went to the trash, Goodwill, or were kept with their old drives.

As far as I've seen and experienced, if there is any limit to hard drive sizes on a PC now, this time they've made it so insanely huge that most PCs in current use really will be on the junk heap before the limit is hit. [Editor's note: UltraATA/100 has a 128 GB limit, but UltraATA/133 breaks it.]

The Mac had an advantage by starting later. Apple was able to create their own System and optimize the Mac to run just that.

The PC's genesis began when the computer landscape was in a massive state of flux. IBM didn't even have an operating system chosen when they began the project, because there wasn't anything anything like the PC at the time with the RAM capacity and the peripherals and expansion options they had planned for it.

If IBM had loaded it up with a bunch of code, it would have been just another limited box that wouldn't be much more than something like a Commodore PET with "massive" RAM and other storage options. IBM went for a design that would allow taking just about any OS and modifying it to work.