#
Upgrading & Repairing PCs Eighth Edition

#

# - 22 -

# Operating Systems Software and Troubleshooting

- Disk Operating System (DOS)
  - Operating System Basics
  - The System ROM BIOS
  - DOS Components
  - IO.SYS (or IBMBIO.COM)
  - MSDOS.SYS (or IBMDOS.COM)
  - The Shell or Command Processor (COMMAND.COM)
  - DOS Command File Search Procedure
  - DOS Versions
  - The Boot Process
  - How DOS Loads and Starts
  - File Management
  - DOS File Space Allocation
  - Interfacing to Disk Drives
  - DOS Structures
  - Potential DOS Upgrade Problems
  - Known Bugs in DOS
  - DOS Disk and Data Recovery
  - The RECOVER Command
  - ScanDisk
  - Third-Party Programs
  - Memory-Resident Software Conflicts
  - Hardware Problems versus Software Problems
- Windows 95
  - Windows 95 and DOS Compared
  - FAT32
- Windows NT

#

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:

- FAT file structure
- FAT disk organization
- Programs for data and disk recovery (their capabilities and dangers)

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:

- Motherboard ROM BIOS
- Adapter card ROM BIOS extensions
- Master partition boot sector
- DOS volume boot sector
- System files (IO.SYS/IBMBIO.COM, and MSDOS.SYS/IBMDOS.COM)
- Device drivers (loaded through CONFIG.SYS or the Windows 95 Registry SYSTEM.DAT)
- Shell program (COMMAND.COM in DOS)
- Programs run by AUTOEXEC.BAT
- Windows (WIN.COM)

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.

Even when a file is overwritten under DOS 3.0 and later versions, the clusters occupied by the file are not actually reused in the overwrite. For example, if you accidentally save on a disk a file using the same name as an important file that already exists, the existing file clusters are marked as available, and the new file (with the same name) is written to the disk in other clusters. It is possible, therefore, that the original copy of the file can still be retrieved. You can continue this procedure by saving another copy of the file with the same name, and each file copy is saved to higher-numbered clusters. Then, each earlier version overwritten might still be recoverable on the disk. This process can continue until the system is rebooted or reset, or until the end of the available space is reached. Then the pointer is set to the first cluster, and the previous file data is overwritten.

Because DOS always uses the first available directory entry when it saves or creates a file, the overwritten or deleted files whose data is still recoverable on the disk no longer appear in a directory listing. No commercial quick unerase or other unerase utilities, therefore, can find any record of the erased or overwritten file on the disk--true, of course, because these programs look only in the directory for a record of an erased file. Some undelete programs have a memory-resident delete tracking function that, in essence, maintains a separate directory listing from DOS. Unless an unerase program has such a function, and that function has been activated before the deletion, no program can recall the files overwritten in the directory entry.

Because unerase programs do not look at the FAT, or at the data clusters themselves (unless they use delete tracking), they see no record of the files' existence. By scanning the free clusters on the disk one by one using a disk editor tool, you can locate the data from the overwritten or erased file and manually rebuild the FAT and directory entries. This procedure enables you to recover erased files even though files have been written to the disk since the erasure took place.

### Interfacing to Disk Drives

DOS uses a combination of disk management components to make files accessible. These components differ slightly between floppies and hard disks and between disks of different sizes. They determine how a disk appears to DOS and to applications software. Each component used to describe the disk system fits as a layer into the complete system. Each layer communicates with the layer above and below it. When all the components work together, an application can access the disk to find and store data. Table 22.1 lists the DOS format specifications for floppy disks.

#### Table 22.1 Floppy Disk Format Specifications

| Current Formats
Disk Size (in.) Disk Capacity (K) | 3 1/2" 2,880 | 3 1/2" 1,440
Media Descriptor Byte | F0h | F0h
Sides (Heads) | 2 | 2
Tracks per side | 80 | 80
Sectors per track | 36 | 18
Bytes per sector | 512 | 512
Sectors per cluster | 2 | 1
FAT length (Sectors) | 9 | 9
Number of FATs | 2 | 2
Root Dir. Length (Sectors) | 15 | 14
Maximum Root Entries | 240 | 224
Total sectors per disk | 5,760 | 2,880
Total available sectors | 5,726 | 2,847
Total available clusters | 2,863 | 2,847

The four primary layers of interface between an application program running on a system and any disks attached to the system consist of software routines that can perform various functions, usually to communicate with the adjacent layers. These layers are shown in the following list:

- DOS Interrupt 21h (Int 21h) routines
- DOS Interrupt 25/26h (Int 25/26h) routines
- ROM BIOS disk Interrupt 13h (Int 13h) routines
- Disk controller I/O port commands

Each layer accepts various commands, performs different functions, and generates results. These interfaces are available for both floppy disk drives and hard disks, although the floppy disk and hard disk Int 13h routines differ widely. The floppy disk controllers and hard disk controllers are very different as well, but all the layers perform the same functions for both floppy disks and hard disks.

Interrupt 21h

The DOS Int 21h routines exist at the highest level and provide the most functionality with the least amount of work. For example, if an application program needs to create a subdirectory on a disk, it can call Int 21h, Function 39h. This function performs all operations necessary to create the subdirectory, including updating the appropriate directory and FAT sectors. The only information this function needs is the name of the subdirectory to create. DOS Int 21h would do much more work by using one of the lower-level access methods to create a subdirectory. Most applications access the disk through this level of interface.

Interrupt 25h and 26h

The DOS Int 25h and Int 26h routines provide much lower-level access to the disk than the Int 21h routines. Int 25h reads only specified sectors from a disk, and Int 26h only writes specified sectors to a disk. If you were to write a program that used these functions to create a subdirectory on a disk, the amount of work would be much greater than that required by the Int 21h method. For example, your program would have to perform all of these tasks:

- Calculate exactly which directory and FAT sectors need to be updated.
- Use Int 25h to read these sectors.
- Modify the sectors appropriately to contain the new subdirectory information.
- Use Int 26h to write the sectors back out.

The number of steps would be even greater considering the difficulty in determining exactly what sectors have to be modified. According to Int 25/26h, the entire DOS- addressable area of the disk consists of sectors numbered sequentially from 0. A program designed to access the disk using Int 25h and Int 26h must know the location of everything by this sector number. A program designed this way might have to be modified to handle disks with different numbers of sectors or different directory and FAT sizes and locations. Because of all the overhead required to get the job done, most programmers would not choose to access the disk in this manner, and instead would use the higher-level Int 21h--which does all the work automatically.

Only disk- and sector-editing programs typically access a disk drive at the Int 25h and Int 26h level. Programs that work at this level of access can edit only areas of a disk that have been defined to DOS as a logical volume (drive letter). For example, DEBUG can read sectors from and write sectors to disks with this level of access.

Interrupt 13h

The next lower level of communications with drives, the ROM BIOS Int 13h routines, usually are found in ROM chips on the motherboard or on an adapter card in a slot. However, an Int 13h handler also can be implemented by using a device driver loaded at boot time. Because DOS requires Int 13h access to boot from a drive (and a device driver cannot be loaded until after boot-up), only drives with ROM BIOS-based Int 13h support can become bootable. Int 13h routines need to talk directly to the controller using the I/O ports on the controller. Therefore, the Int 13h code is very controller-specific. Table 22.2 lists the different functions available at the Interrupt 13h BIOS interface. Some functions are available to floppy drives or hard drives only, whereas others are available to both types of drives.

Table 22.3 shows the error codes that may be returned by the BIOS INT 13h routines. In some cases, you may see these codes referred to when running a low-level format program, disk editor, or other program that can directly access a disk drive through the BIOS.

#### Table 22.2 Int 13h BIOS Disk Functions

Function | Floppy Disk | Hard Disk | Description
00h | X | X | Reset disk system
01h | X | X | Get status of last operation
02h | X | X | Read sectors
03h | X | X | Write sectors
04h | X | X | Verify sectors
05h | X | X | Format track
06h |  | X | Format bad track
07h |  | X | Format drive
08h | X | X | Read drive parameters
09h |  | X | Initialize drive characteristics
0Ah |  | X | Read long
0Bh |  | X | Write long
0Ch |  | X | Seek
0Dh |  | X | Alternate hard disk reset
0Eh |  | X | Read sector buffer
0Fh |  | X | Write sector buffer
10h |  | X | Test for drive ready
11h |  | X | Recalibrate drive
12h |  | X | Controller RAM diagnostic
13h |  | X | Controller drive diagnostic
14h |  | X | Controller internal diagnostic
15h | X | X | Get disk type
16h | X |  | Get floppy disk change status
17h | X |  | Set floppy disk type for format
18h | X |  | Set media type for format
19h |  | X | Park hard disk heads
1Ah |  | X | ESDI--Low-level format
1Bh |  | X | ESDI--Get manufacturing header
1Ch |  | X | ESDI--Get configuration

#### Table 22.3 BIOS INT 13h Error Codes

Code | Description | Code | Description
00h | No error | 06h | Media change error
01h | Bad command | 07h | Initialization failed
02h | Address mark not found | 09h | Cross 64K DMA boundary
03h | Write protect | 0Ah | Bad sector flag detected
04h | Request sector not found | 0Bh | Bad track flag detected
05h | Reset failed | 10h | Bad ECC on disk read
11h | ECC corrected data error | BBh | Undefined error
20h | Controller has failed | CCh | Write fault
40h | Seek operation failed | 0Eh | Register error
80h | Drive failed to respond | FFh | Sense operation failed
AAh | Drive not ready |  |

If you design your own custom disk controller device, you need to write an IBM- compatible Int 13h handler package and install it on the card using a ROM BIOS that will be linked into the system at boot time. To use Int 13h routines, a program must use exact cylinder, head, and sector coordinates to specify sectors to read and write. Accordingly, any program designed to work at this level must be intimately familiar with the parameters of the specific disk on the system on which it is designed to run. Int 13h functions exist to read the disk parameters, format tracks, read and write sectors, park heads, and reset the drive.

A low-level format program for ST-506/412 drives needs to work with disks at the Int 13h level or lower. Most ST-506/412 controller format programs work with access at the Int 13h level because virtually any operation a format program needs is available through the Int 13h interface. This is not true, however, for other types of controllers (such as IDE, SCSI, or ESDI), for which defect mapping and other operations differ considerably from the ST-506/412 types. Controllers that must perform special operations during a low-level format, such as defining disk parameters to override the motherboard ROM BIOS drive tables, would not work with any formatter that used only the standard Int 13h interface.

For these reasons, most controllers require a custom formatter designed to bypass the Int 13h interface. Most general-purpose, low-level reformat programs that perform a non-destructive format access the controller through the Int 13h interface (rather than going direct) and therefore cannot be used for an initial low-level format; the initial low-level format must be done by a controller-specific utility.

Few high-powered disk utility programs, other than some basic formatting software, can talk to the disk at the Int 13h level. The DOS FDISK program communicates at the Int 13h level. The Norton DISKEDIT and older NU programs can communicate with a disk at the Int 13h level when these programs are in their absolute sector mode; they are some of the few disk-repair utilities that can do so. These programs are important because they can be used for the worst data recovery situations, in which the partition tables have been corrupted. Because the partition tables, as well as any non-DOS partitions, exist outside the area of a disk that is defined by DOS, only programs that work at the Int 13h level can access them. Most utility programs for data recovery work only at the DOS Int 25/26h level, which makes them useless for accessing areas of a disk outside of DOS' domain.

Disk Controller I/O Port Commands

In the lowest level of interface, programs talk directly to the disk controller in the controller's own specific native language. To do this, a program must send controller commands through the I/O ports to which the controller responds. These commands are specific to the particular controller and sometimes differ even among controllers of the same type, such as different ESDI controllers. The ROM BIOS in the system must be designed specifically for the controller because the ROM BIOS talks to the controller at this I/O port level. Most low-level format programs also need to talk to the controller directly because the higher-level Int 13h interface does not provide enough specific features for many of the custom ST-506/412 or ESDI and SCSI controllers on the market.

Figure 22.2 shows that most application programs work through the Int 21h interface, which passes commands to the ROM BIOS as Int 13h commands; these commands then are converted into direct controller commands by the ROM BIOS. The controller executes the commands and returns the results through the layers until the desired information reaches the application. This process enables developers to write applications without worrying about such low-level system details, instead leaving them up to DOS and the ROM BIOS. This also enables applications to run on widely different types of hardware, as long as the correct ROM BIOS and DOS support is in place.

FIG. 22.2 Relationships between various interface levels.

Any software can bypass any level of interface and communicate with the level below it, but doing so requires much more work. The lowest level of interface available is direct communication with the controller using I/O port commands. As Figure 22.2 shows, each different type of controller has different I/O port locations as well as differences among the commands presented at the various ports, and only the controller can talk directly to the disk drive.

If not for the ROM BIOS Int 13h interface, a unique DOS would have to be written for each available type of hard and floppy disk drive. Instead, DOS communicates with the ROM BIOS using standard Int 13h function calls translated by the Int 13h interface into commands for the specific hardware. Because of the standard ROM BIOS interface, DOS can be written relatively independently of specific disk hardware and can support many different types of drives and controllers.

### DOS Structures

To manage files on a disk and enable all application programs to see a consistent disk interface no matter what type of disk is used, DOS uses several structures. The following list shows all the structures and areas that DOS defines and uses to manage a disk, in roughly the same order that they appear:

- Master and extended partition boot sectors
- DOS volume boot sector
- Root directory
- File allocation tables (FAT)
- Clusters (allocation units)
- Data area
- Diagnostic read-and-write cylinder

A hard disk has all of these DOS disk-management structures allocated, and a floppy disk has all but the master and extended partition boot sectors and the diagnostic cylinder. These structures are created by the DOS FDISK program, which cannot be used on a floppy disk because they cannot be partitioned. Figure 22.3 is a simple diagram showing the relative locations of these DOS disk-management structures on the 32M hard disk in an IBM AT Model 339.

Each disk area has a purpose and function. If one of these special areas is damaged, serious consequences can result. Damage to one of these sensitive structures usually causes a domino effect, limiting access to other areas of the disk or causing further problems in using the disk. For example, DOS cannot read and write files if the FAT is damaged or corrupted. Therefore, you should understand these data structures well enough to be able to repair them when necessary. Rebuilding these special tables and areas of the disk is essential to the art of data recovery.

FIG. 22.3 DOS disk management structures on an IBM AT Model 339 32M hard disk.

Master Partition Boot Sectors

To share a hard disk among different operating systems, the disk might be logically divided into one to four master partitions. Each operating system, including DOS (through versions 3.2), might own only one partition. DOS 3.3 and later versions introduced the extended DOS partition, which allows multiple DOS partitions on the same hard disk. With the DOS FDISK program, you can select the size of each partition. The partition information is stored in several partition boot sectors on the disk, with the main table embedded in the master partition boot sector. The master partition boot sector is always located in the first sector of the entire disk (cylinder 0, head 0, sector 1). The extended partition boot sectors are located at the beginning of each extended partition volume.

Each DOS partition contains a DOS volume boot sector as its first sector. With the DOS FDISK utility, you might designate a single partition as active (or bootable). The master partition boot sector causes the active partition's volume boot sector to receive control when the system is started or reset. Additional master disk partitions can be set up for Novell NetWare, and for OS/2's HPFS, NTFS, AIX (UNIX), XENIX, or other operating systems. These foreign operating system partitions cannot be accessed under DOS, nor are DOS partitions normally accessible using other operating systems. (OS/2 and Windows NT can access FAT partitions, the high-performance file system (HPFS) is exclusive to OS/2, and the NTFS is exclusive to Windows NT.)

A hard disk must be partitioned in order to be accessible by an operating system. You must partition a disk even if you want to create only a single partition. Table 22.4 shows the format of the Master Boot Record (MBR) with partition tables.

Table 22.5 shows the standard values and meanings of the System Indicator Byte.

#### Table 22.4 Master Boot Record (Partition Table)

Partition Table Entry #1

Offset | Length | Description
1BEh 446 | 1 byte | Boot Indicator Byte (80h = Active, else 00h)
1BFh 447 | 1 byte | Starting Head (or Side) of Partition
1C0h 448 | 16 bits | Starting Cylinder (10 bits) and Sector (6 bits)
1C2h 450 | 1 byte | System Indicator Byte (see Table 22.5)
1C3h 451 | 1 byte | Ending Head (or Side) of Partition
1C4h 452 | 16 bits | Ending Cylinder (10 bits) and Sector (6 bits)
1C6h 454 | 1 dword | Relative Sector Offset of Partition
1CAh 458 | 1 dword | Total Number of Sectors in Partition

Partition Table Entry #2

Offset | Length | Description
1CEh 462 | 1 byte | Boot Indicator Byte (80h = Active, else 00h)
1CFh 463 | 1 byte | Starting Head (or Side) of Partition
1D0h 464 | 16 bits | Starting Cylinder (10 bits) and Sector (6 bits)
1D2h 466 | 1 byte | System Indicator Byte (see Table 22.5)
1D3h 467 | 1 byte | Ending Head (or Side) of Partition
1D4h 468 | 16 bits | Ending Cylinder (10 bits) and Sector (6 bits)
1D6h 470 | 1 dword | Relative Sector Offset of Partition
1DAh 474 | 1 dword | Total Number of Sectors in Partition

Partition Table Entry #3

Offset | Length | Description
1DEh 478 | 1 byte | Boot Indicator Byte (80h = Active, else 00h)
1DFh 479 | 1 byte | Starting Head (or Side) of Partition
1E0h 480 | 16 bits | Starting Cylinder (10 bits) and Sector (6 bits)
1E2h 482 | 1 byte | System Indicator Byte (see Table 22.5)
1E3h 483 | 1 byte | Ending Head (or Side) of Partition
1E4h 484 | 16 bits | Ending Cylinder (10 bits) and Sector (6 bits)
1E6h 486 | 1 dword | Relative Sector Offset of Partition
1EAh 490 | 1 dword | Total Number of Sectors in Partition

Partition Table Entry #4

Offset | Length | Description
1EEh 494 | 1 byte | Boot Indicator Byte (80h = Active, else 00h)
1EFh 495 | 1 byte | Starting Head (or Side) of Partition
1F0h 496 | 16 bits | Starting Cylinder (10 bits) and Sector (6 bits)
1F2h 498 | 1 byte | System Indicator Byte (see Table 22.5)
1F3h 499 | 1 byte | Ending Head (or Side) of Partition
1F4h 500 | 16 bits | Ending Cylinder (10 bits) and Sector (6 bits)
1F6h 502 | 1 dword | Relative Sector Offset of Partition
1FAh 506 | 1 dword | Total Number of Sectors in Partition

Signature Bytes

Offset | Length | Description
1FEh 510 | 2 bytes | Boot Sector Signature (55AAh)

A WORD equals 2 bytes read in reverse order, and a DWORD equals two WORDs read in reverse order.

#### Table 22.5 Partition Table System Indicator Byte Values

Value | Description
00h | No allocated partition in this entry
01h | Primary DOS, 12-bit FAT (Partition < 16M)
04h | Primary DOS, 16-bit FAT (16M <= Partition <= 32M)
05h | Extended DOS (Points to next Primary Partition)
06h | Primary DOS, 16-bit FAT (Partition > 32M)
07h | OS/2 HPFS Partition
02h | MS-XENIX Root Partition
03h | MS-XENIX usr Partition
08h | AIX File System Partition
09h | AIX boot Partition
50h | Ontrack Disk Manager READ-ONLY Partition
51h | Ontrack Disk Manager READ/WRITE Partition
56h | Golden Bow Vfeature Partition
61h | Storage Dimensions Speedstor Partition
63h | IBM 386/ix or UNIX System V/386 Partition
64h | Novell NetWare Partition
75h | IBM PCIX Partition
DBh | Digital Research Concurrent DOS/CPM-86 Partition
F2h | Some OEM's DOS 3.2+ second partition
FFh | UNIX Bad Block Table Partition

DOS Volume Boot Sectors

The volume boot sector is the first sector on any area of a drive addressed as a volume (or logical DOS disk). On a floppy disk, for example, this sector is the first one on the floppy disk because DOS recognizes the floppy disk as a volume without the need for partitioning. On a hard disk, the volume boot sector or sectors are located as the first sector within any disk area allocated as a nonextended partition, or any area recognizable as a DOS volume.

This special sector resembles the master partition boot sector in that it contains a program as well as some special data tables. The first volume boot sector on a disk is loaded by the system ROM BIOS for floppies or by the master partition boot sector on a hard disk. This program is given control; it performs some tests and then attempts to load the first DOS system file (IO.SYS). The volume boot sector is transparent to a running DOS system; it is outside the data area of the disk on which files are stored.

You create a volume boot sector with the DOS FORMAT command (high-level format). Hard disks have a volume boot sector at the beginning of every DOS logical drive area allocated on the disk, in both the primary and extended partitions. Although all the logical drives contain the program area as well as a data table area, only the program code from the volume boot sector in the active partition on a hard disk is executed. The others are simply read by the DOS system files during boot-up to obtain their data tables and determine the volume parameters.

The volume boot sector contains program code and data. The single data table in this sector is called the media parameter block or disk parameter block. DOS needs the information it contains to verify the capacity of a disk volume as well as the location of important features such as the FAT. The format of this data is very specific.

Errors can cause problems with booting from a disk or with accessing a disk. Some OEM versions of DOS have not adhered to the standards set for the format of this data, which can cause interchange problems with disks formatted by different versions of DOS. The later versions can be more particular, so if you suspect that boot sector differences are causing inability to access a disk, you can use a utility program such as DOS DEBUG or Norton Utilities to copy a boot sector from the newer version of DOS to a disk formatted by the older version. This step should enable the new version of DOS to read the older disk and should not interfere with the less particular older version. This has never been a problem in using different DOS versions from the same OEM, but might occur when mixing different OEM versions. Table 22.6 shows the format and layout of the DOS Boot Record (DBR).

#### Table 22.6 DOS Boot Record (DBR) Format

Offset

Hex | Dec | Field Length | Description
00h | 0 | 3 bytes | Jump Instruction to Boot Program Code
03h | 3 | 8 bytes | OEM Name and DOS Version (IBM 5.0)
0Bh | 11 | 1 word | Bytes/Sector (usually 512)
0Dh | 13 | 1 byte | Sectors/Cluster (must be a power of 2)
0Eh | 14 | 1 word | Reserved Sectors (Boot Sectors, usually 1)
10h | 16 | 1 byte | FAT Copies (usually 2)
11h | 17 | 1 word | Maximum Root Directory Entries (usually 512)
13h | 19 | 1 word | Total Sectors (If Partition <= 32M, else 0)
15h | 21 | 1 byte | Media Descriptor Byte (F8h for Hard Disks)
16h | 22 | 1 word | Sectors/FAT
18h | 24 | 1 word | Sectors/Track
1Ah | 26 | 1 word | Number of Heads
1Ch | 28 | 1 dword | Hidden Sectors (If Partition <= 32M, 1 word only)

For DOS 4.0 or Higher Only, Else 00h

Hex | Dec | Field Length | Description
20h | 32 | 1 dword | Total Sectors (If Partition > 32M, else 0)
24h | 36 | 1 byte | Physical Drive No. (00h=floppy, 80h=hard disk)
25h | 37 | 1 byte | Reserved (00h)
26h | 38 | 1 byte | Extended Boot Record Signature (29h)
27h | 39 | 1 dword | Volume Serial Number (32-bit random number)
2Bh | 43 | 11 bytes | Volume Label ("NO NAME" stored if no label)
36h | 54 | 8 bytes | File System ID ("FAT12" or "FAT16")

For All Versions of DOS

Hex | Dec | Field Length | Description
3Eh | 62 | 448 bytes | Boot Program Code
1FEh | 510 | 2 bytes | Signature Bytes (55AAh)

A WORD is 2 bytes read in reverse order, and a DWORD is two WORDs read in reverse order.

Root Directory

A directory is a simple database containing information about the files stored on a disk. Each record in this database is 32 bytes long, with no delimiters or separating characters between the fields or records. A directory stores almost all of the information that DOS knows about a file: name, attribute, time and date of creation, size, and where the beginning of the file is located on the disk. (The information a directory does not contain about a file is where the file continues on the disk and whether the file is contiguous or fragmented. The FAT contains that information.)

There are two basic types of directories: the root directory and subdirectories. Any given volume can have only one root directory, and the root directory is always stored on a disk in a fixed location immediately following the two copies of the FAT. Root directories vary in size because of the different types and capacities of disks, but the root directory of a given disk is fixed. After a root directory is created, it has a fixed length and cannot be extended to hold more entries. Normally, a hard disk volume has a root directory with room for 512 total entries. Subdirectories are stored as files in the data area of the disk and therefore have no fixed length limits.

Every directory, whether it is the root directory or a subdirectory, is organized in the same way. A directory is a small database with a fixed record length of 32 bytes. Entries in the database store important information about individual files and how files are named on a disk. The directory information is linked to the FAT by the starting cluster entry. In fact, if no file on a disk were longer than one single cluster, the FAT would be unnecessary. The directory stores all of the information needed by DOS to manage the file, with the exception of the list of clusters that the file occupies other than the first one. The FAT stores the remaining information about the other clusters that the file occupies.

To trace a file on a disk, you start with the directory entry to get the information about the starting cluster of the file and its size. Then you go to the file allocation table, where you can follow the chain of clusters that the file occupies until you reach the end of the file.

DOS directory entries are 32 bytes long and are in the format shown in Table 22.7.

#### Table 22.7 DOS Directory Format

Offset Hex | Dec | Field Length | Description
00h | 0 | 8 bytes | File name
08h | 8 | 3 bytes | File extension
0Bh | 11 | 1 byte | File attributes
0Ch | 12 | 10 bytes | Reserved (00h)
16h | 22 | 1 word | Time of creation
18h | 24 | 1 word | Date of creation
1Ah | 26 | 1 word | Starting cluster
1Ch | 28 | 1 dword | Size in bytes

File names and extensions are left-justified and padded with spaces (32h). The first byte of the file name indicates the file status as follows:

Hex | File Status
00h | Entry never used; entries past this point not searched
05h | Indicates that the first character of the file name is actually E5h
E5h | [sigma] (lowercase sigma) indicates that the file has been erased
2Eh | . (period) indicates that this entry is a directory. If the second byte is also 2Eh, the cluster field contains the cluster number of the parent directory (0000h, if the parent is the root).

Table 22.8 describes the DOS directory file attribute byte.

#### Table 22.8 DOS Directory File Attribute Byte

Bit Positions

7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Hex Value | Description
0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 01h | Read-only file
0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 02h | Hidden file
0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 04h | System file
0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 08h | Volume label
0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 10h | Subdirectory
0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 20h | Archive (updated since backup)
0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 40h | Reserved
1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 80h | Reserved
Examples |  |  |  |  |  |  |  |  |
0 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 21h | Read-only, archive
0 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 32h | Hidden, subdirectory, archive
0 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 27h | Read-only, hidden, system, archive

File Allocation Tables

The file allocation table (FAT) is a table of number entries describing how each cluster is allocated on the disk. The data area of the disk has a single entry for each cluster. Sectors in the nondata area on the disk are outside the range of the disk controlled by the FAT. The sectors involved in any of the boot sectors, file allocation table, and root directory are outside the range of sectors controlled by the FAT.

The FAT does not manage every data sector specifically, but rather allocates space in groups of sectors called clusters or allocation units. A cluster is one or more sectors designated by DOS as allocation units of storage. The smallest space a file can use on a disk is one cluster; all files use space on the disk in integer cluster units. If a file is one byte larger than one cluster, two clusters are used. DOS determines the size of a cluster when the disk is high-level formatted by the DOS FORMAT command.

You can think of the FAT as a type of spreadsheet that tracks the allocation of the disk's clusters. Each cell in the spreadsheet corresponds to a single cluster on the disk; the number stored in that cell is a code indicating whether the cluster is used by a file, and if so, where the next cluster of the file is located.

The numbers stored in the FAT are hexadecimal numbers that are either 12 or 16 bits long. The 16-bit FAT numbers are easy to follow because they take an even two bytes of space and can readily be edited. The 12-bit numbers are 1 1/2 bytes long, which presents a problem because most disk sector editors show data in byte units. To edit the FAT, you must do some hex/binary math to convert the displayed byte units to FAT numbers. Fortunately, (unless you are using the DOS DEBUG program), most of the available tools and utility programs have a FAT editing mode that automatically converts the numbers for you. Most of them also show the FAT numbers in decimal form, which most people find easier to handle.

The DOS FDISK program determines whether a 12-bit or 16-bit FAT is placed on a disk, even though the FAT is written during the high-level format (FORMAT). All floppy disks use a 12-bit FAT, but hard disks can use either. On hard disk volumes of more than 16M (32,768 sectors), DOS creates a 16-bit FAT; otherwise, DOS creates a 12-bit FAT.

DOS creates two copies of the FAT. Each one occupies contiguous sectors on the disk, and the second FAT copy immediately follows the first. Unfortunately, DOS uses the second FAT copy only if sectors in the first FAT copy become unreadable. If the first FAT copy is corrupted, which is a much more common problem, DOS does not use the second FAT copy. Even the DOS `CHKDSK` command does not check or verify the second FAT copy. Moreover, whenever DOS updates the first FAT, large portions of the first FAT automatically are copied to the second FAT.

If the first copy was corrupted and then subsequently updated by DOS, a large portion of the first FAT would be copied over to the second FAT copy, damaging it in the process. After the update, the second copy is usually a mirror image of the first one, complete with any corruption. Two FATs rarely stay out of sync for very long. When they are out of sync and DOS writes to the disk, causing the first FAT to be updated, it also causes the second FAT to be overwritten by the first FAT. This is why disk repair and recovery utilities warn you to stop working as soon as you detect a FAT problem. Programs like Norton Disk Doctor use the second copy of the FAT as a reference to repair the first one, but if DOS has already updated the second FAT, repair may be impossible.

Clusters (Allocation Units)

The term cluster was changed to allocation unit in DOS 4.0. The newer term is appropriate because a single cluster is the smallest unit of the disk that DOS can handle when it writes or reads a file. A cluster is equal to one or more sectors. Although a cluster can be a single sector, it is usually more than one. Having more than one sector per cluster reduces the size and processing overhead of the FAT and enables DOS to run faster because it has fewer individual units to manage. The trade-off is in wasted disk space. Because DOS can manage space only in full-cluster units, every file consumes space on the disk in increments of one cluster.

Table 22.9 shows the default cluster (or allocation unit) sizes used by DOS for the various floppy disk formats.

#### Table 22.9 Default Floppy Disk Cluster (Allocation Unit) Sizes

Drive Type | Cluster (Allocation Unit) Size
5 1/4-inch 360K | 2 sectors (1,024 bytes)
5 1/4-inch 1.2M | 1 sector (512 bytes)
3 1/4-inch 720K | 2 sectors (1,024 bytes)
3 1/4-inch 1.44M | 1 sector (512 bytes)
3 1/4-inch 2.88M | 2 sectors (1,024 bytes)

It seems strange that the high-density disks, which have many more individual sectors than low-density disks, sometimes have smaller cluster sizes. The larger the FAT, the more entries DOS must manage, and the slower DOS seems to function. This sluggishness is due to the excessive overhead required to manage all the individual clusters; the more clusters to be managed, the slower things become. The trade-off is in the minimum cluster size.

Smaller clusters generate less slack (space wasted between the actual end of each file and the end of the cluster). With larger clusters, the wasted space grows larger. High-density floppy drives are faster than their low-density counterparts, so perhaps IBM and Microsoft determined that the decrease in cluster size balances the drive's faster operation and offsets the use of a larger FAT.

For hard disks, the cluster size can vary greatly among different versions of DOS and different disk sizes. Table 22.10 shows the cluster sizes that DOS selects for a particular volume size.

#### Table 22.10 Default Hard Disk Cluster (Allocation Unit) Sizes

Hard Disk Volume Size | Cluster (Allocation Unit) Size | FAT Type
0M to less than 16M | 8 sectors or 4,096 bytes | 12-bit
16M through 128M | 4 sectors or 2,048 bytes | 16-bit
More than 128-256M | 8 sectors or 4,096 bytes | 16-bit
More than 256-512M | 16 sectors or 8,192 bytes | 16-bit
More than 512-1,024M | 32 sectors or 16,384 bytes | 16-bit
More than 1,024-2,048M | 64 sectors or 32,768 bytes | 16-bit

In most cases, these cluster sizes, selected by the DOS `FORMAT` command, are the minimum possible for a given partition size. Therefore, 8K clusters are the smallest possible for a partition size of greater than 256M. Although most versions of DOS work like this, some versions might use cluster sizes different from what this table indicates.

The effect of these larger cluster sizes on disk use can be substantial. A drive containing about 5,000 files, with average slack of one-half of the last cluster used for each file, wastes about 20M [5000*(.5*8)K] of file space.

Note that Windows NT and OS/2 already have more sophisticated file systems that do away with the FAT structure, and which are not subject to the limitations of FAT partitions. The FAT32 file system included in the Windows 95 SR2 release allows for more than 64K clusters. Because there can be more clusters, the individual clusters can be smaller. This alleviates the large cluster size problem for larger drives, and extends the maximum size for a partition on a hard disk from 2G to 2T. The cluster sizes used on FAT32 drives of various sizes are as follows:

Drive Size | Cluster Size
0M to less than 260M | 512 bytes
260M-8G | 4,096 bytes
6-16G | 8,192 bytes
16-32G | 16,384 bytes
32G-2T | 32,768 bytes

The Data Area.

The data area of a disk is the area that follows the boot sector, file allocation tables, and root directory on any volume. This area is managed by the FAT and the root directory. DOS divides it into allocation units sometimes called clusters. These clusters are where normal files are stored on a volume.

Diagnostic Read-and-Write Cylinder

The FDISK partitioning program always reserves the last cylinder of a hard disk for use as a special diagnostic read-and-write test cylinder. That this cylinder is reserved is one reason FDISK always reports fewer total cylinders than the drive manufacturer states are available. DOS (or any other operating system) does not use this cylinder for any normal purpose, because it lies outside the partitioned area of the disk.

On systems with IDE, SCSI, or ESDI disk interfaces, the drive and controller might allocate an additional area past the logical end of the drive for a bad-track table and spare sectors. This situation may account for additional discrepancies between FDISK and the drive manufacturer.

The diagnostics area enables software such as a manufacturer-supplied Advanced Diagnostics disk to perform read-and-write tests on a hard disk without corrupting any user data. Low-level format programs for hard disks often use this cylinder as a scratch-pad area for running interleave tests or preserving data during nondestructive formats. This cylinder is also sometimes used as a head landing or parking cylinder on hard disks that do not have an automatic parking facility.

### Potential DOS Upgrade Problems

You already know that the DOS system files have special placement requirements on a hard disk. Sometimes these special requirements cause problems when you are upgrading from one version of DOS to another.

If you have attempted to upgrade a PC system from one version of DOS to another, you know that you use the DOS `SYS` command to replace old system files with new ones. The `SYS` command copies the existing system files (stored on a bootable disk with hidden, system, and read-only attributes) to the disk in the correct position and with the correct names and attributes. The `COPY` command does not copy hidden or system files (nor would it place the system files in the required positions on the destination disk if you modify the file attributes in order to use `COPY`). In addition to transferring the two hidden system files from one disk to another, SYS also updates the DOS volume boot sector on the destination disk so that it is correct for the new version of DOS.

When you execute the SYS command, you are usually greeted by one of two messages:

    System transferred

or

    No room for system on destination disk

If a disk has data on it before you try to write the system files to it, the `SYS` command from DOS versions 3.3 and earlier probably will fail because they are not capable of moving other files out of the way. The `SYS` command in DOS 4.0 and higher versions rarely fail because they can move files out of the way.

Some users think that the cause of the `No room` message on a system that has an older version of DOS is that the system files in any newer version of DOS are always larger than the previous version, and that the new version files cannot fit into the space allocated for older versions. Such users believe that the command fails because this space cannot be provided at the beginning without moving other data away. This is incorrect. The `SYS` command fails in these cases because you are trying to install a version of DOS that has file names different from those already on the disk. There is no normal reason for the `SYS` command to fail when you update the system files on a disk that already has them.

The system files can be placed virtually anywhere on the disk, except that the first clusters of the disk must contain the first cluster of the IO.SYS file (or its equivalent). As long as that requirement is met, the IO.SYS and MSDOS.SYS files can be fragmented and placed just about anywhere on the disk, and the SYS command implements them with no problems whatsoever. The only other requirement is that the names IO.SYS and MSDOS.SYS (or their equivalents) must use the first and second directory entries.

DOS 4.0 and Later Versions

Because the system files must use the first two entries in the root directory of the disk as well as the first cluster (cluster 2) of the disk, the versions of the `SYS` command in DOS 4.0 and later versions automatically move any files that occupy the first two entries that do not match the new system file names to other available entries in the root directory. The `SYS` command also moves the portion of any foreign file occupying the first cluster to other clusters on the disk.

The `SYS` command in older versions of DOS would fail and require a user to make adjustments to the disk. The `SYS` command in DOS versions 5.0 and 6.0 go one step further: They replace old system files with the new ones. Even if the old system files had other names, DOS 5.0 and later ensure that they are overwritten by the new system files. With the enhanced `SYS` command in DOS 4.0 and later versions, it is difficult to make a DOS upgrade fail.

Windows 95

When you install Windows 95 on a system running DOS, the Setup program renames the existing system files with a DOS extension and replaces them with the Windows 95 versions of IO.SYS and MSDOS.SYS. Once the operating system is installed, users can invoke a Boot Manager utility that allows them to boot the system to the old DOS version, if needed. To do this, Boot Manager simply renames the Windows 95 system files with the extension W95 and renames the DOS files back to SYS.

### Known Bugs in DOS

Few things are more frustrating than finding out that software you depend on every day has bugs. It's even worse when DOS does. Every version of DOS ever produced has had bugs, and users must learn to anticipate them. Some problems are never resolved; you must live with them.

Sometimes the problems are severe enough, however, that Microsoft and IBM issue a patch that corrects the problems.

Both companies maintain extensive libraries of patch files and troubleshooting information on their Web sites, at the following addresses:

http://www.microsoft.com/kb/softlib/

http://ps.software.ibm.com/pbin-usa-ps/getobj.pl?/pdocs-usa/alldos.html

As of this writing, the current version of MS-DOS is 6.22, which contains fixes for the previous 6.2x releases. IBM has since released PC-DOS 7.0, as well as a number of patches designed to address specific problems in the operating system. The currently available patch releases are as follows:

- D70DCOMP.ZIP. The `DISKCOMP A: A:` command generates an erroneous message about the disk being defective. `DISKCOMP B: B:` generates a message about the disk being compressed when it is not.
- D70DCOPY.ZIP. If A: drive is automounted, an incorrect message prompting the user to insert a disk in the E: drive is generated.
- D70E.ZIP. Addresses a problem with the `TEMPFILENAME` parameter in the E.INI file.
- D70EMM.ZIP. The Ctrl+Alt+Delete key combination fails to function.
- D70MODE.ZIP. A `Function not supported` error is generated when issuing the `mode con rate=xx` command.
- D70POWER.ZIP. The DX register is not saved when POWER is called, causing possible system hangs or data loss.
- D70SHARE.ZIP. Loading the SHARE program generates `Out of memory` errors.
- D70STAC.ZIP. Allows the SETUP program to function on systems with processors prior to the 80286.
- D70TVL.ZIP. Enables the Windows 95 versions of the XTREE and PCTOOLS utilities to run with PC DOS 7.0.
- D70XDF.ZIP. The `XDFCOPY` command fails to recover free space on a drive that does not have enough room for temp files.

### DOS Disk and Data Recovery

The `CHKDSK`, `RECOVER`, and `SCANDISK` commands are the DOS damaged disk recovery team. These commands are crude, and their actions sometimes are drastic, but at times they are all that is available or needed. `RECOVER` is best known for its function as a data recovery program, and `CHKDSK` usually is used for inspection of the file structure. Many users are unaware that `CHKDSK` can implement repairs to a damaged file structure. DEBUG, a crude, manually controlled program, can help in the case of a disk disaster, if you know exactly what you are doing.

ScanDisk is a safer, more automated, more powerful replacement for CHKDSK and RECOVER. It should be used in their place if you have DOS 6 or higher.

The CHKDSK Command

The useful and powerful DOS `CHKDSK` command is frequently misunderstood. To casual users, the primary function of CHKDSK seems to be providing a disk space allocation report for a given volume as well as a memory allocation report. CHKDSK does those things, but its primary value is in discovering, defining, and repairing problems with the DOS directory and FAT system on a disk volume. In handling data recovery problems, CHKDSK is a valuable tool, although it is crude and simplistic compared to some of the aftermarket utilities that perform similar functions.

The output of the `CHKDSK` command when it runs on a typical (well, maybe not typical, but my own personal) hard disk is as follows:

    Volume 4GB_SCSI    created 08-31-1994 5:05p
    Volume Serial Number is 1882-18CF
    2,146,631,680 bytes total disk space
          163,840 bytes in 3 hidden files
       16,220,160 bytes in 495 directories
      861,634,560 bytes in 10,355 user files
    1,268,613,120 bytes available on disk
           32,768 bytes in each allocation unit
           65,510 total allocation units on disk
           38,715 available allocation units on disk
          655,360 total bytes memory
          632,736 bytes free

A little-known `CHKDSK` function is its ability to report on a specified file's (or group of files') level of fragmentation. CHKDSK can also produce a list of all files (including hidden and system files) on a particular volume, like a super `DIR` command. By far, the most important CHKDSK capabilities are its detection and correction of problems in the DOS file system.

The name of the CHKDSK program is misleading: It seems to be a contraction of CHECK DISK. The program does not actually check a disk, or even the files on a disk, for integrity. CHKDSK cannot even truly show how many bad sectors are on a disk, much less locate and mark them. The real function of CHKDSK is to inspect the directories and FATs to see whether they correspond with each other or contain discrepancies. CHKDSK does not detect (and does not report on) damage in a file; it checks only the FAT and directory areas (that is, the table of contents) of a disk.

CHKDSK also can test files for contiguity. Files loaded into contiguous tracks and sectors of a disk or floppy disk naturally are more efficient. Files spread over wide areas of the disk make access operations take longer. DOS always knows the location of all of a file's fragments by using the pointer numbers in the FAT. These pointers are data that direct DOS to the next segment of the file. Sometimes, for various reasons, these pointers might be lost or corrupted and leave DOS incapable of locating some portion of a file. Using CHKDSK can alert you to this condition and even enable you to reclaim the unused file space.

CHKDSK Command Syntax

The syntax of the `CHKDSK` command is as follows:

    CHKDSK [d:\path\] [filename] [/F] [/V]

The `d``:` specifies the disk volume to analyze. The `\path` and `filename` options specify files to check for fragmentation in addition to the volume analysis. Wild cards are allowed in the file name specification, to specify multiple files in a specified directory for fragmentation analysis. One flaw with the fragmentation analysis is that it does not check for fragmentation across directory boundaries, only within a specified directory.

The `/F` (Fix) switch enables CHKDSK to perform repairs if it finds problems with the directories and FATs. If `/F` is not specified, the program cannot write to the disk, and no repairs are performed.

The `/V` (Verbose) switch causes the program to list all of the entries in all of the directories on a disk and give detailed information in cases where errors are encountered.

The drive, path, and file specifiers are optional. If no parameters are given for the command, CHKDSK processes the default volume or drive and does not check files for contiguity. If you specify `[path]` and `[filename]` parameters, CHKDSK checks all specified files to see whether they are stored contiguously on the disk. One of two messages is displayed as a result:

    All specified file(s) are contiguous

or

    [filename] Contains xxx non-contiguous blocks

The second message is displayed for each file on the disk that is found to be fragmented and displays the number of fragments that comprise the file. A fragmented file is one that is scattered around the disk in pieces rather than existing in one contiguous area of the disk. Fragmented files are slower to load than contiguous files, which reduces disk performance. Fragmented files are also much more difficult to recover if a problem with the FAT or directory on the disk occurs.

If you have only DOS, there are several ways to accomplish a full defragmentation. To defragment files on a floppy disk, you can format a new floppy disk and use `COPY` or `XCOPY` to copy all the files from the fragmented disk to the replacement. For a hard disk, you must completely backup, format, and then restore the disk. This procedure is time-consuming and dangerous, which is why so many defragmenting utilities have been developed.

CHKDSK Limitations

In several instances, CHKDSK operates only partially or not at all. CHKDSK does not process volumes or portions of volumes that have been created in the following ways:

- `SUBST` command volumes
- `ASSIGN` command volumes
- `JOIN` command subdirectories
- Network volumes

SUBST Problems

The `SUBST` command creates a virtual volume, which is actually a subdirectory on an existing volume that uses a different volume specifier (drive letter) as an alias. To analyze the files in a subdirectory created with `SUBST`, you must give the `TRUENAME` or actual path name to the files. `TRUENAME` is an undocumented command in DOS 4.0 and later versions that shows the actual path name for a volume that has been created by the `SUBST` command.

You also can use the `SUBST` command to find out the `TRUENAME` of a particular volume. Suppose that you use `SUBST` to create volume E: from the C:\AUTO\SPECS directory, as follows:

    C:\>SUBST E: C:\AUTO\SPECS

When you attempt to execute a `CHKDSK` of the E: volume and the files there, you see the resulting error message:

    E:\>CHKDSK *.*
    Cannot CHKDSK a SUBSTed or ASSIGNed drive

To run CHKDSK on the files on this virtual volume E:, you must find the actual path the volume represents. You can do so by entering the `SUBST` command (with no parameters):

    E:\>SUBST
    E: => C:\AUTO\SPECS

You can also find the actual path with the undocumented `TRUENAME` command (in DOS 4.0 and later versions only), as follows:

    E:\>TRUENAME E:
    C:\AUTO\SPECS

After finding the path to the files, you can issue the appropriate `CHKDSK` command to check the volume and files:

    E:\>CHKDSK C:\AUTO\SPECS\*.*

The output of the `CHKDSK` command, listing the properties of the disk, is as follows:

    Volume 4GB_SCSI    created 08-31-1994 5:05p
    Volume Serial Number is 1882-18CF
    2,146,631,680 bytes total disk space
          163,840 bytes in 3 hidden files
       16,220,160 bytes in 495 directories
      861,634,560 bytes in 10,355 user files
    1,268,613,120 bytes available on disk
           32,768 bytes in each allocation unit
           65,510 total allocation units on disk
           38,715 available allocation units on disk
          655,360 total bytes memory
          632,736 bytes free
    All specified file(s) are contiguous

ASSIGN Problems

Similarly, CHKDSK does not process a disk drive that has been altered by the `ASSIGN` command. For example, if you have used the command `ASSIGN A=B`, you cannot analyze drive A: unless you first unassign the disk drive with the `ASSIGN` command, that is, `ASSIGN A=A`.

JOIN Problems

CHKDSK does not process a directory tree section created by the `JOIN` command (which joins a physical disk volume to another disk volume as a subdirectory), nor does it process the actual joined physical drive, because such a drive is an invalid drive specification, according to DOS. On volumes where you have used the `JOIN` command, CHKDSK processes the actual portion of the volume and then displays this warning error message:

    Directory is joined
    tree past this point not processed

This message indicates that the command cannot process the directory on which you have used `JOIN`. CHKDSK then continues processing the rest of the volume and outputs the requested volume information.

Network Problems

CHKDSK does not process a networked (shared) disk on either the server or workstation side. In other words, at the file server, you cannot use CHKDSK on any volume that has any portion of itself accessible to remote network stations. At any network station, you can run CHKDSK only on volumes physically attached to that specific station and not on any volume accessed through the network software. If you attempt to run CHKDSK from a server or a workstation on a volume shared on a network, you see this error message:

    Cannot CHKDSK a network drive

If you want to run CHKDSK on the volume, you must go to the specific PC on which the volume physically exists and suspend or disable any sharing of the volume during the `CHKDSK`.

CHKDSK Command Output

CHKDSK normally displays the following information about a disk volume:

- Volume name and creation date
- Volume serial number
- Number of bytes in total disk space
- Number of files and bytes in hidden files
- Number of files and bytes in directories
- Number of files and bytes in user files
- Number of bytes in bad sectors (unallocated clusters)
- Number of bytes available on disk
- Number of bytes in total memory (RAM)
- Number of bytes in free memory
- Error messages if disk errors are encountered

By using optional parameters, CHKDSK also can show the following:

- Names and number of fragments in noncontiguous files
- Names of all directories and files on disk

If a volume name or volume serial number does not exist on a particular volume, that information is not displayed. If no clusters are marked as bad in the volume's FAT, CHKDSK returns no display of bytes in bad sectors.

For example, suppose that a disk was formatted under DOS 6.2 with the following command:

    C:\>FORMAT A: /F:720 /U /S /V:floppy_disk

The output of the `FORMAT` command looks like this:

    Insert new diskette for drive A:
    and press ENTER when ready...
    Formatting 720K
    Format complete.
    System transferred
          730,112 bytes total disk space
          135,168 bytes used by system
          594,944 bytes available on disk
            1,024 bytes in each allocation unit.
              581 allocation units available on disk.
    Volume Serial Number is 266D-1DDC
    Format another (Y/N)?

The status report at the end of the `FORMAT` operation is similar to the output of the `CHKDSK` command. The output of the `CHKDSK` command when run on this disk would appear as follows:

    C:\>CHKDSK A:
    Volume FLOPPY_DISK created 01-16-1994 10:18p
    Volume Serial Number is 266D-1DDC
          730,112 bytes total disk space
           79,872 bytes in 2 hidden files
           55,296 bytes in 1 user files
          594,944 bytes available on disk
            1,024 bytes in each allocation unit
              713 total allocation units on disk
              581 available allocation units on disk
          655,360 total bytes memory
          632,736 bytes free

In this case, CHKDSK shows the volume name and serial number information because the `FORMAT` command placed a volume label on the disk with the `/V:` parameter, and `FORMAT` under DOS 4.0 and later versions automatically places the volume serial number on a disk. Note that three total files are on the disk, two of which have the `HIDDEN` attribute. DOS versions earlier than 5.0 report the volume label `FLOPPY_DISK` as a third hidden file. To see the names of the hidden files, you can execute the `CHKDSK` command with the `/V` parameter, as follows:

    C:\>CHKDSK A: /V
    Volume FLOPPY_DISK created 01-16-1994 10:18p
    Volume Serial Number is 266D-1DDC
    Directory A:\
    A:\IO.SYS
    A:\MSDOS.SYS
    A:\COMMAND.COM
          730,112 bytes total disk space
           79,872 bytes in 2 hidden files
           55,296 bytes in 1 user files
          594,944 bytes available on disk
            1,024 bytes in each allocation unit
              713 total allocation units on disk
              581 available allocation units on disk
          655,360 total bytes memory
          632,736 bytes free

With the `/V` parameter, CHKDSK lists the names of all directories and files across the entire disk, which in this example is only three total files. CHKDSK does not identify which of the files are hidden, it simply lists them all. The DOS System files are the first two files on a bootable disk and normally have hidden, system, and read-only attributes.

During the `FORMAT` of the disk in the example, the FORMAT program did not find any unreadable sectors. Therefore, no clusters were marked in the FAT as bad or unusable, and CHKDSK did not display the message

    xxxxxxxxx Bytes in bad sectors

Even if the disk had developed bad sectors since the `FORMAT` operation, CHKDSK still would not display any bytes in bad sectors because it does not test for and count bad sectors. CHKDSK reads the FAT and reports on whether the FAT says that there are any bad sectors. CHKDSK does not really count sectors; it counts clusters (allocation units) because that is how the FAT system operates.

Although bytes in bad sectors sounds like a problem or error message, it is not. The report is simply stating that a certain number of clusters are marked as bad in the FAT and that DOS, therefore, will never use those clusters. Because nearly all hard disks are manufactured and sold with defective areas, this message is not uncommon. In fact, the higher quality hard disks on the market tend to have more bad sectors than the lower quality drives, based on the manufacturer defect list shipped with the drive (indicating all the known defective spots). Many of the newest controllers allow for sector and track sparing, in which the defects are mapped out of the DOS readable area so that DOS never has to handle them. This procedure is almost standard in drives that have embedded controllers, such as IDE (Integrated Drive Electronics) or SCSI (Small Computer Systems Interface) drives.

Suppose that you use a utility program to mark two clusters (150 and 151, for example) as bad in the FAT of the 720K floppy disk formatted earlier. CHKDSK then reports this information:

    Volume FLOPPY_DISK created 01-16-1994 10:18p
    Volume Serial Number is 266D-1DDC
          730,112 bytes total disk space
           79,872 bytes in 2 hidden files
           55,296 bytes in 1 user files
            2,048 bytes in bad sectors
          592,896 bytes available on disk
            1,024 bytes in each allocation unit
              713 total allocation units on disk
              579 available allocation units on disk
          655,360 total bytes memory
          632,736 bytes free

CHKDSK reports 2,048 bytes in bad sectors, which corresponds exactly to the two clusters just marked as bad. These clusters, of course, are perfectly good--you simply marked them as bad in the FAT. Using disk editor utility programs such as that supplied with the Norton Utilities, you can alter the FAT in almost any way you want.

CHKDSK Operation

Although bytes in bad sectors do not constitute an error or problem, CHKDSK reports problems found in a disk volume's FAT or directory system with one of several descriptive messages that vary to fit the specific error. Sometimes the messages are cryptic or misleading. CHKDSK does not specify how an error should be handled; it does not tell you whether CHKDSK can repair the problem, whether you must use some other utility, or what the consequences of the error and the repair will be. Neither does CHKDSK tell you what caused the problem or how to avoid repeating the problem.

The primary function of CHKDSK is to compare the directory and FAT to determine whether they agree with one another--whether all the data in the directory for files (such as the starting cluster and size information) corresponds to what is in the FAT (such as chains of clusters with end-of-chain indicators). CHKDSK also checks sub- directory file entries, as well as the special "dot" (.) and "double dot" (..) entries that tie the subdirectory system together.

The second function of CHKDSK is to implement repairs to the disk structure. CHKDSK patches the disk so that the directory and FAT are in alignment and agreement. From a repair standpoint, understanding CHKDSK is relatively easy. CHKDSK almost always modifies the directories on a disk to correspond to what is found in the FAT. There are only a few special cases in which CHKDSK modifies the FAT. When it does, the FAT modifications are always the same type of simple change.

Think of CHKDSK's repair capability as a directory patcher. Because CHKDSK cannot repair most types of FAT damage effectively, it simply modifies the disk directories to match whatever problems are found in the FAT.

CHKDSK is not a very smart repair program and often can do more damage repairing the disk than if it had left the disk alone. In many cases, the information in the directories is correct and can be used (by some other utility) to help repair the FAT tables. If you have run CHKDSK with the `/F` parameter, however, the original directory information no longer exists, and a good FAT repair is impossible.

> CAUTION: You should never run CHKDSK with the `/F` parameter without first running it in read-only mode (without the `/F` parameter) to determine whether and to what extent damage exists.

Only after carefully examining the disk damage and determining how CHKDSK would fix the problems do you run CHKDSK with the `/F` parameter. If you do not specify the `/F` parameter when you run CHKDSK, the program is prevented from making corrections to the disk. Rather, it performs repairs in a mock fashion. This limitation is a safety feature because you do not want CHKDSK to take action until you have examined the problem. After deciding whether CHKDSK will make the correct assumptions about the damage, you might want to run it with the `/F` parameter.

> CAUTION: Sometimes people place a CHKDSK `/F` command in their AUTOEXEC.BAT file--this is a very dangerous practice. If a system's disk directories and FAT system become damaged, attempting to load a program whose directory and FAT entries are damaged might lock the system. If, after you reboot, CHKDSK is fixing the problem because it is in the AUTOEXEC.BAT, it can irreparably damage the file structure of the disk. In many cases, CHKDSK ends up causing more damage than originally existed, and no easy way exists to undo the CHKDSK repair. Because CHKDSK is a simple utility that makes often faulty assumptions in repairing a disk, you must run it with great care when you specify the `/F` parameter.

Problems reported by CHKDSK are usually problems with the software and not the hardware. You rarely see a case in which lost clusters, allocation errors, or cross-linked files reported by CHKDSK were caused directly by a hardware fault, although it is certainly possible. The cause is usually a defective program or a program that was stopped before it could close files or purge buffers. A hardware fault certainly can stop a program before it can close files, but many people think that these error messages signify fault with the disk hardware, which is almost never the case.

I recommend running CHKDSK at least once a day on a hard disk system because it is important to find out about file structure errors as soon as possible. Accordingly, placing a `CHKDSK` command in your AUTOEXEC.BAT file is a good idea, but do not use the `/F` parameter. Also, run CHKDSK whenever you suspect that directory or FAT damage might have occurred. For example, whenever a program terminates abnormally or a system crashes for some reason, run CHKDSK to see whether any file system damage has occurred.

Common Errors

All CHKDSK can do is compare the directory and FAT structures to see whether they support or comply with one another; as a result, CHKDSK can detect only certain kinds of problems. When CHKDSK discovers discrepancies between the directory and the FAT structures, they almost always fall into one of the following categories (these errors are the most common ones you will see with CHKDSK):

- Lost allocation units
- Cross-linked files
- Allocation errors
- Invalid allocation units

### The RECOVER Command

The DOS `RECOVER` command is designed to mark clusters as bad in the FAT when the clusters cannot be read properly. When a file cannot be read because of a problem with a sector on the disk going bad, the `RECOVER` command can mark the FAT so that those clusters are not used by another file. Used improperly, this program is highly dangerous.

Many users think that `RECOVER` is used to recover a file or the data within the file in question. What really happens is that only the portion of the file preceding the location of the defect is recovered and remains after the `RECOVER` command operates on it. `RECOVER` marks the defective portion as bad in the FAT and returns to available status all of the data located after the defect, thus destroying undamaged parts of the file. Always make a copy of the file to be recovered before using `RECOVER` because the `COPY` command can get all of the data, including the portion of the file after the location of the defect.

Suppose that you are using a word processing program. You start the program and tell it to load a file called DOCUMENT.TXT. The hard disk has developed a defect in a sector used by this file, and in the middle of loading it, you see this message appear on-screen:

    Sector not found error reading drive C
    Abort, Retry, Ignore, Fail?

You might be able to read the file on a retry, so try several times. If you can load the file by retrying, save the loaded version as a file with a different name, to preserve the data in the file. You still have to repair the structure of the disk to prevent the space from being used again.

After multiple retries, if you still cannot read the file, the data will be more difficult to recover. This operation has two phases, as follows:

- Preserve as much of the data in the file as possible.
- Mark the FAT so that the bad sectors or clusters of the disk are not used again.

Preserving Data

To recover the data from a file, use the DOS `COPY` command to make a copy of the file with a different name. For example, if the file you are recovering has the name DOCUMENT.TXT and you want the copy to be named DOCUMENT.NEW, enter the following at the DOS prompt:

    COPY document.txt document.new

In the middle of the copy, you see the `Sector not found` error message again. The key to this operation is to answer with the (I)gnore option. Then the bad sectors are ignored, and the copy operation can continue to the end of the file. This procedure produces a copy of the file with all the file intact, up to the error location and after the error location. The bad sectors appear as gibberish or garbage in the new copied file, but the entire copy is readable. Use your word processor to load the new copy and remove or retype the garbled sectors.

If this file were a binary file (such as a part of a program), you would have to consider the file a total loss because you do not have the option of retyping the bytes that make up a program file. Your only hope then is to replace the file from a backup. This step completes phase one, which recovers as much of the data as possible. Now you go to phase two, in which you mark the disk so that these areas will not be used again

Marking Bad Sectors

You mark bad sectors on a disk by using the `RECOVER` command. After making the attempted recovery of the data, you can use the following `RECOVER` command at the DOS prompt to mark the sectors as bad in the FAT:

    RECOVER document.txt

In this case, the output of the `RECOVER` command looks like this:

    Press any key to begin recovery of the file(s) on drive C:
    XXXXX of YYYYY bytes recovered

The DOCUMENT.TXT file still is on the disk after this operation, but it has been truncated at the location of the error. Any sectors the `RECOVER` command cannot read are marked as bad sectors in the FAT and will show up the next time you run CHKDSK. You might want to run CHKDSK before and after running `RECOVER` to see the effect of the additional bad sectors.

After using `RECOVER`, delete the DOCUMENT.TXT file because you have already created a copy of it that contains as much good data as possible.

This step completes phase two--and the entire operation. You now have a new file that contains as much of the original file as possible, and the disk FAT is marked so that the defective location will not be a bother.

> CAUTION: Be very careful when you use `RECOVER`. Used improperly, it can do much damage to your files and the FAT. If you enter the `RECOVER` command without a file name for it to work on, the program assumes that you want every file on the disk recovered, and operates on every file and subdirectory on the disk. It converts all subdirectories to files, places all file names in the root directory, and gives them new names (FILE0000.REC, FILE0001.REC, and so on). This process essentially wipes out the file system on the entire disk. Do not use `RECOVER` without providing a file name for it to work on. This program should be considered as dangerous as the `FORMAT` command.

### ScanDisk

ScanDisk is included with DOS 6 and higher versions as well as Windows 95. This program is more thorough and comprehensive than CHKDSK or RECOVER, and can perform the functions of both of them. It is more like a scaled-down version of the Norton Disk Doctor program, and it can verify both file structure and disk sector integrity. If ScanDisk finds problems, the directory and FATs can be repaired. If the program finds bad sectors in the middle of a file, it marks the clusters (allocation units) containing the bad sectors as bad in the FAT, and attempts to read the file data by re-routing around the defect. Although ScanDisk is good, I would recommend using one of the commercial packages like the Norton Utilities for any major problems. These utilities go far beyond what is included in DOS or Windows.

### Third-Party Programs

When you get a `Sector not found` error reading drive C:, by far the best course of action to take is to use one of the third-party disk repair utilities on the market, rather than DOS' RECOVER or even ScanDisk. Programs like the Norton Disk Doctor can perform much more detailed repairs, with a greater amount of safety. If the error is on a floppy disk, use Norton's DiskTool before you use Disk Doctor. DiskTool is specially designed to help you recover data from floppy disks. Disk Doctor and DiskTool preserve as much of the data in the file as possible, and can mark the FAT so that the bad sectors or clusters of the disk are not used again. These Norton Utilities also save Undo information, making it possible for you to reverse any data recovery operation. The Norton Utilities are now distributed by Symantec.

Information is available from the Symantec Web site at:

http://www.symantec.com/lit/util/doswinut/doswinut.html

### Memory-Resident Software Conflicts

One area that gives many users trouble is a type of memory-resident software called Terminate and Stay Resident (TSR) or pop-up utilities. This software loads itself into memory and stays there, waiting for an activation key (usually a keystroke combination).

The problem with pop-up utilities is that they often conflict with each other, as well as with application programs and even DOS. Pop-up utilities can cause many types of problems. Sometimes the problems appear consistently, and at other times they are intermittent. Some computer users do not like to use pop-up utilities unless absolutely necessary because of their potential for problems.

Other memory-resident programs, such as MOUSE.COM, are usually loaded from the AUTOEXEC.BAT file. These memory-resident programs usually do not cause the kind of conflicts that pop-up utilities do, mainly because pop-up utilities are constantly monitoring the keyboard for the hotkey that activates them. (Pop-up utilities are known to barge into memory addresses being used by other programs in order to monitor the keyboard, or to activate.) Memory-resident programs like MOUSE.COM are merely installed in memory, do not poll the keyboard for a hotkey, and generally do not clash with the memory addresses used by other programs.

Device drivers loaded in CONFIG.SYS are another form of memory-resident software and can cause many problems.

If you are experiencing problems that you have traced to any of the three types of memory-resident programs, a common way to correct the problem is to eliminate the conflicting program. Another possibility is to change the order in which device drivers and memory-resident programs are loaded into system memory. Some programs must be loaded first, and others must be loaded last. Sometimes this order preference is indicated in the documentation for the programs, but often it is discovered through trial and error.

Unfortunately, conflicts between memory-resident programs are likely to be around as long as DOS is used. The light at the end of the tunnel is operating systems like Windows 95, Windows NT, and OS/2. The problem with DOS is that it establishes no real rules for how resident programs must interact with each other and the rest of the system. Windows 95, Windows NT, and OS/2 are built on the concept of many programs being resident in memory at one time, and all multitasking. These operating systems should put an end to the problem of resident programs conflicting with each other.

### Hardware Problems versus Software Problems

One of the most aggravating situations in computer repair is opening up a system and troubleshooting all the hardware just to find that the cause of the problem is a software program, not the hardware. Many people have spent large sums of money on replacement hardware, all on the premise that the hardware was causing problems, when software was actually the culprit. To eliminate these aggravating, sometimes embarrassing, and often expensive situations, you should be able to distinguish a hardware problem from a software problem.

Fortunately, making this distinction can be relatively simple. Software problems often are caused by device drivers and memory-resident programs loaded in CONFIG.SYS and AUTOEXEC.BAT on many systems. One of the first things to do when you begin having problems with your system is to boot the system from a DOS disk that has no CONFIG.SYS or AUTOEXEC.BAT configuration files on it. Then test for the problem. If it has disappeared, the cause was probably something in one or both of those files.

To find the problem, begin restoring device drivers and memory-resident programs to CONFIG.SYS and AUTOEXEC.BAT one at a time (starting with CONFIG.SYS). For example, add one program back to CONFIG.SYS, reboot your system, and then determine if the problem has reappeared. When you discover the device driver or memory-resident program causing the problem, you might be able to solve the problem by editing CONFIG.SYS and AUTOEXEC.BAT to change the order in which device drivers and memory-resident programs are loaded. Or, you might have to upgrade or even eliminate the problem device driver or memory-resident program.

## Windows 95

While many users still rely on the DOS command line as their last resort for perfoJ5ing file-management tasks, DOS is no longer the working environment of choice in the PC world. Windows 3.1 is the most prevalent desktop interface today, with Windows 95 rapidly approaching it in popularity. Ultimately, however, Windows 3.1 cannot be considered to be an operating system (although debate concerning this subject has raged for years). It runs on top of DOS, and is completely reliant on the DOS mechanisms discussed in this chapter for startup, file storage, and file maintenance.

Windows 95 can indeed be called an operating system, but at the system level, it is not the radical innovation that it was purported to be before its release. In fact, Windows 95 is actually a combination of a new version of MS-DOS (DOS 7.00, according to the `VER` command) and a new Windows interface (called the Explorer).

Windows 95 marries DOS and the Windows environment into a more cohesive operating system than the DOS/Windows 3.1 combination. Booting a Windows 95 system automatically loads the GUI, but changing one character of the MSDOS.SYS text file causes the computer to boot to a DOS prompt, after which you must type WIN to load the Windows interface. Sound familiar?

### Windows 95 and DOS Compared

Much of Windows 95 is based on the same concepts as DOS and Windows 3.1, but developed to the next logical stage. The same two system files, IO.SYS and MSDOS.SYS, still exist in Windows 95, except that all of the system file code is now located in IO.SYS, while the MSDOS.SYS file is now an ASCII text file that contains configuration settings for the system's boot behavior.

During the system startup, IO.SYS automatically loads the equivalents of HIMEM.SYS, IFSHLP.SYS, and SETVER.EXE into memory. CONFIG.SYS and AUTOEXEC.BAT files can still be used to load drivers and memory-resident programs into memory, but the 32-bit device drivers designed for use with Windows 95, as well as most of its configuration settings, are loaded by entries in the Windows 95 Registry. Finally, the WIN.COM file is loaded and Windows 95 is officially started.

The Registry is a database of reference information, configuration settings, and parameters that is continuously available to all Windows 95 modules. It replaces not only the functionality of the CONFIG.SYS and AUTOEXEC.BAT files, but the Windows 3.1 INI files as well. The troubleshooting process described earlier in this chapter, in which memory-resident programs and drivers are systematically eliminated by modifying the configuration files, can be performed in Windows 95 as well, by modifying the Registry.

> NOTE: Be aware that when upgrading a Windows 3.1 computer to Windows 95, many of the program-specific settings located in configuration files like SYSTEM.INI and WIN.INI are copied to the Windows 95 Registry. Once this has occurred, changing those settings in the INI file will have no effect on the system, because the actual operative setting is located in the Registry.

The Registry is manifested on disk as two files called SYSTEM.DAT and USER.DAT. SYSTEM.DAT contains machine-specific settings, while USER.DAT contains the settings specific to the user that logs into the system. By maintaining multiple USER.DAT files, different people can share the same computer, with each user maintaining his or her own system configuration and desktop preferences. Registry files can be imported, exported, modified, backed up, and restored in order to maintain, modify, and protect the settings for a particular user or machine.

As far as disk storage is concerned, Windows 95 by default still uses the same FAT file system that DOS does, maintaining familiar structures such as the Master Boot Record (MBR), DOS Boot Record (DBR), FATs, and directories. The primary enhancement to the file system is the capability to use file and directory names that are up to 255 characters in length, while retaining backwards compatibility with existing FAT file systems and utilities.

Windows 95 does this by maintaining two names for every file and directory--a long name and a truncated name--that fit the standard DOS 8.3 format. This way, a Windows 95 file can be opened by any DOS or Windows 3.1 application, although saving the file can strip away the long file name. If, for example, you ran an older version of a disk repair utility like Norton Disk Doctor on a Windows 95 FAT volume, you could effectively lose the long names of all the files and directories on your system. Upgrade versions of most Windows applications are now available that support Windows 95 long names.

### FAT32

The original Windows 95 release contained only the FAT file system, but a subsequent upgrade offers a new alternative called FAT32. The Windows 95 OEM Service Release 2 is currently available only with the purchase of a new computer or hard drive from an authorized Microsoft original equipment manufacturer. Most of the other patches and improvements to the operating system included in this release are freely available from Microsoft's Web site, but FAT32 will not be widely available until the release of Windows 98 (code-named Memphis). The OSR2 version of Windows 95 was released in this way not to thwart and irritate millions of users (which it has), but to prevent a backlash of incompatibilities that may occur when the operating system is installed on older hardware.

The primary advantage of FAT32 is its ability to support larger hard drives. Surely no one involved in the development of the FAT file system could ever have dreamed that a mid-range home computer would come with a 2G hard drive, but that is now the standard. It is also the largest drive supported by the FAT file system. The other problem with FAT is that the larger cluster sizes used with high-capacity hard drives are extremely wasteful in terms of the disk space lost to the slack caused by unused bits in allocated clusters.

FAT32 addresses both of these problems, by supporting drives up to 2T (or 2,000G) in size, and with much smaller clusters. A 2G FAT drive uses 32K clusters, while the clusters on the same size FAT32 drive are only 4K. This results in a file system that is more efficient when it comes to storing the maximum possible amount of data on a hard drive, by a factor of 10 to 15 percent. Incidentally, while 2T may seem to be an outrageously large amount of data, consider that a typical PC hard drive has gone from 10M to 2G in less than 15 years, an increase of 20,000 percent. At this rate of growth, your home computer in the year 2010 should be equipped with a 400T hard drive (probably running the FAT256 file system).

FAT32 also overcomes some of the other obvious limitations of the FAT system. For example, FAT32 still has two file allocation tables, but it can now make use of either one, switching to the backup if the first table is corrupted. Also, the root directory of a drive is no longer restricted to a specific size. It is composed of cluster chains like any other directory, and can be located anywhere on the disk.

> NOTE: Although it will not be implemented right away, the design of the FAT32 system will eventually allow partitions to be resized as needed. This ability will be almost as significant an advance as when DOS 4 first allowed partitions greater than 32M in size.

FAT32 volumes are implemented by the FDISK program included with the SR2 Windows 95 release. When you attempt to create a partition larger than 512M, the program asks if you want to enable large disk support. Answering yes causes all partitions larger than 512M to use the FAT32 file system.

FAT32, like Windows 95, is designed to provide the greatest possible backwards compatibility, along with its advanced features. It will continue to support real mode DOS programs as well as today's protected mode applications. This means that you will be able to boot from any DOS disk and still access FAT32 drives. However, applications designed for use on FAT drives that address the hardware directly, such as disk repair programs, will not function on (and may damage) FAT32 volumes.

In the course of providing all of its additional functionality, what FAT32 generally lacks is additional speed. FAT32 drives do not perform any faster than their FAT counterparts and may in fact be slower.

## Windows NT

In complete contrast to DOS, Windows 3.1, and Windows 95 is Windows NT, a 32-bit operating system that was designed from the ground up to point towards the future of both network and desktop computing. The primary problem that consistently holds back the advancement of computing technology is backwards compatibility. It is difficult to sell a product that forces users to junk the investment that they have already made in software or hardware.

Windows 95 is much closer to DOS/Windows 3.1 than it is to Windows NT for this very reason. Corporations will not consider converting to a new operating system on a large scale if it forces them to waste millions of dollars spent on 16-bit software and user training. Windows NT is just such a product, and its acceptance in the marketplace since its original release in 1993 has been gradual but steady. Windows NT 4.0 benefits both from the Windows 95 Explorer interface and from the marketing program that has led to a massive 32-bit software development effort. If sales of operating systems like Windows NT have lagged in the past because of a lack of 32-bit productivity applications, the popularity of Windows 95 has certainly remedied the situation.

Windows NT is a completely different operating system from DOS. Although you can open a DOS session window from within the GUI, it is not a shell in the traditional sense. It is rather a DOS emulation that is designed to provide a familiar command-line interface to users who want it. Many DOS programs will not run in a Windows NT DOS session, nor is it possible to boot the operating system to a character-based state that precedes the loading of the graphical interface, as with Windows 95.

Like Windows 95, Windows NT uses a Registry to store its configuration settings and load drivers. There are no CONFIG.SYS, AUTOEXEC.BAT, or INI files. What's more, there is not even an upgrade path from Windows 95 to Windows NT. You must reinstall and reconfigure all of your applications after setting up the operating system.

Windows NT can use the FAT file system, in which case you can boot the computer from a DOS disk and still access its drives. Some of Windows NT's most advanced features, however, are provided by the NT File System (NTFS). NTFS (like FAT32) allows you to create partitions up to 2T in size, but it also provides the file compression, security, and auditing features that are important to Windows NT computers in network environments.

During the Windows NT installation process, the initial setup is performed on a FAT drive, which is converted to NTFS at the end of the installation process, if you want. You can also convert the drives later, using a CONVERT.EXE utility provided with the operating system. This is one of the few instances in which you can convert an existing volume to another file system without losing data. From the time that a partition is converted to NTFS, however, it is accessible by any other operating system. To switch the machine back to Windows 95, Windows 3.1, or DOS, the NTFS partitions must be removed and FAT partitions created from scratch.

As a result of this, virtually none of the troubleshooting techniques outlined earlier in this chapter can be applied to NTFS drives, nor can the disk utilities intended for use on FAT drives address them. However, although they have been a long time in coming, there are now third-party utilities that can repair and defragment NTFS drives.

© Copyright, Macmillan Computer Publishing. All rights reserved.