🚀 go-pugleaf

john.will@satalink.com (John Will) writes:

>TO: Internet: wkeown@ducvax.auburn.edu
>WR.After exposing the hidden files, I de-fragmented my hard drive.  My computer
>  .would not reboot after the de-fragmenter moved the files.  I had to reformat
>  .the hard drive to install the system files before it would reboot.

>Later versions of DOS aren't nearly as picky about where the files are,
>I installed DOS 5 over an earlier version, and the system files were 
>fragmented and not the first files on the disk.  I used DOG, a shareware
>disk optimizer to move them first, then re-enabled their attributes,
>I boot fine.  It booted before I moved them, I'm just a perfectionist. :-)

As of DOS 5, there are only two rules which must be observed in the placement
of the two hidden system files:

(1) - The two files (IO.SYS and MSDOS.SYS for MS-DOS systems; IBMBIO.COM
      and IBMDOS.COM for PC-DOS) must be represented by entries in the
      first two slots of the root directory on the boot drive, in that
      order.

(2) - IO.SYS (or IBMBIO.COM) must occupy a single contiguous block of
      disk space, and must be stored on the disk in serial fashion (meaning
      that the lowest-numbered sector contains the fist 512 bytes, the
      next-higher sector contains the next 512 bytes, and so on until
      the file size (as recorded in the directory entry) is satisfied.

There is no longer a requirement that the files be located at the front
of the user area on the disk, and MSDOS.SYS (or IBMDOS.COM) may be 
stored in fragmented, noncontiguous disk sectors.

The reason for the remaining requirements is that IO.SYS (IBMBIO.COM) must
be read into memory by the boot sector program.  This program must fit
into no more than roughly 450 bytes (512 bytes minus the size of the boot
parameter block), so there is no room for code to search the directory
for the file's entry, and no room for code to chase a string of FAT
references as the file is read.

The boot program locates the IO.SYS entry in the directory, translates the
cluster number it points to into an absolute sector number (after applying
if necessary a correction for the starting address of a fixed disk
partition), and then blindly reads sectors beginning at that location
into memory until it has read enough 512-byte sectors to cover the size
of the file specified in the directory.

An easy way to make a disk nonbootable is to have some defragmenter program
"optimize" the root directory by sorting the entries.  If it does not
exclude the two magic files from the sort these files will be moved
elsewhere in the directory, and the first requirement noted above is
violated.

Somewhere in the string of DOS versions the loading of MSDOS.SYS was
relocated to a point after the DOS file system interface was available;
this is why MSDOS.SYS may be fragmented.  Or at least this explanation
is consistent with what I've seen; I have no access to the source for
DOS...unfortunately.

Joe Morris