[vox-tech] rescuing winxp?

[Rick Moen]

Quoting Mark K. Kim (lugod at cbreak.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
uncle-enzo:~#


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
boot process:

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
    DEL IO.SYS
    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,
rick at linuxmafia.com     modern-American-English-usage-improvement association.