Studying for the A+, Network+ or Security+ exams? Get over 2,600 pages of FREE study guides at CertiGuide.com!|
Join the PC homebuilding revolution! Read the all-new, FREE 200-page online guide: How to Build Your Own PC!
NOTE: Using robot software to mass-download the site degrades the server and is prohibited. See here for more.
Find The PC Guide helpful? Please consider a donation to The PC Guide Tip Jar. Visa/MC/Paypal accepted.
|View over 750 of my fine art photos any time for free at DesktopScenes.com!|
The BIOS and the Software Layer Model
As mentioned in many other places, one of the key factors in the success of the PC platform is the combination of a huge choice of hardware and software options, and at the same time compatibility between many different types of hardware and software. Backwards compatibility is particularly key; nobody wants to have to throw out their old software when hardware changes, and companies that have tried to ignore this have often suffered the consequences (e.g., the MCA bus).
Have you ever marveled at how most of the applications that ran on your AT-class machine in 1985 will still run on your Pentium today? This, despite radically different processors, system buses, memory, in fact, all the hardware is different, and the operating system is as well. I personally have many applications that I run still today that are 12 years old or more. How is this possible?
The key to this universality is the use of multiple software layers. Let's consider the use of a program like Microsoft Word 6.0, running on Windows 3.x. In a simplified view, when you run this application, you are actually employing four main software layers: Word 6.0 is the application; it runs on Windows; Windows runs on top of DOS and DOS runs on top of the system BIOS. The BIOS interfaces with the hardware. This table shows the various layers, from lowest to highest. The operating system and application can (and often are) composed themselves of multiple layers:
Each of these layers contributes to compatibility in an essential way: it talks to the level below it using a standard interface. In order for Word 6.0 to work in Windows, it must follow certain rules set forth by the designers of Windows. Windows must follow rules set forth by the creators of DOS. And DOS must use a standardized way of talking to the system BIOS.
Each layer provides an abstraction model to the software that runs on it, by providing to the layer above it a set of services and functions that the layer above it can use. Word 6.0 doesn't worry about the hardware or DOS much at all; it simply calls Windows functions and lets Windows worry about DOS. Windows talks to DOS using DOS functions, etc. (This is somewhat simplified because in some cases the layers aren't this cleanly separated).
By using these standards, it makes it possible to mix and match various layers, as long as the programmers follow the rules. If you want to update your DOS version, Windows will still work as long as the new DOS version provides the same standard interface that the old one did; it can provide new functions, but not take away any of the old ones. Similarly, Word 6.0 will work on Windows 95 because Windows 95 provides the same facilities to Word that Windows 3.x did. This is how compatibility is maintained across changes to operating systems.
What does all this have to do with the BIOS? :^) The BIOS is actually the pillar that supports all of this, because it provides the standard interface that DOS uses (or whatever the operating system is). The system hardware itself is the "mess at the bottom of the pile" that we are trying to have to avoid dealing with. In some ways, the most amazing part of all of this is that DOS itself will run on so many different machines. The BIOS is what makes this possible. Instead of DOS having to talk directly to the hardware, of which there are many, many possibilities. It talks to the BIOS, which is what is customized to the hardware. The BIOS hides the hardware from the operating system so it doesn't have to worry about it, by providing standardized services to the operating system.
As alluded to above, programs do not always have to follow this model exactly. It is possible for a DOS program to bypass DOS and the BIOS functions, and interface directly with the hardware. This is done normally for performance reasons; games do it most often. The problem is that this breaks the compatibility model; now the software does have to figure out what hardware it is using, and this makes these types of programs much less portable and compatible than ones that "play by the rules".