31. If no problems occur, the DOS volume boot sector executes IO.SYS/IBMBIO.COM.

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

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

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

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

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

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

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

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

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

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

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

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

File Management

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

DOS File Space Allocation

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

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

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

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

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

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

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

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

Interfacing to Disk Drives

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

Table 22.1  Floppy Disk Format Specifications

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

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

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

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

Interrupt 21h

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

Interrupt 25h and 26h

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

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

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

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

Interrupt 13h

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

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

Table 22.2  Int 13h BIOS Disk Functions

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

Table 22.3  BIOS INT 13h Error Codes

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

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

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

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

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

Disk Controller I/O Port Commands

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

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

FIG. 22.2  Relationships between various interface levels.

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

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

DOS Structures

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

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

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

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

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

Master Partition Boot Sectors

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

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

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

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

Table 22.4  Master Boot Record (Partition Table)

Partition Table Entry #1

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

Partition Table Entry #2

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

Partition Table Entry #3

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

Partition Table Entry #4

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

Signature Bytes

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

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

Table 22.5  Partition Table System Indicator Byte Values

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

DOS Volume Boot Sectors

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

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

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

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

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

Table 22.6  DOS Boot Record (DBR) Format

Offset

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

For DOS 4.0 or Higher Only, Else 00h

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

For All Versions of DOS

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

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

Root Directory

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

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

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

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

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

Table 22.7  DOS Directory Format

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

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

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

Table 22.8 describes the DOS directory file attribute byte.

Table 22.8  DOS Directory File Attribute Byte

Bit Positions

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

File Allocation Tables

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

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

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

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

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

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

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

Clusters (Allocation Units)

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

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

Table 22.9  Default Floppy Disk Cluster (Allocation Unit) Sizes

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

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

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

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

Table 22.10  Default Hard Disk Cluster (Allocation Unit) Sizes

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

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

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

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

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

The Data Area.

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

Diagnostic Read-and-Write Cylinder

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

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

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

Potential DOS Upgrade Problems

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

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

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

System transferred

or

No room for system on destination disk

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

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

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

DOS 4.0 and Later Versions

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

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

Windows 95

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

Known Bugs in DOS

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

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

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

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

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

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

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

DOS Disk and Data Recovery

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

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

The CHKDSK Command

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

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

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

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

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

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

CHKDSK Command Syntax

The syntax of the CHKDSK command is as follows:

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

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

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

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

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

All specified file(s) are contiguous

or

[filename] Contains xxx non-contiguous blocks

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

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

CHKDSK Limitations

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

• SUBST command volumes
  
  
• ASSIGN command volumes
  
  
• JOIN command subdirectories
  
  
• Network volumes

SUBST Problems

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

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

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

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

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

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

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

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

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

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

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

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

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

ASSIGN Problems

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

JOIN Problems

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

Directory is joined
tree past this point not processed

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

Network Problems

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

Cannot CHKDSK a network drive

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

CHKDSK Command Output

CHKDSK normally displays the following information about a disk volume:

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

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

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

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

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

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

The output of the FORMAT command looks like this:

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

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

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

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

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

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

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

xxxxxxxxx Bytes in bad sectors

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

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

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

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

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

CHKDSK Operation

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

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

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

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

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

---

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

---

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

---

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

---

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

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

Common Errors

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

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

The RECOVER Command

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

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

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

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

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

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

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

Preserving Data

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

COPY document.txt document.new

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

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

Marking Bad Sectors

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

RECOVER document.txt

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

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

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

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

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

---

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

---

ScanDisk

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

Third-Party Programs

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

Information is available from the Symantec Web site at:

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

Memory-Resident Software Conflicts

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

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

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

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

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

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

Hardware Problems versus Software Problems

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

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

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

Windows 95

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

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

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

Windows 95 and DOS Compared

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

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

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

---

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

---

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

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

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

FAT32

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

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

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

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

---

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

---

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

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

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

Windows NT

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

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

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

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

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

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

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

---

© Copyright, Macmillan Computer Publishing. All rights reserved.