Re: [vox-tech] rescuing winxp?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] rescuing winxp?
Quoting Mark K. Kim (firstname.lastname@example.org):
> Starting at some DOS version, the physical location thing became no longer
> necessary. I'm not sure which version but somewhere around DOS 4-ish.
> Apparently the DOS bootstrap code became smarter and figured out ways to
> search for those files in the FS.
I'm perfectly glad to believe you -- but I just don't see how this could
work. Let me explain why:
The Int13h code (obviously) knows nothing about filesystems, so it can
only load whatever's in sector zero of a device. That loads an initial
bootloader such as the unnamed Microsoft one, which historically has
been pretty dirt-stupid, and capable only of parsing the partition
table's four entries to find one with type primary and bearing the
bootable flag, load sector zero of the cylinder spread detailed in that
entry into RAM, and transfer control. Thus, the nameless MBR program
_likewise_ cannot read filesystems -- unless some huge changes have been
made in it.
First-stage loaders are extremely space-constrained. To my knowledge,
the Microsoft one (still) works from entirely inside the MBR sector's
confines. I.e., it really does fit into 446 bytes.
Some of the really innovative third-party bootloaders attempt a really
clever (if fragile) trick to acquire more living space:
If you look really closely at conventional partitioning, you realise
that almost all of cylinder 0 (traditionally) goes completely to waste.
That is, disk sector zero (the MBR) is just one of many 512-byte sectors
on the inital cylinder, and yet addressable partition space starts only
with cylinder 1.
E.g., my server has:
uncle-enzo:~# fdisk -l /dev/sda
Disk /dev/sda: 9105 MB, 9105024000 bytes
64 heads, 32 sectors/track, 8683 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 95 97264 83 Linux
/dev/sda2 96 7369 7448576 5 Extended
/dev/sda5 96 1049 976880 83 Linux
/dev/sda6 1050 1526 488432 83 Linux
/dev/sda7 1527 1647 123888 82 Linux swap
/dev/sda8 1648 2601 976880 83 Linux
/dev/sda9 2602 7369 4882416 83 Linux
There are 32 sectors on each track, and each cylinder has 64 heads
(two heads per platter, 32 platters). Thus, as /sbin/fdisk points out,
there are _2048 sectors_ on each cylinder, each capable of storing 512
bytes. So, there's a _meg_ of available storage on cylinder 0, of which
only 512 bytes normally gets used!
So, I suppose it's _conceivable_ that Microsoft has finally caused its
nameless MBR program to reach sideways over to adjacent sectors on the
first cylinder for extra space to store and read information (which it
can do without inital understanding of FAT), but I frankly doubt it.
My (faint) recollection is that doing the following to Win9x breaks its
1. Boot "command prompt" maintenance mode from the F8 menu. (Can't
remember the exact name; I mean the one where it minimally starts MS-DOS
7.x without doing anything else.
2. "ATTRIB -r -s -h IO.SYS" (Just in case they were set.)
3. COPY IO.SYS FOO
REN FOO IO.SYS
In other words, my recollection is that IO.SYS is still dependent on
physical disk position -- though, starting with DOS 7, Microsoft Corp.
_did_ change MSDOS.SYS into another ASCII config file, in part, and
it became non-position-sensitive.
I lack enough curiosity to set up a test case, but, if you're so moved,
I'd appreciate hearing your results.
> To re-install the MBR....
Note: This refers to what I was calling the Microsoft Corp. nameless
MBR first-stage bootloader.
Cheers, Founding member of the Hyphenation Society, a grassroots-based,
Rick Moen not-for-profit, locally-owned-and-operated, cooperatively-managed,
email@example.com modern-American-English-usage-improvement association.
vox-tech mailing list