Troubleshooting, Maintaining & Repairing PCs
Stephen Bigelow
 $54.95  0-07-913732-6
Backward Forward
Chapter: 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53

Reserve your copy at a
Beta Bookstore near you!
Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.

CHAPTER 6

Operating systems and the boot process

As a technician, it is vital for you to understand the relationship between PC hardware and software. In the early days of computers, hardware was typically the center of attention. Since early software was written for a specific computer (such as a DEC PDP system or IBM Vax), and early computers were very limited in their storage and processing capacity, software often arrived as an "afterthought" (we still see software development lagging behind hardware advances to this day). With the introduction of personal computers in the mid 1970s, designers realized that a wide selection of software would be needed to make PCs attractive. Instead of writing software specifically for particular machines, a uniform environment would be needed to manage system resources and launch applications. In this way, applications would be portable between systems whose hardware resources would otherwise be incompatible. This "uniform applications environment" became known as the operating system (or OS). When IBM designed the PC, they chose to license a simple operating system from a fledgling company called Microsoft - and the rest is history.

Although this book is dedicated to dealing with PC hardware (since it is the hardware that "breaks"), you must realize that the operating system has a profound effect on PC resources, and how those resources are allocated to individual software applications. This is especially true of the more sophisticated operating systems such as Windows 95 and OS/2 Warp. Every good technician is sensitive to the fact that problems with an OS will result in problems with PC performance. This chapter explains the relationship between PC hardware and software, illustrates some of the major features found in typical operating systems, and walks you through a typical PC boot process.

The PC hierarchy

Before we dig into the operating system itself, you should understand the complex (and often frustrating) relationship between computer hardware and software. This relationship is often expressed as a hierarchy shown in the diagram of Fig. 6-1. Each layer in the hierarchy serves a very specific function in PC operation. There are four levels to this hierarchy; the hardware, the BIOS, the OS, and the application(s).

Hardware

As you might expect, hardware forms the core of a PC hierarchy - there is no computer without the hardware. The hardware includes all of the circuits, drives, expansion boards, power supplies, peripheral devices, and their interconnecting wiring or cables. This extends not only to the PC itself, but to monitors, keyboards, pointing devices, printers, and so on. By sending digital information to various ports or addresses in memory, it is possible to manipulate almost anything attached to the system CPU. Unfortunately, controlling PC hardware is a difficult process which requires an intimate knowledge of a PC's electronic architecture. How is it that Microsoft can sell an operating system that works on an i286-based AT, as well as a new Pentium-based system? Since each PC manufacturer designs their circuitry (especially motherboard circuitry) differently, it is virtually impossible to create a "universal" operating system without some sort of interface between the one standard OS and the myriad variations of hardware in the marketplace. This interface is accomplished by the Basic Input/Output System (BIOS).

BIOS

Simply put, a BIOS is a set of small programs (or services) that are designed to operate each major PC subsystem (i.e. video, disk, keyboard, and so on). Each of these BIOS Services is invoked by a set of standard calls - originally developed by IBM - which are made from the operating system. When the operating system requests a standard BIOS service, the particular BIOS program will perform the appropriate function tailored to the particular hardware. Thus, each PC design requires its own BIOS. Using this methodology, BIOS acts as a "glue" which allows diverse (and older) hardware to operate with a single uniform OS. In addition to services, the BIOS runs a power-on self-test (POST) program each time the PC is initialized. POST checks the major subsystems before attempting to load an operating system.

Since BIOS is specific to each PC design, BIOS resides on the motherboard in the form of a read-only memory (ROM) IC, although newer systems employ electrically-rewritable (or "flash") ROMs which allow the BIOS to be updated without having to replace the BIOS ROM IC. You may see BIOS referred to as firmware rather then software since it software permanently recorded on an IC. As you might imagine, the efficiency and accuracy of BIOS code will have a profound impact on the overall operation of a PC - better BIOS routines will result in superior system performance, while clumsy, inefficient BIOS routines can easily bog a system down. Bugs (software errors) in BIOS can have very serious consequences for the system (such as lost files and system lockups).

Operating System

The operating system serves two very important functions in the modern PC. First, an OS interacts with, and provides an extension to the BIOS. This extension provides applications with a rich selection of high-level file handling and disk control functions. It is this large number of disk-related functions which added the term "disk" to "operating system" (i.e. disk operating system or DOS). When an application needs to perform disk access or file handling, it is the DOS layer which performs most of the work. By providing access to a library of frequently-used functions through DOS, application programs can be written without the need to incorporate the code for such complex functions into each application itself. In actual operation, the OS and BIOS work closely together to give an application easy access to system resources.

Second, an OS forms an "environment" (or shell) through which applications can be executed, and provides a user interface allowing you and your customers to interact with the PC. MS-DOS uses a keyboard driven, command-line interface signified by the command-line prompt (such as C:>_) which we have become so familiar with. By contrast, the Windows family of operating systems provides a graphical user interface (GUI) relying on symbols and icons which are selected with a mouse or other pointing device.

Applications

Ultimately, the aim of a computer is to execute applications (such as games, word processors, spreadsheets, and so on). An OS loads and allows the user to launch the desired application(s). As the application requires system resources during run-time, it will make an appropriate call to DOS or BIOS, which in turn will access the needed function and return any needed information to the calling application. The actual dynamics of such an exchange is more complex than described here, but you get the general idea. Now that you have seen an overview of the typical PC hierarchy and understand how each layer interacts with one another, it is time to take a closer look at the OS layer itself.

Understanding popular OS features

There are many different operating systems written for today’s computers. The range and complexity of operating systems spans the entire spectrum of features and complexity - some are large, complex, commercial giants (such as Windows 95 and Windows NT), while others are small, freely-distributed packages (like FreeBSD). Other operating systems are tailored for such features as real-time operation, true or high-performance multitasking, or networking. New specialized operating systems are regularly being introduced to support particular systems such as process control, manufacturing, or other "mission critical" needs. Table 6-1 offers a partial listing of today’s available operating systems. As a technician, you should understand the important features of today’s operating systems, and why one OS might be selected over another. The following sections offer some highlights of the major commercial operating systems offered by Microsoft and IBM.

MS-DOS 6.22

MS-DOS 6.22 is the last "stand-alone" command-line operating system designed by Microsoft for the PC, and is generally considered to be one of the most versatile and reliable DOS-type OS ever released by Microsoft. There are numerous safety features and enhancements designed to provide the safest possible computing environment of any MS-DOS version. The most notable features are outlined below. Table 6-2 highlights the system requirements for MS-DOS 6.22.

PC-DOS 7.0

PC-DOS is IBM’s answer to MS-DOS. Early versions of PC-DOS were actually licensed to IBM from Microsoft, but the two giants eventually parted company, and IBM continued the development of PC-DOS under their own banner. Today, PC-DOS 7.0 is roughly equivalent in features and performance to MS-DOS 6.22 - including disk compression, anti-virus software, and limited networking features. System requirements are about the same, but PC-DOS 7.0 includes PCMCIA support, a DOS file update feature (to keep files synchronized between PCs), and a high-level programming language called REXX.

Windows 95

Microsoft released Windows 95 in August of 1995 as the major upgrade to Windows 3.1x. Windows 95 was designed to offer superior performance while taking advantage of emerging PC hardware such as Plug-and-Play, power conservation, PCI bus architecture, and so on. Windows 95 runs most Windows 3.1x and DOS programs, but also supports improved features like a built-in uninstaller, dial-up networking, multitasking, and long file names. Though aging, Windows 95 is currently the most popular commercial OS for the personal computer.

OS/2 Warp 4.x

OS/2 Warp has long been IBM’s premier OS. Originally co-developed with Microsoft, OS/2 development continued in-house after IBM and Microsoft ceased their cooperative ventures. OS/2 is a GUI-based operating system capable of running most Windows and DOS software, as well as native OS/2 applications in a true multitasking environment. OS/2 Warp 4.x focuses on network operations and connectivity - including built-in Internet applications - and offers an advantage over competing operating systems with its use of voice input controls. In spite of these advantages, OS/2 is noted for a surprising lack of hardware support. For example, it can be surprisingly difficult to find suitable OS/2 drivers for devices such as CD-ROM drives and sound boards.

Windows CE

Windows CE is designed to serve as an operating system for a broad range of communications, entertainment, and mobile-computing devices. It also enables new types of non-PC business and consumer devices that can communicate with each other, share information with Windows-based PCs, and connect to the Internet (i.e. "wallet" PCs, digital information pagers, cellular smart phones, DVD players, and Internet "web phones". The first hand-held PC products based on Windows CE began shipping in November 1996. It is important to note that Windows CE is strictly released as an OEM product, and cannot be purchased through retail channels.

Windows NT (Workstation)

Windows NT represents Microsoft’s emphasis on business communication and networking. While the "look and feel" of Windows NT may seem quite similar to Windows 95, NT incorporates a powerful suite of networking and Internet-related features backed up by detailed security, cryptography, and system policies configurations. Windows NT also abandons "DOS-mode" support. There is no doubt that Windows NT represents one of the most complex and versatile operating systems now in service for business and networking environments.

Windows 98

With the many new hardware standards and features being developed for the PC, Windows 95 is becoming hard-pressed to make the fullest use of system resources. Windows 98 (previously code-named "Memphis") builds on Windows 95 by adding a rich suite of refinements and improvements to a full 32-bit operating system. New wizards, utilities, and resources work proactively to keep systems running more smoothly. Performance is faster for many common tasks such as application loading, system startup, and shut down. Full integration with the Internet’s world wide web aids online work and system versatility. As of this writing, Windows 98 has entered the Beta 2 phase, and should be released around the second quarter of 1998. The following notes outline some of the features planned for Windows 98:

A closer look at MS-DOS

The operating system provides I/O resources to application programs, as well as an environment that can be used to execute programs or interact with the operating system. To accomplish these two tasks, MS-DOS uses three files; IO.SYS, MSDOS.SYS, and COMMAND.COM. Note that the myriad of other files shipped with MS-DOS are technically NOT part of the operating system itself, but are instead a library of utilities intended to help you optimize and maintain the system. The following sections examine each of the three core MS-DOS files in more detail. Keep in mind that loading and running an operating system properly relies on adequate processing, memory, and disk system resources.

IO.SYS

The IO.SYS file provides many of the low-level routines (or drivers) that interact with BIOS. Some versions of IO.SYS are customized by original equipment manufacturers (OEMs) to supplement the particular BIOS for their system. However, OS customization is rare today because it leads to system incompatibilities. In addition to low-level drivers, IO.SYS contains a system initialization routine. The entire contents of the file (except for the system initialization routine) is kept in low memory throughout system operation. IO.SYS is a file assigned with a hidden-file attribute, so you will not see the file when searching a bootable disk with an ordinary DIR command. Although Microsoft uses the filename IO.SYS, other OS makers may use a different name. For example, the corresponding file name in IBM's PC-DOS is IBMBIO.COM.

In order for a disk (floppy or hard disk) to be bootable under MS-DOS 3.x or 4.x, IO.SYS must be the first file in the disk directory, and it must occupy at least the first available cluster on the disk (usually cluster 2). This is the disk's OS volume boot sector. Of course, subsequent clusters containing IO.SYS can be placed anywhere in the disk just like any other ordinary file. MS-DOS 5.x and later eliminate this requirement and allow IO.SYS to be placed in any root directory location anywhere on the disk. When disk access begins during the boot process, the bootable drive's boot sector is read which loads IO.SYS into memory and gives it control of the system. Once IO.SYS is running, the boot process can continue as you will learn later in this chapter. If this file is missing or corrupt, you will see some type of boot failure message, or the system may lock up.

MSDOS.SYS

This is the core of MS-DOS versions up through 6.22. The MSDOS.SYS file is listed second in the boot disk's directory, and is the second file to be loaded during the boot process. It contains the routines that handle OS disk and file access. Like IO.SYS, the MSDOS.SYS file is loaded into low memory where it resides throughout the system's operation. If the file is missing or corrupt, you will see some kind of boot failure message, or the system may lock up.

IO.SYS and MSDOS.SYS variations under Windows 95

With the introduction of Windows 95, the classical DOS files have been redesigned to streamline the boot process. Windows 95 places all of the functions found in IO.SYS and MSDOS.SYS into a single hidden file called IO.SYS (this file may be renamed WINBOOT.SYS if you start the PC with a previous OS). Most of the options formerly set with entries in the CONFIG.SYS file are now incorporated into Windows 95’s IO.SYS. The settings that are selected with IO.SYS can be superseded by entries in a CONFIG.SYS file, but the defaults used with IO.SYS are listed below.

NOTE: Few of the default settings in IO.SYS are really needed by Windows 95, but they are included to provide a level of backward compatibility with pre-existing system configurations.

The MSDOS.SYS file has also been dramatically altered under Windows 95. Where older versions of MS-DOS relied on MSDOS.SYS for disk and file code, all of that functionality has been worked into IO.SYS. MSDOS.SYS under Windows 95 is now little more than a text .INI file which is used to configure the boot properties of Windows, and list important paths to key Windows files (including the registry).

Adjusting MSDOS.SYS under MS-DOS 7.x

Windows 95 essentially eliminates the function of the MSDOS.SYS file - replacing it instead with a text file used to tailor the startup process. Normally, there is little need to access the MSDOS.SYS file, but you may be faced with the need to adjust the Windows 95 boot process. This part of the chapter takes you inside the MSDOS.SYS file for MS-DOS 7.x (Windows 95), and illustrates the various options you can use to enhance the Windows 95 platform. A typical example of an MSDOS.SYS file is shown in Fig. 6-2.

NOTE: Notice that MSDOS.SYS must be longer than 1024 bytes in length. Otherwise, Windows 95 will fail to load. Do not alter or remove the "x" lines in MSDOS.SYS.

There are two main sections to the MSDOS.SYS file: the [Paths] section, and the [Options] section. Paths defines the directory paths to major Windows file areas, while Options allow you to configure many of the available attributes used to boot a Windows 95 system. The Options are listed below:

[Paths]

WinDir= Indicates the location of the Windows 95 directory specified during Setup.

WinBootDir= Indicates the location of the necessary startup files. The default is the directory

specified during the Setup process (i.e. C :\WINDOWS).

HostWinBootDrv=c Indicates the location of the boot drive root directory.

[Options]

BootMulti= This enables dual-boot capabilities. The default is 0. Setting this value to 1

enables the ability to start MS-DOS by pressing <F4>, or by pressing <F8> to

use the Windows Startup menu.

BootGUI= This enables automatic graphical startup into Windows 95. The default is 1.

BootMenu= This enables automatic display of the Windows 95 Startup menu (the user must

press <F8> to see the menu). The default is 0. Setting this value to 1

eliminates the need to press <F8> to see the menu.

BootKeys= This enables the startup option keys (i.e. F5, F6, and F8). The default is 1.

BootWin= This enables Windows 95 as the default operating system. Setting this value to

0 disables Windows 95 as the default (useful only with MS-DOS version 5 or 6.x

on the computer). The default is 1.

BootDelay=n This sets the initial startup delay to n seconds (default is 2). A BootKeys=0 entry

disables the delay. The only purpose of the delay is to give the user sufficient

time to press <F8> after the Starting Windows message appears.

BootFailSafe= This enables Safe Mode for system startup. The default is 0.

BootMenuDefault=# This sets the default menu item on the Windows Startup menu; the default is 3

for a computer with no networking components, and 4 for a networked computer.

BootMenuDelay=# This sets the number of seconds to display the Windows Startup menu before

running the default menu item. The default is 30 seconds.

Logo= This enables display of the Windows 95 logo. The default is 1. Setting this

value to 0 also avoids hooking a variety of interrupts that can create

incompatibilities with certain memory managers from other vendors.

BootWarn= This enables the Safe Mode startup warning. The default is 1.

DblSpace= This enables automatic loading of DBLSPACE.BIN. The default is 1.

DrvSpace= This enables automatic loading of DRVSPACE.BIN. The default is 1.

DoubleBuffer= This enables loading of a double-buffering driver for a SCSI controller. The

default is 0. Setting this value to 1 enables double-buffering (if required by the

SCSI controller).

LoadTop= This enables the loading of COMMAND.COM or DRVSPACE.BIN at the top of

640KB memory. The default is 1. Set this value to 0 with Novell NetWare or

any software that makes assumptions about what is used in specific memory

areas.

Network= This enables "Safe Mode with Networking" as a menu option. The default is 1

for computers with networking installed. This value should be 0 if network

software components are not installed.

NOTE: If Windows 95 is installed in its own directory, the earlier version of MS-DOS is preserved on the hard disk. If you set BootMulti=1 in MSDOS.SYS, you can start the earlier version of MS-DOS by pressing <F4> when starting Windows 95.

COMMAND.COM

The COMMAND.COM file is serves as the MS-DOS shell and command processor. This is the program that you are interacting with at the command-line prompt. COMMAND.COM is the third file loaded when a PC boots, and it is stored in low memory along with IO.SYS and MSDOS.SYS. The number of commands that you have available depend on the version of MS-DOS in use. MS-DOS uses two types of commands in normal operation; resident and transient.

Resident commands (also called "internal" commands) are procedures that are coded directly into COMMAND.COM. As a result, resident commands execute almost immediately when called from the command line. CLS and DIR are two typical resident commands. Transient commands (also called "external" commands) represent a broader and more powerful group of commands. However, transient commands are not loaded with COMMAND.COM. Instead, the commands are available as small .COM or .EXE utility files in the DOS directory (such as DEBUG and EMM386). Transient commands must be loaded from the disk and executed each time they are needed. By pulling out complex commands are separate utilities, the size of COMMAND.COM can be kept relatively small. A table of transient (external) commands for MS-DOS are shown in Table 6-3, and the resident (internal) commands for MS-DOS are listed in Table 6-4.

Recognizing and dealing with OS problems

Since the operating system is an integral part of the PC, any problems with using or upgrading the OS can adversely effect system operation. Software does not fail like hardware - once software is loaded and running, it will not eventually break down from heat or physical stress. Unfortunately, software is hardly perfect. Upgrading from one OS to another can upset the system's operation, and bugs in the operating system can result in unforeseen operation that might totally destroy a system's reliability.

Virtually all versions of operating systems have bugs in them - especially in early releases. In most cases, such bugs are found in the transient commands that are run from the command line rather than in the three core files (IO.SYS, MSDOS.SYS, and COMMAND.COM). Even the latest stand-alone version of MD-DOS (6.22) has endured several incarnations since its initial release as 6.0. As a technician, you should be sensitive to the version of DOS (and Windows) being used by your customer. Whenever the customer complains of trouble using a DOS utility (such as BACKUP or EMM386), or complains of difficulties using particular software under DOS, one of your first steps should be to ensure that the version in use is appropriate. If it has been updated, you should try the new release. Remember that a software fault can manifest itself as a hardware problem - that is, the hardware may malfunction of refuse to respond. Check with the OS maker to find their newest releases and fixes. Microsoft maintains an extensive web site for the support of their operating systems. Check in regularly to find error reports and upgrades.

Another concern for technicians is dealing with old versions of an OS. Remember that part of the task of an OS is to manage system resources (i.e. disk space, memory, and so on). New OS versions such as MS-DOS 5.0 and later, do a much better job of disk and memory management than MS-DOS 4.x and earlier. Should you recommend an upgrade to your customer? As a general rule, any MS-DOS version older than 5.0 is worth upgrading to MS-DOS 6.22 - especially if your customer is planning to keep or upgrade the PC. If the MS-DOS version is 5.0 or later, the only good reason to upgrade would be to take advantage of advanced utilities such as MemMaker or DoubleSpace which have been refined and included with MS-DOS 6.22. If the PC hardware will support an upgrade to Windows 95 or Windows 98, it should also be considered as a potential OS upgrade.

The boot process

Computer initialization is a process - not en event. From the moment power is applied until the system sits idle at the command-line prompt or graphical desktop, the PC boot process is a sequence of predictable steps that verify the system and prepare it for operation. By understanding each step in system initialization, you can develop a real appreciation for the way that hardware and software relate to one another - you also stand a much better chance of identifying and resolving problems when a system fails to boot properly. This part of the chapter provides a step-by-step review of a typical PC boot process.

Applying power

PC initialization starts when you turn the system on. When all output voltages from the power supply are valid, the supply generates a Power Good (PG) logic signal. It can take between 100ms and 500ms for the supply to generate a PG signal. When the motherboard timer IC receives the PG signal, the timer stops forcing a Reset signal to the CPU. At this point, the CPU starts processing.

The bootstrap

The very first operation performed by a CPU is to fetch an instruction from address FFFF:0000h. Since this address is almost at the end of available ROM space, the instruction is almost always a jump command (JMP) followed by the actual BIOS ROM starting address. By making all CPUs start at the same point, the BIOS ROM can then send program control anywhere in the particular ROM (and each ROM is usually different). This initial search of address FFFF:0000h and the subsequent re-direction of the CPU is traditionally referred to as the bootstrap in which the PC "pulls itself up by its bootstraps" - or gets itself going. Today, we have shortened the term to boot, and have broadened its meaning to include the entire initialization process.

Core tests

The core tests are part of the overall Power-On Self-Test (POST) sequence which is the most important use of a system BIOS during initialization. As you might expect, allowing the system to initialize and run with flaws in the motherboard, memory, or drive systems can have catastrophic consequences for files in memory or on disk. To insure system integrity, a set of hardware-specific self-test routines checks the major motherboard components, and identifies the presence of any other specialized BIOS ICs in the system (i.e. drive controller BIOS, video BIOS, SCSI BIOS, and so on).

BIOS starts with a test of the motherboard hardware such as the CPU, math co-processor, timer ICs, direct memory access (DMA) controllers, and interrupt (IRQ) controllers. If an error is detected in this early phase of testing, a series of beeps (or beep codes) are produced. By knowing the BIOS manufacturer and the beep code, you can determine the nature of the problem. Chapter 19 deals with beep and error codes in more detail. Beep codes are used because the video system has not been initialized.

Next, BIOS looks for the presence of a video ROM between memory locations C000:0000h through C780:000h. In just about all systems, the search will reveal a video BIOS ROM on a video adapter board plugged into an available expansion slot. If a video BIOS is found, its contents are evaluated with a checksum test. If the test is successful, control is transferred to the video BIOS which loads and initializes the video adapter. When initialization is complete, you will see a cursor on the screen, and control returns to the system BIOS. When no external video adapter BIOS is located, the system BIOS will provide an initialization routine for the motherboard's video adapter, and a cursor will also appear. Once the video system initializes, you are likely to see a bit of text on the display identifying the system or video BIOS ROM maker and revision level. If the checksum test fails, you will see an error message such as; C000 ROM Error or Video ROM Error. Initialization will usually halt right there.

Now that the video system is ready, system BIOS will scan memory from C800:0000h through DF80:0000h in 2KB increments to search for any other ROMs that might be on other adapter cards in the system. If other ROMs are found, their contents are tested and run. As each supplemental ROM is executed, they will show manufacturer and revision ID information. In some cases, a supplemental (or "adapter") ROM may alter an existing BIOS ROM routine. For example, an Ultra DMA/33 drive controller board with its own on-board ROM will replace the motherboard’s older drive routines. When a ROM fails the checksum test, you will see an error message such as; XXXX ROM Error. The XXXX indicates the segment address where the faulty ROM was detected. When a faulty ROM is detected, system initialization will usually halt.

POST

BIOS then checks the memory location at 0000:0472h. This address contains a flag that determines whether the initialization is a cold start (power first applied) or a warm start (reset button or <Ctrl>+<Alt>+<Del> key combination). A value of 1234h at this address indicates a warm start - in which case the (POST) routine is skipped. If any other value is found at that location, a cold start is assumed, and the full POST routine will be executed.

The full POST checks many of the other higher-level functions on the motherboard, memory, keyboard, video adapter, floppy drive, math co-processor, printer port, serial port, hard drive, and other sub-systems. There are dozens of tests performed by the POST. When an error is encountered, the single-byte POST code is written to I/O port 80h where it may be read by a POST code reader. In other cases, you may see an error message on the display (and system initialization will halt). Keep in mind that POST codes and their meanings will vary slightly between BIOS manufacturers. If the POST completes successfully, the system will respond with a single beep from the speaker. Chapter 19 covers I/O port POST codes.

Finding the OS

The system now needs to load an operating system (usually DOS or Windows 95). The first step here is to have the BIOS search for a DOS volume boot sector (VBS) on the A: drive. If there is no disk in the drive, you will see the drive light illuminate briefly, and then BIOS will search the next drive in the boot order (usually drive C:). If there is a disk in drive A:, BIOS will load sector 1 (head 0 cylinder 0) from the disk's DOS volume boot sector into memory starting at 0000:7C00h. There are a number of potential problems when attempting to load the VBS. Otherwise, the first program in the directory (IO.SYS) will begin to load, followed by MSDOS.SYS.

If the OS cannot be loaded from any floppy drive, the system will search the first fixed drive (hard drive). Hard drives are a bit more involved than floppy disks. BIOS loads sector 1 (head 0 cylinder 0) from the hard drive's master partition boot sector (called the "master boot sector" or MBS) into memory starting at 0000:7C00h, and the last two bytes of the sector are checked. If the final two bytes of the master partition boot sector are NOT 55h and AAh respectively, the boot sector is invalid, and you will see an error message similar to; No boot device available and system initialization will halt. Other systems may depict the error differently, or attempt to load ROM BASIC. If the BIOS attempts to load ROM BASIC, and there is no such feature in the BIOS, you’ll see a ROM BASIC error message.

Otherwise, the disk will search for and identify any extended partitions (up to 24 total partitions). Once any extended partitions have been identified, the drive's original boot sector will search for a boot indicator byte marking a partition as active and bootable. If none of the partitions are marked as bootable (or if more than one partition is marked bootable), a disk error message will be displayed such as; Invalid partition table. Some older BIOS versions may attempt to load ROM BASIC, but will generate an error message in most cases anyway.

When an active bootable partition is found in the master partition boot sector, the DOS volume boot sector (VBS) from the bootable partition is loaded into memory and tested. If the DOS volume boot sector cannot be read, you will see an error message similar to; Error loading operating system. When the DOS volume boot sector does load, the last two bytes are tested for a signature of 55h and AAh respectively. If these signature bytes are missing, you will see an error message such as; Missing operating system. Under either error condition, system initialization will halt.

After the signature bytes are identified, the DOS volume boot sector (now in memory) is executed as if it were a program. This "program" checks the root directory to ensure that IO.SYS and MSDOS.SYS (or IBMBIO.COM and IBMDOS.COM) are available. In older MS-DOS versions, IO.SYS and MSDOS.SYS have to be the first two directory entries. If the DOS volume boot sector was created with MS-DOS 3.3 or earlier and the two startup files are not the first two files in the directory (or there is an error in loading the files), the system will produce an error code such as; Non-System disk or disk error. If the boot sector is corrupt, you may see a message like; Disk boot failure.

Loading the OS

If there are no problems detected in the disk's DOS volume boot sector, IO.SYS (or IBMBIO.COM) is loaded and executed. If Windows 95 is on the system, IO.SYS may be renamed WINBOOT.SYS which will be executed instead. IO.SYS contains extensions to BIOS that start low level device drivers for such things as the keyboard, printer, and block devices. Remember that IO.SYS also contains initialization code that is only needed during system startup. A copy of this initialization code is placed at the top of conventional memory which takes over initialization. The next step is to load MSDOS.SYS (or IBMDOS.COM) which is loaded such that it overlaps the part of IO.SYS containing the initialization code. MSDOS.SYS (the MS-DOS kernel) is then executed to initialize base device drivers, detect system status, reset the disk system, initialize devices such as the printer and serial port, and set up system default parameters. The MS-DOS essentials are now loaded, and control returns to the IO.SYS/WINBOOT.SYS initialization code in memory.

NOTE: For Windows 95 systems, IO.SYS (or WINBOOT.SYS) combines the functions of IO.SYS and MSDOS.SYS.

Establishing the environment

If a CONFIG.SYS file is present, it is opened and read by IO.SYS/WINBOOT.SYS. The DEVICE statements are processed first in the order they appear, then INSTALL statements are processed in the order they appear. A SHELL statement is handled next. If no SHELL statement is present, the COMMAND.COM processor is loaded. When COMMAND.COM is loaded, it overwrites the initialization code left over from IO.SYS (which is now no longer needed). Under Windows 95, COMMAND.COM is loaded only if an AUTOEXEC.BAT file is present in order to process the AUTOEXEC.BAT statements. Finally, all other statements in CONFIG.SYS are processed, and WINBOOT.SYS also looks for the SYSTEM.DAT registry file.

When an AUTOEXEC.BAT file is present, COMMAND.COM (which now has control of the system) will load and execute the batch file. After batch file processing is complete, the familiar DOS prompt will appear. If there is no AUTOEXEC.BAT in the root directory, COMMAND.COM will request the current DATE and TIME, then show the DOS prompt. You may now launch applications, or use any available OS commands. AUTOEXEC.BAT may also call a shell (such as Windows 3.1x) or start an application. Under Windows 95, IO.SYS/WINBOOT.SYS automatically loads HIMEM.SYS, IFSHLP.SYS, and SETVER.EXE, then loads the WIN.COM kernel to officially start Windows 95.

Creating a DOS boot disk

The most persistent problem with PC troubleshooting is that it can be difficult to boot a system successfully - especially if there are hard drive problems. This makes it particularly important to have a bootable floppy diskette on-hand. There are two means of creating a boot disk; automatically through an existing Windows 95 platform, or manually through a DOS 6.22 platform. In either case, you’re going to need access to a running PC with an operating system similar to the version you plan to install on the new PC.

Windows 95 - Windows 95 comes with an automatic "Startup Disk" maker. If you have access to a Windows 95 system, use the following procedure to create a DOS 7.x startup disk:

The preparation process takes several minutes, and will copy the following files to your diskette; ATTRIB, CHKDSK, COMMAND, DEBUG, DRVSPACE.BIN, EDIT, FDISK, FORMAT, REGEDIT, SCANDISK, SYS, and UNINSTAL. All of these files are DOS 7.x-based files, so you can run them from the A: prompt.

NOTE: The Windows 95 FDISK utility has been reported to have a bug which can cause problems when creating more than one partition on the same drive. Later releases of Windows 95 (i.e. OSR 2) claim to have corrected this issue, but if you encounter problems with FDISK, use the DOS 6.22 version.

DOS 6.22 - If you don’t have access to a system with Windows 95 already, you’ll need to make a boot disk manually using DOS 6.22 utilities. Create a bootable diskette by using the SYS feature such as;

C:\DOS\> SYS A: <Enter>

or use the FORMAT command to make a bootable diskette like;

C:\DOS\> FORMAT A: /S <Enter>

Once the diskette is bootable, copy the following DOS utilities (usually from the DOS directory); FDISK, FORMAT, SYS, MEM, DEFRAG, SCANDISK, EDIT, HIMEM, EMM386, and EDIT. You may not need all of these utilities, but it can be handy to have them on-hand in case you need to check a disk or memory.

Further study

That concludes Chapter 6. Be sure to review the glossary and chapter questions on the accompanying CD. If you have access to the Internet, point your web browser to some of the contacts below (also check out some of the URLs listed in Table 6-1):

IBM: http://www.software.ibm.com/os/warp/warp-client/

Microsoft: http://www.microsoft.com

Novell: http://www.novell.com

V Communications (System Commander): http://www.v-com.com

Backward Forward
Chapter: 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53

Reserve your copy at a
Beta Bookstore near you!
Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Beta Books | Beta Bookstores | Computing McGraw-Hill

Professional Publishing Home | Contact Us | Customer Service | For Authors | International Offices | New Book Alert | Search Catalog/Order | Site Map | What's New


A Division of the McGraw-Hill Companies
Copyright © 1998 The McGraw-Hill Companies. All rights reserved. Any use is subject to the Terms of Use; the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers.