[vox-tech] rescuing winxp?

[Rick Moen]

Quoting Peter Jay Salzman (p at dirac.org):

> Apparently, there's a DOS utility called SYS, and doing:
> 
>    SYS C:
> 
> is supposed to restore some crucial boot up files, but when I boot a DOS
> disk, it doesn't seem to know about the hard drive.  I take this to mean that
> DOS doesn't know how to access NTFS.

That is correct.  SYS.COM copies several files (io.sys, command.com,
msdos.sys, and at least one other that I've mercifully forgotten about) 
with the read-only, hidden, and system flags set, to the indicated FAT
filesystem.  One of those gets written to a specific physical location 
so as to be findable by the Int13h boot service, early in the boot
process -- and bootstraps at that point the minimal ability to read the
FAT data structures and find the other files needed for the process, 
leading to the eventual loading of COMMAND.COM.  COMMAND.COM has both a
RAM-resident portion and a transient portion that is re-read from disk
as required, and provides a primitive OS kernel hardwired to a command 
shell.  (You thus are stuck with that shell unless you replace
COMMAND.COM with something like 4DOS.)

A sufficiently high-numbered version of DOS will be able to cope with
FAT32 in addition to FAT16 and FAT12 -- but not NTFS.

"Windows Bestiary" on http://linuxmafia.com/kb/Legacy_Microsoft/
includes a partial field guide to MS-DOS versions 7.0 and up -- the ones
that Microsoft Corp. tried to pretend weren't bundled with MS-Windows
4.x (aka Win9x/ME).

The info. on DOS versions on that page is fragmentary for lack of data
-- sorry.  If people are able to check their Win9x/ME systems and report
the following, it would help complete that table, and I'd be grateful:

o  "ver /r" output (which is the MS-Windows shell version, starting w/4.0)
o  "MSD.EXE" info on MS-DOS version

(Yes, I know that "ver /r" used to report MS-DOS versions.  They
jiggered that starting with Win 4.0, possibly  to distract attention
from MS-DOS's presence.)