Understanding MultiBooting
and Booting Windows from an Extended Partition

by Dan Goodell
Introduction Appendixes: Links Notes Backup Strategies Virtual PC
Miscellaneous Notes


How does DOS and Win95/98/ME assign drive letters?
 
When planning your partitions, keep in mind how any DOS/Win9x OS's will assign drive letters. Drive letters are not "remembered" from one boot to the next, they are assigned at boot time to recognized partitions as the boot process discovers them, in the following order (see Microsoft's KB51978 for details):

Note that DOS/Win9x will include only visible FAT/FAT32 partitions in its scan, while NT-family OS's will add NTFS partitions to the search. A modern BIOS may be configurable as to which disks are considered to be 'disk 1', 'disk 2', etc.

Since DOS/Win9x assigns drive letters at boot time, adding or changing disks or partitions can change the drive letters assigned to pre-existing partitions.

Note that Microsoft does not officially support the use of extra primary partitions with MS-DOS or Win95/98/ME (that is, more than one primary DOS partition per hard disk). However, this does not mean they won't be recognized. In fact, DOS/Win9x will assign drive letters to additional primaries that are not hidden, though they will be assigned after all other drive letters have been normally assigned. These drive letters can be accessed just like any other drive.

However, beware of an obscure bug in DOS/Win9x when there are logical partitions and the last logical partition is invisible (either hidden or non-FAT). In this circumstance, the extra primary may be inaccessible or may be accessible but data corruption may occur. To avoid this bug, keep the last logical partition visible to DOS/Win9x. (Remember, DOS/Win9x do not officially support extra primary partitions, so we can't get too upset about this bug.)


How does Windows XP remember drive letters?
 
Windows NT, 2000 and XP follow the same sequence as DOS/Win9x to assign drive letters to newly discovered partitions at boot time. Unlike DOS/Win9x, however, NT/2000/XP will remember those assignments on subsequent boots--see here for additional details. Partitions will not change drive letters as other partitions or devices are added or removed from the system. Newly discovered partitions are assigned the next available drive letter following the DOS/Win9x sequence of discovery, but skipping over drive letters already "in use".


How to restore the MBR ("fixmbr" and "fdisk /mbr")
 
When booted to the NT/2000/XP recovery console, the MBR boot code can be refreshed by typing the command "fixmbr". When booted from a Win95/98/ME boot disk, the equivalent command is "fdisk /mbr". Both commands replace the boot code but do not alter the partition table at the end of the master boot sector. Refreshing the MBR in this manner will overwrite any replacement boot code installed by another boot manager, so this is one way to disable a third-party boot manager.

The two commands are not exactly identical, however. A subtle difference allows us to use the Win98 version to reset drive letters previously assigned by 2000/XP--a technique I call "Kawecki's Trick".


Tips on moving 2000/XP partitions
 
Windows 2000 and XP keep a list in the registry of partitions and assigned drive letters identified by their signatures. However, the signature may need to change when a partition is moved or resized. Windows 2000/XP may become confused because drive letters in the registry table may be linked to the signatures of other partitions. To avoid potential problems it is wise to clear the registry table and let 2000/XP rebuild it the next time it boots.

You may also temporarily move 2000/XP's paging file to a partition you are not changing. This may prevent paging file errors when the altered 2000/XP is next booted.

My experimentation suggests that Win2000 is less robust than XP and more easily tripped up by invalid signatures or paging file errors.


XP and hidden partitions
 
Windows XP keeps a list of visible partitions. With XP's Disk Management snap-in the drive letters can not only be changed, they can be "removed", rendering those partitions inaccessible to programs. Removing the drive letter is not the same as hiding the partition. Removed drive letters can be "restored", but a partition hidden from XP will not get a drive letter and will be inaccessible to XP (the OS will know something's there, but won't be able to manipulate it). Hidden partitions still show up in XP's Disk Management console, where they are typically identified as "Healthy (Unknown Partition)".

If a previously-hidden partition is newly visible when XP boots, it will be recognized and given a new drive letter. Once a partition is visible to XP it is recommended that you do not subsequently try to hide it from XP with a boot manager or PartitionMagic. Instead, use XP's Disk Management snap-in to remove the drive letter if need be.


What does "Healthy (Unknown Partition)" mean?
 
"Healthy (Unknown Partition)" is the way hidden partitions typically show up in XP's Disk Management console. Although XP can "see" the partition, it will not assign it a drive letter and cannot access files on the hidden partition.

On occasion, a data partition may accidentally have its partition-type code toggled to "hidden" and any data on it may appear to be lost. To recover, simply toggle the partition-type back to its proper code. There are a number of third-party utilities that can easily do this, such as PartitionMagic, BootIt-NG, Partition Commander, Ranish Partition Manager, et al. If you don't have something like that, the easiest way may be to download the free utility ptedit.zip. Extract ptedit.exe from within the zipfile, boot from a DOS floppy (or Win98 startup floppy, or see www.bootdisk.com if you don't have one), run ptedit.exe, and change the appropriate partition-type from hidden-NTFS (or hidden-FAT32) to normal NTFS (or FAT32). Reboot into XP and see if the partition now shows up as it should.


Do hidden partitions still show up in XP?
 
It all depends on how invisible you want the secret partition to be.

Routine third-party boot managers like XOSL, GAG, and BootMagic can mark secret partitions hidden/unhidden depending on which partition is booted--W2K can boot with XP hidden, while XP boots with W2K hidden. However, "hidden" doesn't mean it's totally invisible--W2K and XP will each know the other partition is there, but won't be able to access it and won't give it a drive letter. Normally, this should be enough.

BootIt-NG, Ranish Partition Manager, and System Commander can also do that, but also have an optional proprietary mode with which they can even make the secret partition appear to be unallocated, unpartitioned space, hiding its contents even deeper. The downside, however, is that the proprietary partition handling means you have to swear off using other partition management tools--for example, you can't subsequently use PartitionMagic, fdisk, or XP's native disk management tools because they'll think the hidden space really is unallocated and may overwrite your secret partition. Normally, you shouldn't need to hide a partition this deeply unless you're hiding from a technician the fact that you have a dormant partition there.


"Why did XP install on F: instead of C:?"
 
This can happen if the XP CD is used to create the installation partition and immediately install XP--and there are other pre-existing partitions (hidden or not) on the HDD. The solution is to reboot between creating the new partition and installing XP. Do not let XP-Setup create the new partition and proceed straight to installing the OS without rebooting. The XP CD can be used, just remember to reboot and start over after it creates and formats the partition.

It works like this: let's say you already have two hidden partitions and unallocated space for a new XP partition. You plan to make a new partition for XP, but at the moment it's still unallocated space. When the XP CD boots, there is no visible, active partition, so it may temporarily assign the two hidden partitions as C: and D: (and perhaps your CD drive E:). These are just temporary assignments and won't be visible to the final XP installation, but have an impact on the next step. When you then have XP-Setup create a new partition, it may assign it as F: because C: is already taken, even if only temporarily. If you then let XP-Setup proceed with the rest of the XP install, "F:" will be locked into the new registry. The final XP installation won't see the hidden partitions, but will see itself as drive F: instead of C:.

But if you instead reboot immediately after XP-Setup assigns "F:", it will start over with the temporary drive letter assignments, and this time there will be an active, visible partition (the new partition), which will be assigned a drive letter first--namely "C:". The two hidden partitions will get other drive letters (which you don't care about because they're only temporary anyway and won't exist once the XP install finishes). If you now proceed to install XP, it will see itself as C:.

Note this is a problem only when you have other pre-existing partitions (hidden or not) on the disk. In a normal, fresh XP install on a virgin disk, there won't be hidden partitions to pre-empt the letter C:, so that's why you don't find this issue covered in setup instructions.

Incidentally, a zip drive or card reader in the system can cause the same problem. To make sure XP installs on C:, either reboot after creating the active target partition or else temporarily disconnect or remove the zip drive until XP has finished installing.


"I resized my WinME (or 95 or 98) partition, now my dualboot is broken!"
 
If you have a working Win9x/XP dualboot system using the Microsoft method and try to resize the active (C:) partition, you may find the Win9x system fails to boot, even though the XP system still works properly. The problem is because the bootsect.dos file did not change when the Win9x partition was resized.

The boot sector contains vital information about the size and location of the startup partition (C: with ME, in this case). When you install XP on an existing ME system and let XP configure the dualboot, an image of the existing ME boot sector is saved in a file called bootsect.dos and the real boot sector is replaced with an XP version. The computer always starts booting from the boot sector, which now becomes an XP version. But if you choose ME from the boot menu, a little sleight-of-hand takes place--the XP boot files recall the ME boot sector image from the saved file, step out of the way, and let ME boot up just as though the computer had started up with the ME boot sector in the first place.

If you subsequently resize the ME partition, Partition Magic adjusts the boot sector accordingly to reflect the new size and location. But remember this is now an XP boot sector (and as long as PM readjusts it properly, XP will still boot fine). The ME boot sector is buried in the bootsect.dos file, still sitting there unchanged. So, when you try to boot ME and bootsect.dos is resurrected, it still thinks the old partition layout exists.

The solution is to replace bootsect.dos with a fresh version for a properly resized ME partition. The basic idea is to work on the boot sector: temporarily replace the existing XP version with an ME version again, capture this anew to replace bootsect.dos, and then put the XP version back again. For detailed instructions on how to do this, see https://thpc.info/dual/bootsectdos.html and look for the section on replacing bootsect.dos.

Note this problem occurs only with the Microsoft multiboot method, not if you use a third-party boot manager.


ARCpaths and boot.ini
 
The order of the entries in the Master Partition Table may not necessarily correspond with the order of the physical partitions on the disk. PartitionMagic shows the physical order of the partitions in its graphical display, but does not show the order of entries in the partition table. To look at the partition table, find the utility ptedit.exe on the PM CD. Along with TeraByte's editbini.exe, ptedit is an essential utility for editing NT/2000/XP boot.ini files.

The boot.ini file refers to partitions by their ARCpaths, such as "multi(0)disk(0)rdisk(0)partition(2)". The numbering scheme of the "partition( )" parameter follows the order of entries in the MPT, not the order of the physical partitions themselves. However, the number doesn't actually refer to the slot in the partition table, it refers to the partition sequence as counted by XP. That sequence follows the order of slots in the partition table, but skips empty slots and any extended partition entry. (Although the "extended" entry itself is skipped, logical partitions within the extended partition are counted after all primaries.) Let's say the order of entries in the partition table (regardless of physical order on disk) is XPa-ME-extended-XPb. The boot.ini file in the XPb partition should refer to itself as "partition(3)"--although it's in slot 4, the extended entry is not counted. If you subsequently delete the ME partition, the partition table may show XPa-empty-extended-XPb, and XPb's boot.ini should be changed to "partition(2)" because empty slots are also not counted. Note that the XPb partition could physically be the first or second partition on the disk and it wouldn't matter--it's the order in the partition table that matters.

You can read more about ARCpaths at Microsoft's pages on KB 102873 or "Using ARC Pathnames".


How to replace a hard drive without losing everything
 
The simplest way usually is to use a simple disk copy utility from the drive manufacturer. Many manufacturers have free software specifically for your intended purpose--such as Seagate's "Disk Wizard", Maxtor's "MaxBlast", and WD's "Data Lifeguard Tools". These manufacturers realize it's in their best interests to make it as simple as possible to replace/upgrade your HDD. If you don't get the utility on a floppy disk with your new HD, you can download it from the manufacturer's website. To use, it's as simple as plugging in both HD's, boot from the floppy, copy one HD to the other, remove old HD, put new HD in its place, and reboot. Do not install the new HD first and try to format it with XP; just put it in bare and boot the utility floppy. (Many people make this mistake, which gives XP a chance to give the new HD a different drive letter and screw things up.)

Very important: do not leave the old HD installed as a slave when you first boot the new HD. Get the system back up and running with the new HD by itself first. After the new HD is running properly as a single-HD system, you may reformat and install the old HD as a slave if you want.

If the manufacturer's utility doesn't work (some people do experience a glitch here or there), you can always buy/use something like DriveImage, Ghost, or BootIt-NG. For best results, you want something that will operate from a bootable CD or floppy boot disk, not from within Windows.

The proper way to use these utilities is to install both HDDs, boot from floppy disk, do the copying, remove the original HDD, and boot the new HDD. You don't want to let XP see the new HDD before doing the copy, and you don't want the new XP to see the old XP the first time it boots up. Many people who complain of problems with cloning utilities have made one of these two mistakes.

If you've already made that mistake, Kawecki's trick and a Win98 boot floppy may work to fix things back up. Remove the old HDD, install the new HDD as master, boot from a Win98 boot floppy (download one from www.bootdisk.com if you need to), execute the command "fdisk /mbr", remove the floppy, and reboot from the new HDD. If all goes well, XP should come up as C:. You can subsequently reinstall the old HDD, but only after first getting the system back up and running as a one-HDD system.


Planning your partitions wisely
 
The FAT16 file system has a maximum partition size of 2GB, but it does not have to be the first 2GB of the disk. This is a limitation of the file system--FAT32 allows much larger partition sizes. If the operating system or the computer's BIOS is incapable of supporting Int13h extensions (i.e., uses CHS addressing rather than LBA), then there is also a 8GB limit to deal with. CHS addressing (cylinder/head/sector) can only address the first 8GB of a hard disk. LBA can go up to 137GB, and the new 48-bit LBA can exceed even that.

DOS 6.x uses CHS, not LBA, so is constrained to the first 8GB of the hard disk. It also does not support FAT32, so is limited to partition sizes of 2GB, but that 2GB can be anywhere within the first 8GB of the disk.

DOS7.1 (Win98 version, not Win95) uses CHS by default and supports FAT32. FAT16 partitions are limited to 2GB sizes, but FAT32 partitions can be larger. It can switch to LBA addressing if supported by the BIOS, but because it starts with CHS by default, it may be necessary to locate the start of the partition within the first 8GB of the disk. This seems to be an issue if the operating system is installed below 8GB and then moved above 8GB. For the record, there is a patch that allows Win98 and WinME to break the 8GB barrier if it's not convenient to constrain Win98/ME to the first 8GB of the disk.

WinNT uses CHS but only supports FAT16 or NTFS. It is limited to the first 8GB of the disk. Since NT supports 64KB FAT16 clusters (versus 98's 32KB clusters), FAT16 partitions can be up to 4GB in size.

Win2000/XP use LBA instead of CHS, so are not constrained to the first 8GB of the disk. They support FAT16 and FAT32 partitions, which can be above the 8GB boundary if desired, but any FAT16 partitions must still be no more than 4GB in size.

When planning your partitions, place data partitions at the end of the disk. Don't be tempted to place any of your OS's in logical partitions after the data partitions. While WinNT/2K/XP can remember drive letter assignments, Win95/98/ME assigns drive letters anew during each bootup as the boot process discovers them. If you're careless about your partition ordering you could end up with a data partition assigned as C: before the OS partition gets a letter.

In order for a data partition to be common to multiple OS's, it must be in a format recognizable to all desired OS's. FAT32 data partitions have the advantage that Win98, 2000, and XP can read them. Even if the 2000 or XP system partition is NTFS it will have no trouble reading a FAT32 data partition. Win98 cannot read a NTFS data partition (without third-party help, that is).

Although DOS 6.x and Win95a cannot read a FAT32 partition, converting my data partitions to FAT16 for DOS compatibility would restrict me to a maximum size of 2-GB for each data partition (a FAT16 limitation). So I can either live with this 2-GB restriction, live without access to the data while booted to DOS, or change to another DOS version. I don't have win95a installed and don't specifically need the 6.x version of DOS, so I instead use the FAT32-aware DOS 7 version that comes with Win98. To create a fully functional DOS system that can read FAT32, boot from a Win98 boot floppy, use the command "sys c:" to copy the system files to C:, then copy the DOS files from the Win98 partition's c:\windows\command directory, plus the files himem.sys, emm386.exe, and smartdrv.exe from the c:\windows directory.


Backup strategies
 
[Edit 05-28-2017: this section has been updated here]

There are many different backup strategies, and what works for one person may not be ideal for someone else. I receive numerous inquiries as to how I do backups, so this section is an explanation of my preferred method.

A key point many users fail to grasp is that the operating system is a different animal from your data. The operating system can't be copied/restored just by dealing with files. It involves a boot sector, the registry, and a whole assortment of files that aren't easy to backup while they're "in use" by Windows. Furthermore, the operating system consists of gigabytes of files that rarely change, so frequent backing up of the operating system results in inefficient use of resources--a waste of time and storage space. Your data, on the other hand, consists only of files, many of which may change on a daily basis. These should be backed up more frequently.

Data should be segregated from the OS, and then different approaches can be taken to backup each part. Imagers are ideal for OS backup, while a whole assortment of file backup programs are well-suited for backing up your data. File backup utilities may allow greater control of exactly what you want backed up and when, and often have easy methods of accessing or restoring individual files from the backup.

For what it's worth, some imaging tools are beginning to include "incremental" updating options. This stretches the definition of what an "image" is. Furthermore, in my opinion their "one-size-fits-all" approach (using the same tool to backup either OS or data) doesn't serve either as well as tools designed specifically for each job.

I usually divide my disk space into at least 3 partitions--C: for the OS and applications, D: for data, and E: as extra storage for miscellaneous "expendibles" and backups. (Expendibles are files I don't care about losing or really don't need to backup.)

Using the DOS-based version of DriveImage, I create a new backup image of C: periodically and store it on E:. (It seems so utterly intuitive to me that taking a snapshot of a partition is best done when you aren't booted into it, so I avoid Windows-based imaging programs.) This is nominally done every 3-6 months, or sooner if significant changes have been made to C:. In general, you want to weigh the cost in time to restore your up-to-date system versus the time spent creating and managing backups. Restoring my current system involves restoring from a backup image and then applying any tweaks or updates that had been made since the backup image was created. If few changes have been made, a 5- or 6-month old image may still be viable. But if several programs have been added since the last image, it may be more efficient to make a fresh image. Since imaging is a manual process, the less often it has to be done, the better.

My system is configured to store email, "My Documents", and "Favorites" on D:. That way, I don't have to worry about overwriting data if/when C: is restored from a backup image. If my data files were stored on C:, I would first have to carefully recover them, restore the OS from a DriveImage backup, then put the data files back where they belong. But with my data on D:, I never have to worry about losing any of it when restoring the OS. Separating data also makes it easier to identify what to backup--anything and everything on D: is mine, not the OS's, so gets backed up on a daily basis.

There are many worthy backup programs, but my preference is to have the files gathered together in common zipfiles, where it is an easy matter to extract individual files as needed. That way, I never have to worry about finding a particular program to access backups in some proprietary format. I use a backup routine that runs automatically once per day and backs up D: without my intervention. While it makes periodic full backups of all files, the usual daily run is an incremental backup, skipping files that haven't changed recently. The backups are stored on E:. Some people simply make DriveImage or Ghost images daily, but since 99% of what you are imaging doesn't change on a daily basis, I consider that extremely wasteful. In contrast, incremental backups may take only seconds per day to run, and it wouldn't be unusual for a month's worth (or more!) of backups to fit on a single CDR.

Backup images of C: and backup zipfiles of D: are stored on E:. This partition is formatted FAT32 so I have no trouble getting at my backups from a Win98 (DOS) boot floppy when necessary. This partition also contains expendible files I don't care about backing up. My "Downloads" and "Temporary Internet Files" folders are redirected here. I even consider my backups expendible--after all, if they should accidentally be lost, the originals are still on C: and D:, so the backups can easily be recreated.

Some people like to separate the OS and apps on different partitions--I used to do that, but now consider it more trouble than it's worth, so I keep apps on C:, together with the OS. If you do video editing, file fragmentation can be an issue, so you'll want to keep a large, empty partition just for that, so as not to fragment your video files when working on them.

As a backup strategy, the backup images and zipfiles should ideally be on a separate HD to protect against mechanical failure of the primary HD. That's hard to do if you're working with a laptop, however. USB/external HDs might be an alternative, but that would be complicated by my automated daily backup program. Due to convenience and time savings, the automated backups are far more important to me than trying to work with external HDs, so I just work with E: as a separate partition on the same HD and just have to be more diligent about offloading backups periodically. Every couple weeks I transfer backups from E: onto CD.

This way I won't lose more than a couple weeks of work in the rare event of a sudden HD failure. I've never encountered this worst case scenario, however--the HD failures I've experienced have given enough forewarning to start transferring backups more frequently. (Note: I don't burn DriveImage images direct to CD, I prefer to create them in CD-sized splits on HD, then burn a copy of those onto CD.)

On the other hand, I've had to recover from backups due to software problems far more often than HD failures. Accordingly, it's convenient to have the latest backup right there on the HD for quick and easy restoration. If I accidentally overwrite the wrong Excel file, for example, I can quickly restore it from yesterday's backup on the HD without having to fumble around for a backup CD. Or if I try something major like installing SP4 and it doesn't go right, I can boot DriveImage from a DOS floppy and quickly restore C: from the backup image on the E: partition.


What is the difference between an "image" and a "clone"?
 
A clone is a partition that is an exact copy of the source partition--boot sector, directories, and all files--copied sector-by-sector.

An image is a file containing a compressed snapshot of the source partition, which can later be extracted to a blank area of hard disk space to recreate a clone of the original.

Think of it like a zipfile, just on a grander scale. You probably know that with WinZip, PKZip, and other zip programs, you can compress entire directories (er, "folders") of files into a single zipfile, which can later be unzipped to restore all the encapsulated files and even the directory structure. An image is like a zipfile: it's not an exact duplicate of the original files, but it contains within it the means to restore exact duplicates--in this case not just a set of files, but an entire partition.

Like a zipfile, an image is meant to be for storage--an archive. Like a zipfile, you can't directly use an image. To make use of a zipfile, you must extract the files from within it. To make use of an image, you must extract the partition within it onto a hard disk.

So which is better, a clone or an image?

Well, you generally do not need to create a clone or copy unless you are ready to use it immediately. For example, if you are replacing your hard disk, you want a clone now, so if you make an image you'd just have to extract it immediately anyway. In contrast, an image is more appropriate if you are just making a backup to store away in case you might need it later. Then when you need it, you extract it to restore the enclosed partition on a hard disk.

An image is much smaller--a 20GB partition that is half full might fit in a 5GB image file, but if cloned it would still be 20GB.

A large image can be split into multiple pieces (for example, to store on a set of CDRs), while there is no way to split a clone and still have it be a duplicate of the original partition.

An image can also be saved on CDR or DVD-R (remember, it's a file, so can go anywhere a file can go), but a clone of the partition cannot.


Why won't 5GB of data clone to a 10GB partition?
 
It certainly is possible to clone a source partition onto a smaller partition. However, it is necessary that there be sufficient space to hold the clone, which might span more space than the net amount of the data. For example, if you have a 20GB source partition with 5GB of data, that 5GB may be fragmented and spread out over, say, 12GB of disk space with lots of interspersed free space. Since a true clone puts sectors in the same order as the original (including interspersed free-space sectors), the target would need to be at least 12GB, even though the net amount of data is only 5GB. The solution is rather obvious--defrag the source first to reorder the data into contiguous sectors/clusters, and it won't be spread out over 12GB of disk space.


DriveImage = restoration protection
 
The method of setting up multibooting that is the subject of this webpage involves creating images of the OS installations. This has a nice side benefit in that I automatically have backup images to quickly restore a partition if something gets messed up. Indeed, I keep the OS images and periodically refresh them with new images of each partition as significant changes are made in the OS's.


running utilities from the hard disk
 
While I made a logical partition initially to store the OS images, it also came in handy to copy the utilities (ptedit.exe, de.exe, editbini.exe, and all files from the PartitionMagic and DriveImage floppies) to the logical partition. The drive letter may jump around a bit, but find the right drive letter and I can run the utilities more quickly and without floppy-swapping.


introducing pqboot.exe
 
If you install OS's in separate partitions and do not have a boot manager installed, you can still alter which partition will boot by setting one partition "active" in the partition table and setting all other primary partitions "hidden". This can be done with PartitionMagic, but it's inconvenient to startup PartitionMagic just to switch the active boot partition. A quicker way is to use pqboot.exe, a text-mode utility that performs one simple task: all it does is simply set active/unhidden the chosen partition while hiding all others. It prints onscreen a numbered list of your primary partitions and their status (active, hidden, etc). Punch a number on the keyboard and it sets that partition active/unhidden and hides the other primary partitions. End of task. Reboot and the active partition is the one that boots. This can save some time while installing OS's before you get around to installing a boot manager. (It only works on primary partitions, though). For OS's in primary partitions, pqboot.exe is a great way to test how each boots up before introducing the boot manager into the mix.

Find the utility pqboot.exe on the PartitionMagic CD and copy it, preferably to a logical partition that is always visible. If you're clever, install the DOS partition first instead of last and use pqboot.exe to toggle it on and off during installation of other OS's and you can minimize the number of times you have to resort to a boot floppy.


introducing mbrwork.exe
 
Here's another nifty little utility that didn't have a place on my "Tools" page but is nevertheless handy to have around. This DOS text-mode utility can set a partition active, restore a standard MBR, clear the EMBR, or completely clear the master boot sector--MBR and partition table. It can also be used to directly edit the partition table, although ptedit is easier to use for that purpose. Download mbrwork from www.terabyteunlimited.com/downloads-free-software.


creating more than 4 primary partitions: Bootit-NG and Ranish Partition Manager
 
The master partition table (MPT) only has room for 4 entries, so how can you have more than 4 primary partitions? While these particular partition managers can do normal partitioning work, they can optionally be configured to maintain their own private list of partitions, which can include more than 4 primaries. You then specify which four should be listed in the MPT. This permits you to "show" the partitions that should be visible to the active operating system, while leaving some partitions unlisted in the MPT.

WARNING: this means the disk space occupied by the unlisted partitions will appear to be available unallocated space to normal disk utilities like fdisk, PartitionMagic, or even XP's Disk Management functions. It would be easy to overwrite partitions you don't know are there, so once you commit yourself to this non-standard partition technique, it is absolutely vital that you do not use any other partitioning utility!


evaluation: TeraByte Bootit-NG
 
Extremely versatile all-in-one (boot manager/partition manager/imager). Must be installed from its own dedicated boot floppy. Uses hidden sectors on track 0 (called EMBR). Can selectively hide primary and logical partitions. Graphical menu and config utility. Can image directly to some CDRW and USB drives. Can easily be disabled, but reenabling requires the installation floppy. Optional feature permits more than 4 primary partitions but at the expense of non-standard manipulation of partition table, which is incompatible with PartitionMagic or other partitioning utils. I'm not familiar with every OS, but as we've demonstrated, I'm not sure you need more than 4 primary partitions, so why use a proprietary format if you don't need to? Save yourself a lot of potential grief and keep the "limit primaries" option enabled.


evaluation: Powerquest BootMagic
 
Must be installed in a FAT/FAT32 partition. Uses hidden sectors on track 0. Can selectively hide primary partitions but cannot selectively hide logical partitions. Works very well if OS's are only in primary partitions and at least one of them is FAT/FAT32. Config utility can easily disable/reenable the boot manager without requiring reinstallation (provided you can still get at the partition the config utility is on). Graphical "windows-like" display and config utility.


evaluation: System Commander
 
Too expensive for me to test myself. Reportedly version 7 can be installed in FAT/FAT32/NTFS partitions. Unknown if it can selectively hide logical partitions. My old version was easy to disable/reenable, but required a FAT partition and could not selectively hide logical partitions.


evaluation: XOSL (Extended Operating System Loader)
 
Versatile. Can selectively hide primary and logical partitions. Requires FAT/FAT32 partition or its own proprietary partition, which can be a logical partition. Does not use hidden sectors on track 0. Can be daisy-chained with other boot managers. Graphical display and configuration. Doesn't autodetect installed OS's, but manual configuration is easy. XOSL does not have an option to disable/reenable the boot manager, but it can be disabled by restoring the MBR with a standard version (e.g., the DOS/Win9x "fdisk /mbr" command). To reenable XOSL, run the XOSL installation program again and restore (since the XOSL configuration files are still there). FREE!


evaluation: Casper-XP
 
In early 2003 I evaluated CasperXP to see how it compared to true cloning utilities like Ghost and DriveImage. I had no trouble duplicating the operating system and it booted fine--after I corrected the boot.ini file. I didn't bother to check what files were open, but it seemed like everything got copied, and the copy did boot properly.

CasperXP does not make true sector-by-sector clones like DriveImage and Ghost, but instead makes file-by-file copies of the source partition. However, I was impressed to note it automatically altered the registry [MountedDevices] key to swap the drive letters of the source and target partitions so the copy would boot up with the same drive letter as the original. However, it did not fix the boot.ini file on the copy. In my case, I needed to manually edit the copy's boot.ini file so the copy would boot.

CasperXP does not make clones, it copies files. A clone is a sector-by-sector duplicate of the original. CasperXP does not do that, it copies files. A clone by definition must have the same file format (FAT32, NTFS, et al) as the original. CasperXP will copy files from a FAT32 partition to a NTFS partition, or vice-versa. Imaging/cloning utilities create the copy in unallocated disk space--if a partition is already there, it is removed before the imager/cloner proceeds. CasperXP cannot write to unallocated disk space, it can only write to existing partitions (remember, it copies files)--if the target is unallocated space, a formatted partition is first created (possibly even using WinXP's native Disk Management services) before CasperXP can copy files to it. CasperXP can only work with file formats recognizable to Windows XP, which excludes linux and hidden partitions. Most true imaging/cloning utilities can work with a wider variety of partitions, including linux and hidden partitions.

Image files (such as those made by Ghost or DriveImage) are an excellent way to store an entire partition onto another backup medium, such as CD or tape. I don't see CasperXP doing that. Image files may also be smaller because the data may be compressed when stored--a 40GB partition with 10GB of data may be stored in around 5GB of space on a single DVD. If you need to just restore a few individual files from a backup image, both Ghost and DriveImage have Windows-based front-ends to facilitate that, so CasperXP doesn't necessarily have an advantage here, either.

Finally, an image is a different disaster recovery stratagem than CasperXP. Images follow a backup/restore paradigm--when disaster strikes, you restore from your backup to the original (or replacement) hard disk and you're back up and running. You can even restore from a DOS floppy, which is great when Windows has crashed fatally. CasperXP makes a copy--when disaster strikes, you don't restore, you just start using the copy . . . which is about the only way to use it--since CasperXP requires a working Windows XP to run, you can't use it to "restore" anything unless Windows is already working, which limits its usefulness for that purpose.

Personally, I prefer Ghost or DriveImage because I backup my system partition for later restoration if/when necessary. CasperXP is less desirable for backup/restore purposes because the "backup" takes up more room than a compressed image, and because you have no way of "restoring" from a backup unless you have XP running (since CasperXP only runs from within XP). Ghost and DriveImage don't need a working XP to restore from a backup image, so are better for disaster recovery purposes.

What CasperXP is good for is transferring a working XP system to another drive in order to upgrade the hard drive--in other words, not a backup/restore operation, but a transfer and then boot the copy. As a side benefit, since it makes a file-by-file copy, the copy is naturally defragmented in the process. It seems to work well for its intended use--though ultimately, it will be up to each user to decide whether the price is reasonable for this limited purpose.

(2007 Update: A user has reported that the current version of Casper XP appears to do byte-for-byte cloning rather than simply copying files.)


problem: Intuit TurboTax and the EMBR
 
Emboldened by Microsoft's product activation scheme imposed with XP, in 2003 (2002 tax year) Intuit introduced a similar product activation feature in their TurboTax product. Intuit's method reportedly involved storing secret activation data in the "reserved" sectors on the hard disk's first track--the same EMBR area used by some boot managers and partition managers. This action can cause crashes, conflicts, or loss of data. This area is not part of any partition and is thus outside the control of any file system, so there is no way for Intuit (or any other program) to know whether the EMBR is already being used. It is up to the user to police who gets use of that area--not an easy task if Intuit is secretive about what they are doing. It's reasonable for boot/partition utilities to need the use of the EMBR area--they need to work outside the realm of partitions and operating systems. Many will also tell you if they use that area. But it's arrogant and unconscionable for Intuit to think they have the right to presume all areas of your hard disk are fair game, and jump outside the realm of the operating system to run roughshod over areas of your hard disk they don't belong in.


Advanced Features of BootIt-NG
 
There are a couple "features" of XP that can trip you up, regardless of whether you use BootIt, Ghost, DriveImage, or anything else. Most people who complain that such-and-such copy/clone utility didn't work are being tripped up by XP, not by the imaging utility.

One issue is that the NT-family OS's use a boot.ini file in the active startup partition that must point to the partition where XP is running from. When you copy/clone partition-1 to partition-2, boot.ini goes with it, but then the boot.ini in partition-2 may be pointing to the wrong place. There are two ways to handle this: either edit the boot.ini file to point to the right partition, or change the order of the partition table entries so boot.ini is fooled. The former can be accomplished with any text editor, provided you can access boot.ini (easily done with TeraByte's editbini.exe utility if we're talking about NTFS partitions).

If you're using BootIt-NG, the latter solution is easier and makes use of BootIt's ability to rearrange the partition table on the fly when you choose which menu item to boot. First, understand that the four entries in the partition table can be in any order and do not necessarily have to correspond with the physical order of the actual partitions themselves. Boot.ini looks at the partition table to determine which partition it's supposed to boot XP from. So if partition-1's boot.ini found itself in the first slot of the partition table, you can fool partition-2's boot.ini by rearranging the partition table so partition-2 appears first in the table. BootIt-NG allows you to rearrange on the fly the four partition table entries in any order for each menu item (see steps 33-34 in TeraByte Unlimited's "Tutorial One"--https://www.bootitng.com/tutorials/tutorial1.pdf).

The other issue is that NT-family OS's "remember" drive letters by recording the signatures of the corresponding partitions in the XP registry. When you clone partition-1 to partition-2, the registry goes with it. But then when partition-2 tries to boot it will remember that the partition signature corresponding to partition-1 is where 'C:' was, and it may assign partition-2 a different drive letter. That's bad. The solution is to make XP forget the remembered drive letter assignments. The registry tweak to clear the partition signatures will do that. Make the registry edit on partition-1 before cloning it to partition-2, then XP won't remember any previous drive letters and will build the registry partition signatures anew the first time it boots.

An even easier method is to use BootIt's [Clear Sig] button. That deletes the DiskID in the MBR (similar to Kawecki's trick), thereby forcing XP to ignore the old partition signatures and rebuild the registry table the first time it boots.


evaluation: Savepart
 
In late 2004 I evaluated Savepart 2.91, a freeware alternative to the more popular imaging/cloning utilities like Ghost and DriveImage. Savepart can clone one partition to another, or save and restore partition images. This is an english version of a program originally written in french. The interface and terminology takes a bit of getting used to (for example, the term "elements" is used for partitions), but it worked just fine and was modern enough to clone a NTFS WinXP-SP2 partition without any errors. This was just a cursory evaluation, as I'm not equipped to do a comprehensive review anyway (with the new gonzo-gigabyte hard drives, SATA, RAID, etc).

Savepart works slowly, but gives you 10 levels of image compression--from 0 (no compression) to 9, with lower compression levels working more quickly. In a quick comparison test on a random partition, Savepart levels 5 or 6 seemed to achieve similar compression ratios as DriveImage 2002 and BootIt-NG, but taking twice as long. Savepart easily cloned primary to logical, and vice versa. Savepart will readily clone to a smaller partition, provided the data will fit (BootIt-NG could not do this). Savepart also checked the "Hidden Sectors" field of the target partition's boot sector parameter table, correcting it if it was wrong (DriveImage could not do this).

Savepart includes a unique feature: with it you can edit the drive letter assignments in the registry's [MountedDevices] key--without booting into Windows! This is the only utility, including the commercial cloning utilities, that I have seen with this handy feature!

Back to Top
author: Dan Goodell, ©2003-2007
last revised: 05/25/2007