I found this: http://support.microsoft.com/default.aspx?scid=kb;en-us;66530
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 guess. -Mark On Fri, 24 Sep 2004, Rick Moen wrote: > Quoting Mark K. Kim ([EMAIL PROTECTED]): > > > 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, > [EMAIL PROTECTED] modern-American-English-usage-improvement association. > _______________________________________________ > vox-tech mailing list > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
