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):
- active or first primary partition on disk 1
- active or first primary partition on disk 2
- active or first primary partition on disk 3, etc.
- all logical partitions on disk 1, in sequential order
- all logical partitions on disk 2, in sequential order
- all logical partitions on disk 3, etc.
- all additional primary partitions on disk 1, in sequential order
- all additional primary partitions on disk 2, in sequential order
- all additional primary partitions on disk 3, etc.
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
