It is often difficult for people to understand the difference between hardware and software in a PC system. The differences can be difficult because they are both very much intertwined in the system design, construction, and operation. Understanding these differences is essential to understanding the role of the BIOS in the system.

First let's define what the BIOS is. BIOS is a term that stands for basic input/output system, which consists of low-level software that controls the system hardware and acts as an interface between the operating system and the hardware.

Most people know the term BIOS by another name—device drivers, or just drivers. In other words, the BIOS is drivers, meaning all of them. BIOS is essentially the link between hardware and software in a system.

When the PC was first introduced, the BIOS software containing all the device drivers for the entire system was collectively burned into one or more nonvolatile (meaning they retain their data even when the power is turned off) read-only memory (ROM) chips and placed on the motherboard.

In essence, the drivers were self-contained, preloaded into memory, and accessible anytime the PC was powered on. This ROM chip also contained a power on self test (POST) program and a bootstrap loader. The bootstrap program was designed to initiate the loading of an OS by checking for and loading the boot sector from a floppy disk and, if one was not present, a hard disk.

After the OS was loaded, it could call on the low-level routines (device drivers) in the BIOS to interact with the system hardware. In the early days, all the necessary device drivers were in the BIOS stored in the motherboard ROM. This included drivers for the keyboard, MDA/CGA video adapters, serial/parallel ports, floppy controller, hard disk controller, joystick, and clock.

When the OS loaded, you didn't have to load a driver to interact with those pieces of hardware because the drivers were already preloaded in the ROM. That worked great as long as you didn't add any new hardware for which there wasn't a driver in ROM.

If you did, you then had two choices: If the hardware you were adding was an adapter card, that card could have a ROM onboard containing the necessary device drivers.

The motherboard ROM was preprogrammed to scan a predetermined area of memory looking for any adapter card ROMs and, if any were found, their code was tested and subsequently executed, essentially linking them into and adding their functionality to the existing BIOS.

In essence, the motherboard ROM "assimilated" any adapter card ROMs, adding to the "collective" functionality. This method of adding drivers was required for certain items, such as video cards, that needed to be functional immediately when the PC was powered on.

The BIOS code in the motherboard ROM had drivers only for the IBM monochrome display adapter (MDA) and color graphics adapter (CGA) video cards. If you added any card that was different from that, the drivers in the motherboard ROM would not work.

That wouldn't be a problem if the new video card had its own onboard drivers in a ROM that would be linked into the BIOS immediately upon throwing the power switch. If the device did not use an adapter card, there had to be another way to add the necessary driver to the BIOS collective.

A scheme was devised whereby during the early stages of loading, the OS startup file (IO.SYS) checked for a configuration file (called CONFIG.SYS) that specified any additional drivers to load to support new hardware. The CONFIG.SYS file, along with any drivers named within, would be placed on the boot drive.

Then, when the IO.SYS program read them, it loaded the specified drivers into memory and linked them into the rest of the BIOS, again adding their functionality to the collective whole. In essence, these drivers were loaded from disk into RAM and linked into the BIOS so they could be called on when necessary.

At this point, the BIOS had grown from being entirely contained in the motherboard ROM, to having additional drivers linked in from adapter card ROMs, to having even more drivers linked in after being loaded into RAM during the early stages of the boot process.

The BIOS was now constructed of programs located in three different physical locations in the system, and yet it functioned as a single entity because all the programs were linked together via the BIOS subroutine calling system-of-software interrupts.

The OS or an application program needing to talk to a specific piece of hardware (for example, to read from the CD-ROM drive) would make a call to a specific software interrupt, and the interrupt vector table would then route the call to the specific part of the BIOS (meaning the specific driver) for the device being called.

It did not matter whether that driver was in the motherboard ROM, adapter ROM, or RAM. As far as the system was concerned, memory is memory, and as long as the routine existed at a memory address, it could be called.

The combination of the motherboard BIOS, adapter card BIOS, and device drivers loaded from disk contributed to the BIOS as a whole. The portion of the BIOS contained in ROM chips, both on the motherboard and in some adapter cards, is sometimes called firmware, which is a name given to software stored in chips rather than on disk.

Of course, after you turned off the system, the drivers in nonvolatile ROM would remain intact but those in volatile RAM would instantly vanish. That was not a problem, however, because the next time the system was turned back on, it went through the boot process and again loaded the necessary supplemental drivers from disk all over again.

As the PC has evolved, more and more accessories and new hardware have been devised to add to the system. This means that more and more drivers have needed to be loaded to support this hardware. Adding new drivers to the motherboard ROM has been extremely difficult because ROM chips were relatively fixed (difficult to change) and limited space was available.

The PC architecture allotted only 128KB for the motherboard ROM, and most of it was already used by the existing drivers, POST, BIOS Setup program, and of course the bootstrap loader. Putting the driver on an adapter card ROM is also difficult and expensive, and only 128KB is allocated for all adapter card ROMs to exist, not to mention the fact that the video cards have already stolen 32KB of that.

So, most companies developing new hardware for the PC simply wrote a driver that was designed to be loaded into RAM during boot. As time went on, more and more drivers were being loaded from disk—in some cases, even drivers that were replacing those in the motherboard.

For example, Windows 95 introduced a new hard disk driver that used 32-bit code, which shut down the existing 16-bit coded driver that existed in the motherboard ROM.

At that point, the hard disk driver in the motherboard ROM was used for only a few seconds after the system was turned on, and after the improved 32-bit driver was loaded into RAM during the boot process, the vector table was changed to point to that one instead of the one in the ROM.

This has progressed to today, when 32-bit drivers have been designed to be loaded from disk to replace all the drivers in the motherboard ROM. This is the case for any system today running Windows NT, 2000, or XP. Those systems do not use any of the 16-bit drivers found in either the motherboard ROMs or any adapter card ROMs.

The motherboard ROM code is used only to get the system functioning enough to get the initial 32-bit drivers and OS loaded, at which point they take over and the motherboard ROM is shut down.

Therefore, today on a PC running Windows XP, for example, after XP is loaded, no more calls are made to any of the routines in the motherboard or adapter ROMs. Instead, only device drivers loaded into RAM are called. So, the instant the PC is powered on, the BIOS might be mostly in ROM, but after XP is loaded, the BIOS resides entirely in RAM.

That is most likely the way things will continue for the future. The motherboard ROM exists only to get the system started, to initialize specific hardware, to offer security in the way of power-on passwords and such, and to perform some basic initial configuration. However, after the OS is loaded, a whole new set of drivers takes over.

A PC system can be described as a series of layers—some hardware and some software—that interface with each other. In the most basic sense, you can break a PC down into four primary layers, each of which can be broken down further into subsets. Figure 1 shows the four layers in a typical PC.

The purpose of the layered design is to enable a given operating system and applications to run on different hardware.

Figure 1 shows how two different machines with different hardware can each use different drivers (BIOS) to interface the unique hardware to a common operating system and applications.

Thus, two machines with different processors, storage media, video display units, and so on can run the same application software.

In this layered architecture, the application software programs talk to the operating system via what is called an Application Program Interface (API).

The API varies according to the operating system you are using and consists of the various commands and functions the operating system can perform for an application. For example, an application can call on the operating system to load or save a file.

This prevents the application itself from having to know how to read the disk, send data to a printer, or perform any other of the many functions the operating system can provide. Because the application is completely insulated from the hardware, you can essentially run the same applications on different machines; the application is designed to talk to the operating system rather than the hardware.

The operating system then interfaces with or talks to the BIOS or driver layer. The BIOS consists of all the individual driver programs that operate between the operating system and the actual hardware. As such, the operating system never talks to the hardware directly; instead, it must always go through the appropriate drivers.

This provides a consistent way to talk to the hardware. It is usually the responsibility of the hardware manufacturer to provide drivers for its hardware. Because the drivers must act between both the hardware and the operating system, the drivers typically are operating system specific.

Thus, the hardware manufacturer must offer different drivers so that its hardware works under DOS, Windows 9x, Windows 2000, Windows XP, OS/2, Linux, and so on. Because many operating systems use the same internal interfaces, some drivers can work under multiple operating systems.

For example, a driver that works under Windows Me will usually also work under Windows 98 and 95, and a driver that works under Windows XP will also often work under Windows 2000 and NT (and vice versa). This is because Windows 95, 98, and Me are essentially variations on the same OS, as are Windows NT, 2000, and XP.

Because the BIOS layer looks the same to the operating system no matter what hardware is above it (or underneath, depending on your point of view), the same operating system can run on a variety of systems.

For example, you can run Windows XP on two systems with different processors, hard disks, video adapters, and so on, yet Windows XP will look and feel pretty much the same on both of them. This is because the drivers provide the same basic functions no matter which specific hardware is used.

As you can see from Figure 1, the application and operating systems layers can be identical from system to system, but the hardware can differ radically. Because the BIOS consists of software drivers that act to interface the hardware to the software, the BIOS layer adapts to the unique hardware on one end but looks consistently the same to the operating system at the other end.

The hardware layer is where most differences lie between various systems. It is up to the BIOS to mask the differences between unique hardware so that the given operating system (and subsequently the application) can be run.