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 swi itch-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.
|