Upgrading and Repairing PCs

Replacing an Existing Drive

Previous sections discussed installing a single hard drive or adding a new hard drive to a system. Although formatting and partitioning a new hard disk can be challenging, replacing an existing drive and moving your programs and files to it can be a lot more challenging.

Drive Migration for MS-DOS Users

When MS-DOS 6.x was dominant, many users used this straightforward method to transfer the contents of their old hard drive to their new hard drive:

Because the only hidden files such a system would have were probably the operating system boot files (already installed) and the Windows 3.1 permanent swap file (which could be re-created after restarting Windows), this "free" data transfer routine worked well for many people.

After the original drive was removed from the system, the new drive would be jumpered as master and assigned C:. The user then would need to run FDISK from a floppy and set the primary partition on the new C: drive as Active. Then, the user would exit FDISK and the drive would boot.

Drive Migration for Windows 9x/Me Users

Windows 9x/Me have complicated the once-simple act of data transfer to a new system by their frequent use of hidden files and folders (such as \Windows\Inf, where Windows 9x hardware drivers are stored). The extensive use of hidden files was a major reason for a greatly enhanced version of XCOPY being included in Windows 9x/Me.

Note XCOPY32 is automatically used in place of XCOPY when XCOPY is started within a command prompt session under Windows.

XCOPY32 for Windows 9x Data Transfer

Compared to "classic" XCOPY, XCOPY32 can copy hidden files; can preserve file attributes such as system, hidden, read-only, and archive; can automatically create folders; and is compatible with long filenames. Thus, using it to duplicate an existing drive is possible, but with these cautions:

• The XCOPY32 command is much more complex.

• Errors might occur during the copy process because of Windows's use of temporary files during normal operation, but XCOPY32 can be forced to continue.

This command line calls XCOPY32 and transfers all files and folders with their original attributes intact from the original drive (C:) to the new drive (D:). This command, however, must be run from an MS-DOS prompt window (and not MS-DOS Mode) under Windows 9x/Me, as follows:

xcopy32 c:\. d:\ /e/c/h/r/k

The command switches are explained here:

• /e. Copies folders, even if empty; also copies all folders beneath the starting folder.

• /c. Continues to copy after errors. The Windows swap file can't be copied due to being in use.

• /h. Copies hidden and system files.

• /r. Overwrites read-only files.

• /k. Preserves file attributes.

Repeat the command with appropriate drive-letter changes for any additional drive letters on your old drive.

After the original drive is removed from the system, the new drive must be jumpered as master (or single), and the operating system assigns it C:. You next need to run FDISK from a floppy and set the primary partition on the new C: drive as Active. Then, exit FDISK, and the drive will boot.

Note that although the XCOPY method has worked for me, some people have problems with it. A much more automated and easy approach to cloning drives is to use commercial software designed for that purpose, such as Drive Copy by PowerQuest or Norton Ghost by Symantec. Drive copying programs included with older versions of hard disk installation programs provided by drive vendors have not always worked well, but the latest versions of these programs can be very useful for drive copying and other preparation tasks. In recent installations, I've found that the Maxtor MaxBlast disk copying program worked perfectly in transferring a Windows XP installation to a much larger target drive. So, I recommend you try the drive vendor's copying program first. If you have problems, you can use a third-party product instead.

Even though many users have prepared new hard drives for use with nothing but FDISK and FORMAT, today's more complex systems are presenting increasingly good reasons for looking at alternatives.

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 among disks of varying sizes. They determine how a disk appears to DOS and applications. 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.

Four primary interface layers exist between an application program running on a system and the disk drives attached to the system. They consist of software routines that can perform various functions, usually to communicate with the adjacent layers. These layers are as follows:

• 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 the 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 writes only 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 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 add the new subdirectory information.

• Use Int 26h to write the sectors back to the disk.

The number of steps is even greater when you factor in the difficulty in determining exactly which sectors must 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 correct disk locations by 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 do not choose to access the disk in this manner and instead use the higher-level Int 21h, which does all the work automatically.

Typically, only disk- and sector-editing programs access disk drives 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, the DOS DEBUG program 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 an expansion 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 can't be loaded until after bootup), only drives with ROM BIOS–based Int 13h support can be bootable. Int 13h routines communicate directly with the controller using the I/O ports on the controller.

Note The DVD accompanying this book contains a list of functions available at the Interrupt 13h BIOS interface, as well as the error codes that might be returned by the BIOS INT 13h routines. See the Technical Reference section of the DVD.

Few high-powered disk utility programs, other than some basic disk-formatting applications, can talk to the disk at the Int 13h level. The DOS FDISK program communicates at the Int 13h level, as does the Norton Utilities' DISKEDIT program when it is in its absolute sector mode; these are some of the few disk-repair utilities that can do so. These programs are important because you can use them for the worst data recovery situations in which the partition tables have been corrupted. Because the partition tables, and 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 at only the DOS Int 25/26h level, which makes them useless for accessing areas of a disk outside DOS's domain.

Disk Controller I/O Port Commands

At the lowest interface level, programs communicate directly with 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.

Most applications work through the Int 21h interface. This interface passes commands to the ROM BIOS as Int 13h commands; the ROM BIOS then converts these commands into direct controller commands. 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, leaving them instead up to DOS and the ROM BIOS. This also enables applications to run on widely varying types of hardware—as long as the correct ROM BIOS and DOS support is in place.

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. Each type of controller has different I/O port locations. With different controllers also come differences among the commands presented at the ports. 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 is relatively independent from the disk hardware and can support many types of drives and controllers.