l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2004 Sep 24 13:20

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] rescuing winxp?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] rescuing winxp?

I found this:


It says DOS 3.3 needs IO.SYS to be located in the first three sectors of
the "disk data area" (whatever that is.)  DOS 5.0 does not need IO.SYS to
be located in the first three sectors, but must be contiguous.

I think the majority of this work is done by the boot sector code, not
MBR, so it has a little more room to work with.  But that's just a wild


On Fri, 24 Sep 2004, Rick Moen wrote:

> Quoting Mark K. Kim (lugod@cbreMAPSak.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.)
>     DEL 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@linuxmafia.com     modern-American-English-usage-improvement association.
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech

Mark K. Kim
AIM: markus kimius
Homepage: http://www.cbreak.org/
Xanga: http://www.xanga.com/vindaci
Friendster: http://www.friendster.com/user.php?uid=13046
PGP key fingerprint: 7324 BACA 53AD E504 A76E  5167 6822 94F0 F298 5DCE
PGP key available on the homepage
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.