System Layers


System Layers

Startupalso known as bootstrapping is the process that occurs in the period between turning a computer on and being able to use it. In previous versions of Windows, you probably didn't stick around to observe this process directly, as you felt it best to spend the time more productivelydoing the crossword puzzle, weeding the front yard, knitting a new sweater. With Windows XP, the process has been sped up to the point that you can barely fetch the newspaper before the Welcome screen is up. It would be nice to be able to just appreciate the improvement and stop there. At some point, though, you may have to take a deeper look at the startup processthis might happen when you've installed a new hardware device that causes Windows to crash upon startup, or upon finding that your computer has become infected with a virus or adware, or in order to make permanent some change that you have gotten tired of making every time you log on. When this happens, you'll need to know where to start. A lot goes on in the 30-seconds-or-less between the power switch and the Welcome Screen.

When you investigate computer hardware and software you'll repeatedly encounter the concept of layers . Computers and their operating systems are amazingly complex constructions, but they have a very definite structure. When you use an application program like Microsoft Word, the application doesn't actually "know" how to read and write data from the hard disk, or how to draw letters on the screen. It relies on the graphics and file system support layers of the operating system to do these jobs for it; the operating system layers in turn rely on device driver software to handle the particular hardware devices in your computer, and the device drivers rely on the hardware to get the job done, as illustrated in Figure 4.1. The figure shows a vastly simplified picture of the software layers in Windows.

Figure 4.1. Windows has many "layers" of software between your application and the PC's hardware.

Hardware Layers

Ultimately, all the work your computer does is performed by hardware. The CPU or CPUs in it shuffle data around; calculate where to draw the letters, images, and lines on your display; interpret the data stored on your disks; and so on. Ancillary processors also do a considerable amount of work. Every hard disk, for example, has its own dedicated CPU that is responsible for not only moving the magnetic recording head back and forth across the disk surface and generating and interpreting the recorded signals, but also for caching and optimizing the flow of data between the disk and the CPU. Graphic display adapters (video cards) have processor chips that can be far more powerful than the main CPU, although their architecture limits them to special purpose processing tasks. Of course, image generation is their intended purpose, but their talents are now being harnessed for digital signal processing, DNA sequence analysis, and other non-graphical tasks as well.

These independent devices must be controlled, coordinated, and managed by software. For the last 30 years or so, the first bit of software that runs when a microcomputer is turned on is called the BIOS.

BIOS

Basic Input Output System (BIOS) is a term that first appeared around 1976 as a component of Gary Kildall's CP/M operating system for the eight-bit Intel 8080 CPU. In early microcomputers, hardware devices were not well standardized, and the interface hardware for each computer's keyboard, display, and floppy disk drives required custom software. Loadable device drivers were not yet widely used, so to make it easier to produce a version of the operating system for a new computer model, the software drivers for the floppy drive, and serial interface or keyboard and display were stored in a separate software module; this way, the majority of the operating system and all application software could be left as is. Once the BIOS was loaded, the routine to read a character from the terminal was stored at one fixed, predetermined address, the routine to send a character to the terminal at another, and so on. CP/M and application programs could thus rely on these BIOS routines, and didn't have to directly deal with differences in hardware from one make of computer to another.

When IBM hired Microsoft to develop an operating system for the original IBM PC in 1980, CP/M quite literally served as the model, and BIOS came along with it, in both name and function. On the IBM PC, the BIOS was stored in a read-only memory chip so that it didn't need to be loaded from disk. Its first task on startup was to perform an extensive test of the computer's hardware, called the Power On Self Test, or POST. If a hardware failure was detected , the BIOS would display a code number that indicated which device had failed. If the POST was successful, the BIOS program used the computer's floppy disk drive to load in MS-DOS. As with CP/M, the PC's BIOS chip contained subroutines to display characters on the screen, read characters from the keyboard, and read and write blocks of data to and from blocks or sectors on the disk. MS-DOS, once loaded, added additional functions to manage the FAT file system, which gave programs access to directories and files.

As the PC evolved into today's version, the BIOS evolved as well. Today's BIOS is stored not in a permanently programmed Read Only Memory (ROM) chip, but in a reprogrammable FLASH chip, so that the BIOS code can be updated. The original PC had only floppy disks for storage, and about three other interface options. Today's BIOS faces hard disks with IDE, SATA, and SCSI interfaces; CD and DVD drives, ISA, PCI, PCI-Express and AGP busses ; various types of memory chips with different timing requirements; USB keyboard and mice; and a huge variety of graphics adapters. The BIOS must be able to detect, initialize, and use (in at least a primitive way) all these devices in order to boot whatever operating system is being used. In addition, most hardware devices no longer use fixed assignments for interfaces addresses and interrupts, but rely on the BIOS to enumerate (detect) the installed devices and assign them addresses and interrupts, using the Plug and Play mechanism.

Tip

If the Power On Self Test fails, most BIOSs make the PC speaker beep out a code that tells you what was wrong: memory error, missing display adapter, and so on. I've seen newer BIOSs that literally tell you what's wrong, in English, through the sound systemvery nice. But BIOSs also write code numbers that denote the particular tests being performed to a specific hardware address. You can purchase a plug-in card called a POST card for ISA or PCI-bus computers that display these codes. If the POST fails, the last displayed code tells you what failed. This type of unit can be helpful if the problem can't be displayed on the monitor or spoken aloud .


Today's BIOSs still contain routines to read the keyboard and manage the graphics adapter in a 25-line by 80-column text-only display mode, so you can still run MS-DOS on any of today's PCs, and programs that rely solely on the BIOS and MS-DOS routines to interact with hardware still work. (They may be faster than their authors ever expected, though, so you may find that a game written for an old CPU is over a few milliseconds after you start it).

BIOS support routines are designed only to be run with the CPU in real mode , where the CPU acts like an Intel 8086 16-bit processor, there is a limit of 1MB of addressable memory, and, due to the design of the PC, only 640KB of the address range is actually usable. (The BIOS actually does briefly switch the CPU to protected mode during startup in order to test and initialize memory and some hardware, but the CPU is returned to real mode before the BIOS begins the process of loading an operating system). Modern operating systems such as Linux and the 32-bit versions of Windows use the BIOS only to get the CPU started, and once their initial bits are loaded from the selected hard disk, the operating system switches the CPU to 32-bit protected mode and takes over direct control of the hardware. These operating systems use discrete, interchangeable software modules called device drivers .

Device Drivers

Device drivers are operating system components written to manage specific hardware devices. Although the driver is concerned with the intimate details of the particular make and model of hardware it's designed to control, it also shields the operating system from having to know these specific details. As far as Windows is concerned , the various categories of device drivers are just interchangeable parts , each doing the same job in exactly the same way.

For example, device drivers for graphic display adapters come in versions for each model of display adapter made, and there are dozens if not hundreds of these. Each one uses memory differently, has different mechanisms for setting resolution and update frequency, and so on. But as far as Windows is concerned, these hardware details are irrelevant; Windows can instruct the driver to shade a particular pixel on the screen a certain color , and the display adapter driver does whatever it has to do to make the hardware display that pixel. Likewise, the drivers for IDE and SCSI hard disk interfaces shield Windows itself from the details of managing those devices; Windows can, for example, simply request data block number 47 from hard disk number 2, and the disk driver will fetch it.

Part of the job of the operating system is to protect each of the system layers and user applications from interference by each other; this increases both security and reliability. On Windows NT-based operating systems like Windows 2000 and XP, user-level programs are not allowed to directly access any system hardware; the processor instructions that initiate input/output activity are blocked (or in some cases are intercepted, and the action they would have performed is simulated by the operating system using calls to the appropriate device driver). The memory ranges that correspond to device hardware interfaces are not accessible.

The reason for these restrictions is primarily to give the operating system absolute control over the hardware in an environment where several applications could attempt to perform the same action at the same time. For example, with several applications running, it might happen that two of them would attempt to write data to the disk at the same time. If allowed to access the disk hardware directly, one application might instruct the disk to move its read/write head to a certain position and then to write data at that position. Another application could decide to do the same thing, and could move the disk head to a different location, while the first was still writing. The result would be a scrambled disk.

Device drivers themselves , however, must have unfettered access to the device hardware that they manage. The majority of them run in the context of the Windows kernel, where they are permitted to execute Input/Output instructions and hardware devices. And while each application program is allowed to access only a limited amount of memory dedicated for its use, device drivers have direct access to all of the PC's memory.

This total access carries some risk: a bug in a device driver can cause it to execute inappropriate instructions or memory accesses , leading Windows to conclude that its code could have become corrupted, and as discretion is the better part of valor, this causes an immediate halt: Windows displays the infamous Blue Screen of Death (BSOD), so named because the screen is blue with white error message text. The system halts dead in its tracks and the only remedy is to cycle its power. Usually the BSOD indicates that a device driver caused the shutdown, but occasionally the bug corrupts some other driver or component, and...well, it's a nasty situation in any case.

But the advantage of a kernel driver is its faster performance. When the device driver is copying data between a hardware device and an application program, kernel mode makes it possible to copy the data in a single step. A user-mode driver would require a copy from the device to the driver's address space, then another copy from the driver to the application.

File Systems and Filters

For storage devices such as hard disks, floppy disks, CDs, and DVDs, device drivers are used to manage the disk's physical controller hardware and to read and write data. However, the data on these devices is structured into files and folders, using any of several different schemes. For example, floppy disk data is organized using a structure called the FAT-12 file system. Most Windows PC hard disks are formatted with a structure called FAT-16, FAT-32, or NTFS, and other PC operating systems such as OS/2 and Linux can use these and other file system organizations. CDs, CD-Rs, CD-RWs, and DVDs use still other formats, and then there are FLASH cards, smart cards, and other devices.

In order to maintain independence between the software that operates the hardware and the software that interprets the data stored on it, there is an additional layer of software called File System drivers.

Here's how these layers work: an application program that wants to read a file from the disk passes its request to the Win32 subsystem. If the desired file is on a disk formatted with the NTFS file system, the NTFS file system driver works out exactly where on the disk the data is located. It asks the disk drive's driver to get it, the driver instructs the disk's hardware to move to a particular location and read it, and the data is passed back up through the same chain.

Now, added to this picture are other drivers called filters that position themselves in between any of the layers we've described so far. Filters can let requests move down through the layers and their results come back up, or they can intercept the flow of data and take some other action.

One use of the filter mechanism is to allow a developer to add support for some new feature, file system, or device that hasn't been conceived yet.

Another use of the filter mechanism is to add a security feature. For example, antivirus programs add filter drivers just above the file system drivers, where they intercept requests for reading data from your drives. When the data has been read, they can examine it all before any other program has a chance to see it, and can take appropriate action if they decide the data contains a virus program.

Services

Device drivers have unhindered, unprotected access to hardware. A great many of the internal functions of Windows don't need to have the kernel's unrestricted access, but they do need to run all the time, whether you're logged in or not, and they may need high privileges. Examples of these functions are the Automatic Update service, which downloads and installs critical Windows security patches, the Windows Firewall, which monitors all network activity and blocks attempts by outsiders to hack into your system, and the Print Spooler, which manages the flow of data to your printers.

Most operating systems provide a means of having programs run independently of any logged-on user. On UNIX and Linux, they're called daemons , and on Windows, they're called services . A Windows service is a program that can be started automatically when Windows starts up, and which provides some essential function. In most cases, services do their jobs without interacting with the keyboard, mouse or display at all. It's possible, though uncommon, for a service for display a message on the screen. The Print Spooler is one service that does thiswhen a printer jams, the Print Spooler service pops up a message. But most do their job silently, and in the event of a problem usually just record an error message in the Windows Event Log.

We'll discuss services in greater detail later in the chapter.




Upgrading and Repairing Microsoft Windows
Upgrading and Repairing Microsoft Windows (2nd Edition)
ISBN: 0789736950
EAN: 2147483647
Year: 2005
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net