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.
