'; window.popUpWin.document.write(zhtm); window.popUpWin.document.close(); // Johnny Jackson 4/28/98 } //-->

Upgrading & Repairing PCs

Operating Systems Software and Troubleshooting

This chapter focuses on the problems that occur in PC systems because of faulty or incompatible software. First, it describes the structure of DOS and how DOS works with hardware in a functioning system. Topics of particular interest are as follows:

The chapter also examines two other important software-related issues: using memory-resident software (and dealing with the problems it can cause), and distinguishing a software problem from a hardware problem. Finally, the chapter examines the Windows 95 and Windows NT operating systems that have all but taken over the desktop, and how their relationship with the PC hardware differs from that of DOS.

Disk Operating System (DOS)

Information about DOS may seem out of place in a book about hardware upgrade and repair, but if you ignore DOS and other software when you troubleshoot a system, you can miss a number of problems. The best system troubleshooters and diagnosticians know the entire system--hardware and software.

Note that Windows 95, by default, still uses the same structures on the disk as DOS does, such as the Master Boot Record (MBR), DOS Boot Record (DBR), File Allocation Tables (FATs), and directories. There are a few enhancements to the directory structure in order to support long file names, but that's about it. However, the OEM Service Release 2 of Windows 95 includes a 32-bit FAT file system that breaks the current partition size barrier of 2G for DOS and Windows 95 partitions. Note that the OS/2 HPFS (High Performance File System) supports single partitions of up to 8G and NTFS (the Windows NT File System) can support 2T partitions (2T = 2,000G).

This section describes the basics of DOS: where it fits into the PC system architecture, what its components are, and what happens when a system boots (starts up). Understanding the booting process can be helpful when diagnosing startup problems. This section also explains DOS configuration--an area in which many people experience problems--the file formats DOS uses, as well as how DOS manages information on a disk.

Operating System Basics

DOS is just one component in the total system architecture. A PC system has a distinct hierarchy of software that controls the system at all times. Even when you are operating within an application program such as a word processor, several other layers of programs are always executing underneath. Usually the layers can be defined distinctly, but sometimes the boundaries are vague.

Communications generally occur only between adjoining layers in the architecture, but this rule is not absolute. Many programs ignore the services provided by the layer directly beneath them and eliminate the middleman by skipping one or more layers. An example is a program that ignores the DOS and ROM BIOS video routines and communicates directly with the hardware in the interest of the highest possible screen performance. Although the high performance goal is admirable, many operating systems (such as OS/2 and Windows NT) no longer allow direct access to the hardware. Programs that do not play by the rules must be rewritten to run in these new environments.

The hardware is at the lowest level of the system hierarchy. By placing various bytes of information at certain ports or locations within a system's memory structure, you can control virtually anything connected to the CPU. Maintaining control at the hardware level is difficult; doing so requires a complete and accurate knowledge of the system architecture. The level of detail required in writing the software operating at this level is the most intense. Commands to the system at this level are in machine language (binary groups of information applied directly to the microprocessor). Machine language instructions are limited in their function: You must use many of them to perform even the smallest amount of useful work. The large number of instructions required is not really a problem because these instructions are executed extremely rapidly, wasting few system resources.

Programmers can write code consisting of machine language instructions, but generally they use a tool--an assembler--to ease the process. They write programs using an editor, and then use the assembler to convert the editor's output to pure machine language. Assembler commands are still very low level, and using them effectively requires that programmers be extremely knowledgeable. No one (in his or her right mind) writes directly in machine code anymore; assembly language is the lowest level programming environment typically used today. Even assembly language, however, is losing favor among programmers because of the amount of knowledge and work required to complete even simple tasks, and because of its lack of portability between different kinds of systems.

When you start a PC system, a series of machine code programs, the ROM BIOS, assumes control. This set of programs, always present in a system, talks (in machine code) to the hardware. The BIOS accepts or interprets commands supplied by programs above it in the system hierarchy and translates them to machine code commands that then are passed on to the microprocessor. Commands at this level typically are called interrupts or services. A programmer can use nearly any language to supply these instructions to the BIOS.

DOS itself is made up of several components. It attaches to the BIOS, and part of DOS actually becomes an extension of the BIOS, providing more interrupts and services for other programs to use. DOS provides for communication with the ROM BIOS in PCs and with higher level software (such as applications). Because DOS gives the programmer interrupts and services to use in addition to those provided by the ROM BIOS, a lot of "reinventing the wheel" in programming routines is eliminated. For example, DOS provides a rich set of functions that can open, close, find, delete, create, and rename files, as well as perform other file-handling tasks. When programmers want to include some of these functions in their programs, they can rely on DOS to do most of the work.

This standard set of functions that applications use to read data from and write it to disks makes data recovery operations possible. Imagine how tough writing programs and using computers would be if every application program had to implement its own custom disk interface, with a proprietary directory and file retrieval system. Every application would require its own special disks. Fortunately, DOS provides a standard set of documented file storage and retrieval routines that can be used by all software applications. As a result, you can make some sense out of what you find on a typical disk.

Another primary function of DOS is to load and run other programs. As it performs that function, DOS is the shell within which another program can be executed. DOS provides the functions and environment required by other software--including operating environments such as Windows 3.x--to run on PC systems in a standard way. Windows 95 finally marries DOS and the Windows environment into a more seamless operating system. You can still drop to a DOS prompt within Windows 95, however the graphical interface is now the operational standard.

The System ROM BIOS

Think of the system ROM BIOS as a form of compatibility glue that sits between the hardware and an operating system. Why is it that the same DOS operating system can run on the original IBM PC and on the latest Pentium systems--two very different hardware platforms? If DOS were written to communicate directly with the hardware on all systems, it would be a very hardware-specific program. Instead, IBM developed a set of standard services and functions that each system should be capable of performing, and coded them as programs in the ROM BIOS. Each system then gets a completely custom ROM BIOS that talks directly to the hardware in the system and knows exactly how to perform each specific function on that hardware only.

This convention enables operating systems to be written to what is essentially a standard interface that can be applied to many different types of hardware. Any applications written to the operating system standard interface can run on that system. Figure 22.1 shows that two very different hardware platforms can each have a custom ROM BIOS that talks directly to the hardware, and still provides a standard interface to an operating system.

The two different hardware platforms described in Figure 22.1 can run not only the exact same version of DOS, but also the same application programs because of the standard interfaces provided by the ROM BIOS and DOS. Keep in mind, however, that the actual ROM BIOS code differs among the specific machines and that it is usually not possible to run a ROM BIOS designed for one system in a different system. ROM BIOS upgrades must come from a source that has an intimate understanding of the specific motherboard on which the chip will be placed, because the ROM must be custom written for that particular hardware.

FIG. 22.1  A representation of the software layers in an IBM-compatible system.

The portion of DOS shown in Figure 22.1 is the system portion, or core, of DOS. This core is physically manifested as the two system files on any bootable DOS disk. These hidden system files are called IO.SYS and MSDOS.SYS in MS-DOS and versions of DOS licensed from Microsoft by original equipment manufacturers (OEMs), or IBMIO.COM and IBMDOS.BOM in IBM's PC-DOS. In Windows 95, the IO.SYS and MSDOS.SYS files still exist, but perform slightly different functions. The IO.SYS file actually contains all of the code previously found in both system files, while MSDOS.SYS is a text file containing configuration settings for the boot process. These two system files are normally the first files listed in the directory on a bootable disk.

Figure 22.1 represents a simplified view of the system; some subtle but important differences exist. Ideally, application programs are insulated from the hardware by the ROM BIOS and by DOS, but in reality many programmers write portions of their programs to talk directly to the hardware, circumventing DOS and the ROM BIOS. A program may therefore work only with specific hardware, even if the proper DOS and ROM BIOS interfaces for the hardware in the machine are present.

Programs designed to communicate directly with the hardware are written that way mainly to increase performance. For example, many programs directly access the video hardware to improve screen update performance. These applications often have install programs that require you to specify exactly what hardware is present in your system so that the program can load the correct hardware-dependent routines into the application.

Additionally, some utility programs absolutely must talk directly to the hardware to perform their function. For example, a low-level format program must talk directly to the hard disk controller hardware to perform the low-level format of the disk. Such programs are very specific to a certain controller or controller type. Another type of system-specific utility, called a memory manager, enables extended memory in a DOS system to function as expanded memory. These drivers work by accessing the system processor directly and using specific features of the chip.

Another way that reality might differ from the simple view is that DOS itself communicates directly with the hardware. The DOS system files can contain low-level drivers designed to supplant and supersede ROM BIOS code in the system. When DOS loads, it determines the system type and ID information from the ROM and loads different routines depending on which version of ROM it finds. For example, there are at least four different hard disk code sections in IBM DOS, but only one is loaded for a specific system.

I have taken a single DOS boot disk with only the system files (plus COMMAND.COM and CHKDSK.COM) on it, and booted the disk on both an XT and an AT system, each one with an identical 640K of memory. After loading DOS, CHKDSK reported different amounts of free memory, which showed that DOS had taken up different amounts of memory in the two systems. This is because of the different code routines loaded, based on the ROM ID information. In essence, DOS, the ROM BIOS, and the hardware are much more closely related than most people realize.

DOS Components

DOS consists of two primary components: the input/output (I/O) system and the shell. The I/O system consists of the underlying programs that reside in memory while the system is running; these programs are loaded first when DOS boots. The I/O system is stored in the IO.SYS and MSDOS.SYS (or IBMIO.COM and IBMDOS.COM) files that are hidden on a bootable DOS disk. No matter what the exact names are, the function of these two files is basically the same for all versions of DOS.

The user interface program, or shell, is stored in the COMMAND.COM file, which also is loaded during a normal DOS boot sequence. The shell is the portion of DOS with which the user communicates with the system, providing the DOS prompt and access to internal commands like COPY and DIR.

The following sections examine the DOS I/O system and shell in more detail to help you properly identify and solve problems that are related to DOS rather than to hardware. Also included is a discussion on how DOS allocates disk file space.

The following sections describe the two files that make up the I/O system: IO.SYS (or IBMBIO.COM) and MSDOS.SYS (or IBMDOS.COM), as well as the DOS command processor (COMMAND.COM).

IO.SYS (or IBMBIO.COM)

IO.SYS is one of the hidden files found on any system (bootable) disk. This file contains the low-level programs that interact directly with devices on the system and the ROM BIOS. During boot-up, the DOS volume boot sector loads the file into low memory and gives it control of the system (see the section "DOS Volume Boot Sectors" later in this chapter). The entire file, except the system initializer portion, remains in memory during normal system operation.

For a disk to be bootable, IO.SYS or its equivalent must be listed as the first file in the directory of the disk and must occupy at least the first cluster on the disk (cluster number 2). The remainder of the file might be placed in clusters anywhere across the rest of the disk. The file normally is marked with hidden, system, and read-only attributes, and placed on a disk by the FORMAT command (with the /S switch) or the SYS command.

MSDOS.SYS (or IBMDOS.COM)

MSDOS.SYS, the core of DOS, contains the DOS disk-handling programs. The routines present in this file make up the DOS disk and device-handling programs. MSDOS.SYS is loaded into low memory at system bootup by the DOS volume boot sector and remains resident in memory during normal system operation.

MSDOS.SYS or its equivalent originally had to be listed as the second entry in the root directory of any bootable disk. This file usually is marked with hidden, system, and read-only attributes, and is normally placed on a disk by the FORMAT /S command or the SYS command. There are no special requirements for the physical positioning of this file on a disk.

The Shell or Command Processor (COMMAND.COM)

The DOS command processor COMMAND.COM is the portion of DOS with which users normally interact. The commands can be categorized by function, but IBM DOS divides them into two types according to how they are made available: resident or transient.

Resident commands are built into COMMAND.COM and are available whenever the DOS prompt is present. They are generally the simpler, frequently used commands such as CLS and DIR. Resident commands execute rapidly because the instructions for them are already loaded into memory. They are memory-resident.

When you look up the definition of a command in the DOS manual, you find an indication of whether the command is resident or transient. You then can determine what is required to execute that command. A simple rule is that, at a DOS prompt, all resident commands are instantly available for execution, with no loading of additional files required. Resident commands are also sometimes termed internal. Commands run from a program on disk are termed external, or transient, and also are often called utilities.

Transient commands are not resident in the computer's memory, and the instructions to execute the command must be located on a disk. Because the instructions are loaded into memory only for execution and then are overwritten in memory after they are used, they are called transient commands. Most DOS commands are transient; otherwise, the memory requirements for DOS would be much larger than they are. Transient commands are used less frequently than resident commands and take longer to execute because they must be found and loaded before they can be run. DOS' transient commands take the form of individual executable files, such as FORMAT.COM and XCOPY.COM, that are located in the DOS home directory (typically C:\DOS).

Most executable files operate like transient DOS commands. The instructions to execute the command must be located on a disk. The instructions are loaded into memory only for execution and are overwritten in memory after the program is no longer being used.

DOS Command File Search Procedure

One of the most commonly seen DOS errors is the Bad command or filename message that appears when you attempt to issue a command that DOS cannot process. This can happen for a number of reasons, and your troubleshooting efforts should begin at the highest level, the software itself, before you begin to suspect that a hardware problem may be at fault.

Whenever you issue a transient command or run a software application's executable file, DOS attempts to find the instructions needed to execute that command by looking in several places, in a specific order. The instructions that represent the command or program are located in files on one or more disk drives. Files that contain execution instructions have an extension of either COM (command files), EXE (executable files), or BAT (batch files). COM and EXE files are machine code programs; BAT files contain ASCII text specifying a series of commands and instructions using the DOS batch facilities. DOS attempts to locate these executable files by searching the current directory and the directories specified in the PATH command.

In other words, if you type several characters, like WIN, at the DOS prompt and press the Enter key, DOS attempts to find and run a program named WIN by performing a two- or three-level search for the program instructions (the file). The first step in looking for command instructions is to see whether the command is a resident in COMMAND.COM and, if so, to run it from the program code already loaded in memory. If the command is not resident, DOS looks in the current directory for a file called WIN with a COM, EXE, and BAT extension (in that order), and loads and executes the first file it finds with the specified name. Therefore, if two files in that directory are called WIN.COM and WIN.BAT, the WIN.COM file will always be executed in response to the WIN command.

If the command is not resident and no file by that name is found in the current directory, DOS looks in each of the directories specified in the DOS PATH environment variable in turn, searching for the file using the same extension order just indicated. Finally, if DOS fails to locate the required instructions, it displays the error message Bad command or filename. As you can see, this error message can be misleading. You may puzzle at the inability of DOS to run a command file that clearly is on the disk, and suspect a hardware problem concerning the disk drive itself, when actually the problem stems from the fact that the command instructions are simply missing from the search areas.

Suppose that, at the DOS prompt, you type the command XYZ and press Enter. This command sends DOS on a search for the XYZ program's instructions. If DOS is successful, the program starts running within seconds. If DOS cannot find the proper instructions, an error message is displayed. Here is what happens:

1. DOS checks internally to see whether it can find the XYZ command as one of the resident commands whose instructions are already loaded. It finds no XYZ command as resident.

2. DOS looks next in the current directory on the current drive for a file named XYZ.COM, then for a file named XYZ.EXE, and finally for a file named XYZ.BAT.

3. DOS looks to see whether the PATH environment variable exists. If not, the search ends here. If so, DOS checks every directory listed in that PATH for the first file that it can find named XYZ.COM, XYZ.EXE, or XYZ.BAT (in that order). Your PATH lists several directories, but DOS does not find an appropriate file in any of them.

4. The search ends, and DOS generates the message Bad command or filename.

For this search-and-load procedure to be successful, you must ensure that the desired program or command file exists in the current directory on the current drive. Or, you must set your DOS PATH to point to the drive and directory in which the program does exist.

A common practice is to place all simple command files or utility programs in one directory and set the PATH to point to that directory. Each of those programs (or commands) is then instantly available simply by typing its name from any DOS prompt, just as though it were resident.

This practice works well only for single-load programs such as commands and other utilities. Major applications often consist of many individual files and might have problems if they are called up from a remote directory or drive using the DOS PATH. This is because the PATH variable has no effect when the application looks for its overlay and accessory files.

On a hard disk system, users typically install all transient commands and utilities in subdirectories and ensure that the PATH points to those directories. The path literally is a list of directories and subdirectories specified in the AUTOEXEC.BAT file that tells DOS where to search for files when the command cannot be found in the current directory. A path on such a hard drive may look like this:

PATH=C:\DOS;C:\BAT;C:\UTILS;

In the previous example, all of the ancillary programs included with the DOS operating system will be immediately locatable because of the inclusion of C:\DOS in the PATH command.

The PATH normally cannot exceed 128 characters in length (including colons, semicolons, and backslashes). As a result of that limitation, you cannot have a PATH that contains all your directories if the directory names exceed 128 characters.

You can also completely short circuit the DOS command search procedure simply by entering the complete path to the file at the command prompt. For example, rather than include C:\DOS in the PATH and enter this command:

C:\>CHKDSK

You can enter the full name of the program:

C:\>C:\DOS\CHKDSK.COM

The latter command immediately locates and loads the CHKDSK program with no search through the current directory or PATH setting. This method of calling up a program speeds the location and execution of the program and works especially well to increase the speed of DOS batch file execution. It also allows you to immediately eliminate path problems as the source of the Bad command message.

DOS Versions

In more than a decade and a half of development, a great many DOS versions have been released. IBM released version 1.0 of the operating system in 1981, but by version 3.x Microsoft too began releasing its own DOS, using the same version numbers as IBM in most cases. Early versions of DOS were frequently designed for the hardware configurations of specific machines. At one time, IBM, Compaq, and other original equipment manufacturers would have their own versions of DOS (created by IBM or Microsoft), designed to support only their hardware. You could not, in many cases, boot an IBM DOS computer using a Compaq DOS boot disk, and gain full functionality.

DOS 5.x

By the time that DOS 5.0 was released by Microsoft, however, this situation was all but eliminated. DOS 5 was the first version of the operating system to be marketed on a retail level, and users turned out in droves to upgrade their systems. Both the IBM and Microsoft versions of DOS 5.0 and later can be used on almost any system.

DOS 5 offered vastly improved memory management, and incorporated many of the features that users had come to rely on third-party utilities for. At this time, there are some people who still swear by DOS 5, and resist upgrading to version 6 which, truth to tell, is more of an enhancement than a major overhaul. However, there is no reason why any DOS version below 5.0 should still be in use on any computer (except for museum pieces that can handle nothing but their native versions).

IBM and MS DOS 6.xx

After DOS 5.0, there were several different versions of DOS 6.xx from both Microsoft and IBM. The original release of MS DOS 6.0 came from Microsoft. One of the features included in 6.0 was the new DoubleSpace disk compression. Unfortunately, DoubleSpace had some problems with certain system configurations and hardware types. In the meantime, IBM took DOS 6.0 from Microsoft, updated it to fix several small problems, removed the disk compression, and sold it as IBM DOS 6.1. Microsoft had many problems with the DoubleSpace disk compression used in 6.0 and released 6.2 as a free bug fix upgrade.

Microsoft then ran into legal problems in a lawsuit brought by Stacker Corporation that accused Microsoft of having infringed on its rights to the compression algorithm used by its Stacker software product. Microsoft was ultimately vindicated of any wrongdoing, but not before it had removed the DoubleSpace compression feature from DOS 6.2, which was released as 6.21. Microsoft then quickly developed a non-infringing disk compression utility called DriveSpace, which was released in version 6.22, along with several minor bug fixes. IBM skipped over the 6.2 version number and released DOS 6.3 (now called PC DOS), which also included a different type of compression program than that used by Microsoft. By avoiding the DoubleSpace software, IBM also avoided the bugs and legal problems that Microsoft had encountered. Also included in the updated IBM releases were enhanced PCMCIA and power management commands.

The Boot Process

The term boot comes from the term bootstrap and describes the method by which the PC becomes operational. Just as you pull on a large boot by the small strap attached to the back, a PC can load a large operating system program by first loading a small program that then can pull in the operating system. A chain of events begins with the application of power and finally results in an operating computer system with software loaded and running. Each event is called by the event before it and initiates the event after it.

Tracing the system boot process might help you find the location of a problem if you examine the error messages that the system displays when the problem occurs. If you can see an error message displayed only by a particular program, you can be sure that the program in question was at least loaded and partially running. Combine this information with the knowledge of the boot sequence, and you can at least tell how far along the system's startup procedure has progressed before the problem occurred. You usually want to look at whatever files or disk areas were being accessed during the failure in the boot process. Error messages displayed during the boot process as well as those displayed during normal system operation can be hard to decipher, but the first step in decoding an error message is to know where the message came from--what program actually sent or displayed the message. The following programs are capable of displaying error messages during the boot process:

This section examines the system startup sequence and provides a detailed account of many of the error messages that might occur during this process.

How DOS Loads and Starts

If you have a problem with your system during startup and you can determine where in this sequence of events your system has stalled, you know what events have occurred and you probably can eliminate each of them as a cause of the problem. The following steps occur in a typical system startup:

1. You switch on electrical power to the system.

2. The power supply performs a self-test. When all voltages and current levels are acceptable, the supply indicates that the power is stable and sends the Power Good signal to the motherboard. The time from switch-on to Power Good is normally between .1 and .5 seconds.

3. The microprocessor timer chip receives the Power Good signal, which causes it to stop generating a reset signal to the microprocessor.

4. The microprocessor begins executing the ROM BIOS code, starting at memory address FFFF:0000. Because this location is only 16 bytes from the very end of the available ROM space, it contains a JMP (jump) instruction to the actual ROM BIOS starting address.

5. The ROM BIOS performs a test of the central hardware to verify basic system functionality. Any errors that occur are indicated by audio codes because the video system has not yet been initialized.

6. The BIOS performs a video ROM scan of memory locations C000:0000 through C780:0000, looking for video adapter ROM BIOS programs contained on a video adapter card plugged into a slot. If a video ROM BIOS is found, it is tested by a checksum procedure. If it passes the checksum test, the ROM is executed; the video ROM code initializes the video adapter; and a cursor appears on-screen. If the checksum test fails, the following message appears: 

C000 ROM Error
7. If the BIOS finds no video adapter ROM, it uses the motherboard ROM video drivers to initialize the video display hardware, and a cursor appears on-screen.

8. The motherboard ROM BIOS scans memory locations C800:0000 through DF80:0000 in 2K increments for any other ROMs located on any other adapter cards. If any ROMs are found, they are checksum-tested and executed. These adapter ROMs can alter existing BIOS routines as well as establish new ones.

9. Failure of a checksum test for any of these ROM modules causes this message to appear: 

XXXX ROM Error
10. The address XXXX indicates the segment address of the failed ROM module.

11. The ROM BIOS checks the word value at memory location 0000:0472 to see whether this start is a cold start or a warm start. A word value of 1234h in this location is a flag that indicates a warm start, which causes the memory test portion of the POST (Power-On Self Test) to be skipped. Any other word value in this location indicates a cold start and full POST.

12. If this is a cold start, the POST executes. Any errors found during the POST are reported by a combination of audio and displayed error messages. Successful completion of the POST is indicated by a single beep.

13. The ROM BIOS searches for a DOS volume boot sector at cylinder 0, head 0, sector 1 (the very first sector) on the A: drive. This sector is loaded into memory at 0000:7C00 and tested. If a disk is in the drive but the sector cannot be read, or if no disk is present, the BIOS continues with the next step.

14. If the first byte of the DOS volume boot sector loaded from the floppy disk in A: is less than 06h, or if the first byte is greater than or equal to 06h, and the first nine words contain the same data pattern, this error message appears and the system stops: 

602-Diskette Boot Record Error
15. If the disk was prepared with FORMAT or SYS using DOS 3.3 or an earlier version and the specified system files are not the first two files in the directory, or if a problem was encountered loading them, the following message appears: 
Non-System disk or disk error
Replace and strike any key when ready
16. If the disk was prepared with FORMAT or SYS using DOS 3.3 or an earlier version and the boot sector is corrupt, you might see this message: 
Disk Boot failure
17. If the disk was prepared with FORMAT or SYS using DOS 4.0 and later versions, and the specified system files are not the first two files in the directory, or if a problem was encountered loading them, or the boot sector is corrupt, this message appears: 
Non-System disk or disk error
Replace and press any key when ready
18. If no DOS volume boot sector can be read from drive A:, the BIOS looks for a master partition boot sector at cylinder 0, head 0, sector 1 (the very first sector) of the first fixed disk. If this sector is found, it is loaded into memory address 0000:7C00 and tested for a signature.

19. If the last two (signature) bytes of the master partition boot sector are not equal to 55AAh, software interrupt 18h (Int 18h) is invoked on most systems. On an IBM PS/2 system, a special character graphics message is displayed that depicts inserting a floppy disk in drive A: and pressing the F1 key. For non-PS/2 systems made by IBM, an Int 18h executes the ROM BIOS-based Cassette BASIC Interpreter. When this occurs, the message looks like this: 
The IBM Personal Computer Basic
Version C1.10 Copyright IBM Corp 1981
62940 Bytes free
Ok
Because no BIOS versions other than IBM's systems ever had the Cassette BASIC interpreter in ROM, other BIOS manufacturers had to come up with different messages to display for the same situations in which an IBM system would invoke this BASIC. PCs that have an AMI BIOS in fact display a confusing message as follows: 
NO ROM BASIC - SYSTEM HALTED
This message is a BIOS error message that is displayed by the AMI BIOS when the same situations occur that would cause an IBM system to dump into Cassette BASIC, which of course is not present in an AMI BIOS (or any other compatible BIOS for that matter). Other BIOS versions display different messages. For example, under the same circumstances, a Compaq BIOS displays the following: 
Non-System disk or disk error
replace and strike any key when ready
This is somewhat confusing on Compaq's part because this very same (or similar) error message is contained in the DOS Boot Sector, and would normally be displayed if the DOS system files were missing or corrupted.

In the same situations that you would see Cassette BASIC on an IBM system, a system with an Award BIOS would display the following: 

DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER
Phoenix BIOS systems will display either: 
No boot device available -
strike F1 to retry boot, F2 for setup utility
or 
No boot sector on fixed disk -
strike F1 to retry boot, F2 for setup utility
The first or second Phoenix message displays depending on exactly which error actually occurred.

Although the message displayed varies from BIOS to BIOS, the cause for all of them relates to specific bytes in the Master Boot Record, which is the first sector of a hard disk at the physical location Cylinder 0, Head 0, Sector 1.

The problem involves a disk that has either never been partitioned or has had the Master Boot Sector corrupted. During the boot process, the BIOS checks the last two bytes in the Master Boot Record (first sector of the drive) for a "signature" value of 55AAh. If the last two bytes are not 55AAh, an Interrupt 18h is invoked, which calls the subroutine that displays the message you received as well as the others indicated, or on an IBM system invokes Cassette (ROM) BASIC itself.

The Master Boot Sector (including the signature bytes) is written to the hard disk by the DOS FDISK program. Immediately after you low-level format a hard disk, all the sectors are initialized with a pattern of bytes, and the first sector does not contain the 55AAh signature. In other words, these ROM error messages are exactly what you see if you attempt to boot from a hard disk that has been low-level formatted, but has not yet been partitioned.

20. The master partition boot sector program searches its partition table for an entry with a system indicator byte indicating an extended partition. If the program finds such an entry, it loads the extended partition boot sector at the location indicated. The extended partition boot sector also has a table that is searched for another extended partition. If another extended partition entry is found, that extended partition boot sector is loaded from the location indicated. The search continues until either no more extended partitions are indicated, or the maximum number of 24 total partitions has been reached.

21. The master partition boot sector searches its partition table for a boot indicator byte marking an active partition.

22. On an IBM system, if none of the partitions are marked active (bootable), ROM BIOS-based Cassette BASIC is invoked. On most IBM-compatible systems, some type of disk error message is displayed.

23. If any boot indicator in the master partition boot record table is invalid, or if more than one indicates an active partition, the following message is displayed, and the system stops: 

Invalid partition table
24. If an active partition is found in the master partition boot sector, the volume boot sector from the active partition is loaded and tested.

25. If the DOS volume boot sector cannot be read successfully from the active partition within five retries because of read errors, this message appears and the system stops: 

Error loading operating system
26. The hard disk DOS volume boot sector is tested for a signature. If the DOS volume boot sector does not contain a valid signature of 55AAh as the last two bytes in the sector, this message appears and the system stops: 
Missing operating system
27. The volume boot sector is executed as a program. This program checks the root directory to ensure that the first two files are IO.SYS (or IBMBIO.COM) and MSDOS.SYS (or IBMDOS.COM). If these files are present, they are loaded.

28. If the disk was prepared with FORMAT or SYS using DOS 3.3 or an earlier version and the specified system files are not the first two files in the directory, or if a problem is encountered loading them, the following message appears: 

Non-System disk or disk error
Replace and strike any key when ready
29. If the disk was prepared with FORMAT or SYS using DOS 3.3 or an earlier version and the boot sector is corrupt, you might see this message: 
Disk Boot failure
30. If the disk was prepared with FORMAT or SYS using DOS 4.0 or a later version and the specified system files are not the first two files in the directory, or if a problem is encountered loading them, or the boot sector is corrupt, the following message appears: 
Non-System disk or disk error
Replace and press any key when ready
31. If no problems occur, the DOS volume boot sector executes IO.SYS/IBMBIO.COM.

32. The initialization code in IO.SYS/IBMBIO.COM copies itself into the highest region of contiguous DOS memory and transfers control to the copy. The initialization code copy then relocates MSDOS.SYS over the portion of IO.SYS in low memory that contains the initialization code, because the initialization code no longer needs to be in that location. Windows 95's IO.SYS combines the functions of DOS' IO.SYS and MSDOS.SYS.

33. The initialization code executes MSDOS.SYS (or IBMDOS.COM), which initializes the base device drivers, determines equipment status, resets the disk system, resets and initializes attached devices, and sets the system default parameters.

34. The full DOS filing system is active, and control is returned to the IO.SYS initialization code.

35. The IO.SYS initialization code reads the CONFIG.SYS file multiple times. In Windows 95, IO.SYS also looks for the SYSTEM.DAT Registry file.

36. When loading CONFIG.SYS, DEVICE statements are first processed in the order in which they appear, and any device driver files named are loaded and executed. Then any INSTALL statements are processed in the order in which they appear, and the programs named are loaded and executed. The SHELL statement is processed and loads the specified command processor with the specified parameters. If the CONFIG.SYS file contains no SHELL statement, the default \COMMAND.COM processor is loaded with default parameters. Loading the command processor overwrites the initialization code in memory (because the job of the initialization code is finished).

In Windows 95, the COMMAND.COM program is loaded only if an AUTOEXEC.BAT exists, so it can process the commands contained within.

During the final reads of CONFIG.SYS, all of the remaining statements are read and processed in a predetermined order. Thus, the order of appearance for statements other than DEVICE, INSTALL, and SHELL in CONFIG.SYS is of no significance.

37. If AUTOEXEC.BAT is present, COMMAND.COM loads and runs AUTOEXEC.BAT. After the commands in AUTOEXEC.BAT have been executed, the DOS prompt appears (unless the AUTOEXEC.BAT calls an application program or shell of some kind, in which case the user might operate the system without ever seeing a DOS prompt).

38. If no AUTOEXEC.BAT is present, COMMAND.COM executes the internal DATE and TIME commands, displays a copyright message, and displays the DOS prompt.

In Windows 95, IO.SYS automatically loads HIMEM.SYS, IFSHLP.SYS, and SETVER.EXE. Finally, it loads WIN.COM and Windows 95 is officially started.

Some minor variations from this scenario are possible, such as those introduced by other ROM programs in the various adapters that might be plugged into a slot. Also, depending on the exact ROM BIOS programs involved, some of the error messages and sequences might vary. Generally, however, a computer follows this chain of events in "coming to life."

You can modify the system startup procedures by altering the CONFIG.SYS and AUTOEXEC.BAT files, or the Windows 95 Registry. These files control the configuration of DOS or Windows 95 and allow special startup programs to be executed every time the system starts.

File Management

DOS uses several elements and structures to store and retrieve information on a disk. These elements and structures enable DOS to communicate properly with the ROM BIOS as well as application programs to process file storage and retrieval requests. Understanding these structures and how they interact help you to troubleshoot and even repair these structures.

DOS File Space Allocation

DOS allocates disk space for a file on demand (space is not preallocated). The space is allocated one cluster (or allocation unit) at a time. A cluster is always one or more sectors. (For more information about sectors, refer to Chapter 14, "Hard Disk Drives.")

The clusters are arranged on a disk to minimize head movement for multisided media. DOS allocates all the space on a disk cylinder before moving to the next cylinder. It does this by using the sectors under the first head, and then all the sectors under the next head, and so on until all sectors of all heads of the cylinder are used. The next sector used is sector 1 of head 0 on the next cylinder. (You find more information on floppy disks and drives in Chapter 13, "Floppy Disk Drives" and on hard disks in Chapter 14, "Hard Disk Drives.")

The algorithm used for file allocation in DOS 3.0 and later versions is called the Next Available Cluster algorithm. In this algorithm, the search for available clusters in which to write a file starts not at the beginning of the disk, as in previous DOS versions, but rather from where the last write occurred. Therefore, the disk space freed by erasing a file is not necessarily reused immediately. Rather, DOS maintains a Last Written Cluster pointer indicating the last written cluster and begins its search from that point. This pointer is maintained in system RAM and is lost when the system is reset or rebooted, or when a disk is changed in a floppy drive.

The Next Available Cluster algorithm in DOS 3.0 and later versions is faster than the First Available Cluster algorithm of earlier versions and helps to minimize fragmentation. Sometimes this type of algorithm is called elevator seeking because write operations occur at higher and higher clusters until the end of the disk area is reached. At that time, the pointer is reset, and writes work their way from the beginning of the disk again.

Files still end up becoming fragmented using the new algorithm, because the pointer is reset after a reboot, a disk change operation, or when the end of the disk is reached. Nevertheless, a great benefit of the newer method is that it makes unerasing files more likely to succeed even if the disk has been written to since the erasure, because the file just erased is not likely to be the target of the next write operation. In fact, it might be some time before the clusters occupied by the erased file are reused.