Top Left corner of my screen is "dead".

Unless one has the tools and knows hows to program such things ... it's too
easy.

You're shittin' me, right? Who'd'o' ever thunk we was talking about that
arcane feature? I'll be damned ... you'se BRILLIANT!!

Who (other than yourself) said anything about the "Recovery Console" wrt the
current topic?

The OP mentioned not being able to "fix" problems with "XP and above" in
the same manner as with 98 by using the command prompt. The recovery
console is as close as one can get to this functionality without a PE
disk.

First you mock me (as if you actually understood the difference between
"command prompt" and "maintenance OS") and then prove that you actually
don't understand it at all.

Some people like NT *because* of the NTFS, and many users of the NTFS
use Linux's support of that filesystem when making a bootable tools CD.

Damned nice of MS to finally offer the opportunity to create a dual boot
scenario instead of just stomping all over everything on the disk. :o)

If you install XP on a FAT32-formatted drive with DOS already
"installed" on that drive, then during XP installation you can choose to
have a boot menu startup. That way you can boot into DOS to perform any
file or drive maintainence that XP (or malware) would normally block you
from doing. DOS 7.1 is available on the net, and supports long file
names.

The vast majority of people that use any version of Windows do so
because it's what-ever version came pre-installed with their
store-bought or corporate-bought PC / laptop / what-ever. Few of them
know what a file system is, let alone which file system their machine
might have. Fewer still can point to something at the user-level and
claim they couldn't do this or that if the file system was FAT32.

NTFS is proprietary and any compatibility with NTFS while running
third-party boot CD's is still done with microsoft system files.

Try downloading a dvd iso image over 2GB to a fat32 filesystem.

Older versions of fuse ntfs support did require importing the
drivers from the windows system. Current ntfs-3g drivers no
longer use the m$ drivers.

I don't think so. My Linux boot disk can't load PE executables to use
as drivers (.sys files implementing NTFS) which it would need to do if
that were true. It reads and writes NTFS fine on its own. I'd be
surprised to hear that MS provides ELF format NTFS drivers for unix-
like systems.

I think you mean 4gb.

And I generally wouldn't download a 4gb file, regardless what file
system I had. I'd look for downloads that were broken up into smaller
pieces.

Correct. I mistakenly stated the fat16 partition size limit,
rather then the fat32 file size limit.

Correct. I mistakenly stated the fat16 partition size limit,
rather then the fat32 file size limit.

I usually download alpha, or beta versions of Mandriva linux
install iso images about once a month. Takes about a day, on
my slow dsl connection.

How is it possible for Linux to run a Windows kernel mode driver like
ntfs.sys? I accept it could be run in a virtual machine but would need
a complete implementation (or at least a major part) of the kernel in
order to work. Is that the case; i.e, an NTFS disk is mounted inside a
VM?

NTFS support is only a part of the equation. Linux's feature rich
command line blows away Windows' "Recovery Console" subset of NT's
command line. The recovery console was minimalist in nature, while more
recent versions are less so.

This tangent was sparked by the observation / criticism that the file
system on a win-98 machine was more accessible because of being able to
boot into DOS, while XP and other NT-based systems don't have that
ability (at least not natively, or without some hassle to impliment). I
responded by saying that one simply needs to install XP on a
FAT32-formatted drive or volume to have the same accessibility.

Somehow linux crept into the tangent, for reasons that aren't very
clear.

It was the command line available from booting to DOS as opposed that of
the recovery console of XP and above (using a DOS boot disk as opposed
to booting using the recovery console) that was being discussed. Yes,
the filesystem (NTFS) is a major stumbling block to being able to still
use old DOS versions as a maintenance OS on NT machines, but the subset
of commands and directory branch limitations of the recovery console
made people opt for a more feature rich environment for running their
tools. The OP mentioned that by not using NTFS on W2K he could still
"sort of" do what he wanted on W2K with regard to recovery (probably
meaning that he used a DOS boot disk instead of the recovery console
http://support.microsoft.com/kb/229716 , otherwise, the filesystem being
used would not have been an issue).

Not that much of the kernel had to be duplicated. Just a translation
from the linux i/o api to the windows i/o api. See
http://en.wikipedia.org/wiki/Captive_NTFS
It used a read-only native linux ntfs driver to allow the user to get
the ntfs driver from the windows system, and then used a wrapper around
that driver, to enable write support.

The advantage of that version, was that it used the actual ntfs driver
from the windows system, so it didn't matter which version of ntfs
was used on the file system.

It's been replaced by ntfs-3g.
http://en.wikipedia.org/wiki/NTFS-3G
As long as m$ doesn't change the underlying filesystem, like they have
in the past, it should remain the preferred option for rescue cd/dvd
boot options.

There are many linux distributions that include live cds, which are
well suited for use as a rescue cd. In addition to being able to
update files on the ntfs filesystem, they include networking, so
you can browse the net for information, or "good" versions of infected
system files. As always, when booted from something other then the
filesystem being fixed, you don't have to worry about files being
locked.

It's not so much that people desire to use the "old" DOS versions to
access their NTFS volumes.

It's more like people want to use some form of command-line interface to
access those volumes - had Micro$haft bothered to create one in the
first place.

But after 10 - 15 years of not having one, it's clear that Macro$haft's
intention all along was to never provide one. It's part of that "father
knows best" mentality. Microsoft want's to control exactly how you
experience it's products - for your own good (but really - more for it's
own good).

We can't have people running around with a floppy, booting various
NT-based windoze PC's in corporate, military or gov't settings and
having direct file access now can we? What's that you ask? What about
home and soho users? Who cares about them - they'll use what we give
them because we're the only game in town. And they'll learn to like it,
and they'll even claim it's good for them.

Access to NTFS volumes is not the issue, it is the minimalist nature of
the console that makes *other* methods preferable.

I see it used parts of ReactOS for the wrapper. I've previously looked
at the code of ReactOS to get a few clues about the operation of
undocumented Windows functions and have wondered about the purpose of
writing a Windows clone. I now see the point!

Which is effectively a virtual file system.

Very interesting. Thanks for the information.