Often it's unsafe to operate Windows for various reasons:
In these situations, you need a maintenance Operating System (mOS). The tasks you'd use this for would fall into these broad categories:
The hallmarks of a mOS is that it does not automatically write to the hard drive, does not depend on hard drive contents to be sane, does not run any code from the hard drive whatsoever, allows direct access to hardware, and ideally requires only a small subset of hardware to work perfectly.
The traditional mOS for Windows 9x has been DOS mode, but this is no longer up to the task in the XP era:
So while one can keep XP within reach of DOS mode maintainability by avoiding NTFS, hard drives over 137G etc., XP really needs a new mOS!
Depending on whether you use the home or identity-based security model, you may need to limit or suppress access from a mOS. The question then arises as how to do this:
XP Home is intended for stand-alone consumers accustomed to the "home" security model, so the mOS should default to running unless locked out by some sort of HD content; in fact, as malware can spoof this, I'd prefer to see XP Home as always accessible via mOS.
XP Pro is intended for business use, where it may be preferable to lose maintainability if it removes the physical access hacking risk that a mOS might pose. If the HD is inspected for content that will lock out the mOS if present, then the risk of being locked out due to hard drive corruption is smaller than if particular content was required to allow mOS access.
As at July 2004, these include:
This would be the obvious choice, but Microsoft's licensing terms make this available to so few users (basically, only large PC factories) that it's unlikely software vendors will develop tools to run on it. Even as a DSP (Delivery Service Partner, i.e. small-volume PC builder) and MSDN subscriber, I do not have access to this tool, and so it goes for most field techs who would be the market for data recovery and anti-malware utilities that need a mOS.
This is a 3rd-party utility that creates a bootable XP CDR, and it's free for download (requiring your XP installation CD-ROM to build the boot CDR). In the absence of an offering from Microsoft, this could become the de facto mOS standard, but it remains to be seen whether software vendors will write for a quasi-OS platform that exists outside Microsoft's fence.
Some Windows programs already run within Bart's PE, as long as a suitable plug-in wrapper is used. This topic is covered at Bart's site.
Unlike NT, Linux can already function as its own mOS, with boot disks ranging from diskettes (such as that used to host MemTest86) through USB flash drives to CDRs. Some Linux distros are tailored for this, e.g. Knoppix (a CDR-based Debian Linux). However, even Linux advocates are skeptical about the safety of writing to NTFS via reverse-engineered drivers.
There's been some progress there, though, and now BitDefender Live - available as one large download - comes close to a turnkey solution by fusing these three initiatives:
The process of getting up and running with this involves:
I tested BitDefender Live CDR on various i865G systems I was building, and found it detected my generic (Chronos) digital camera as a drive if it was plugged into the USB before boot. I would store Microsoft's NTFS driver files and BitDefender's antivirus updates there, and direct the CDR-booted antivirus to these before use.
I'd avoid letting the process discover the NTFS drivers on the infected PC's hard drive as that undermines the formality of the scan, and as a safety precaution, I'd keep the USB stick (or in my case, the camera's SD memory card) write-protected.
There's something deeply ironic about having to learn Linux in order to salvage and maintain NT, but there you are.
NT (including Win2000 and XP) does not contain DOS or a DOS mode, but you can use one from a Win9x OS or download a free DOS from www.bootdisk.com.
If you avoided NTFS, you can use DOS mode as-is to formally scan for viruses and clean them, delete or rename-away files, or copy off data. But DOS mode doesn't support Long File Names (LFNs), so you will need 3rd-party tools if you wish to preserve these.
There are two free TSR drivers that allow Command.com and other LFN-aware "DOS" programs to support LFNs. One is fatally flawed in a nasty way; it creates the same (non-unique) 8.3 name under LFNs that match the first 8.3-legal 6 characters and extension, without incrementing the ~n index before the extension. The other one seems to work OK.
However, I find free Odi's LFN Tools to be more useful. These are a set of non-TSR external commands that replace Command.com's internal file management commands with LFN-aware alternatives, such as LMD, LDel, LRen, LDir, LCopy etc. LCopy is particularly powerful, as it can copy over an entire volume via syntax such as...
LCopy D:\* C:\BadHD /A /S
There are free and fee TSR drivers that enable DOS mode to read NTFS, available from the www.systeminternals.com web site. However, these don't support LFNs, and won't work with add-on TSR LFN drivers or Odi's LFN Tools, which would otherwise allow LFN preservation in DOS mode.
The free TSR takes up around 300k of conventional DOS memory (i.e. double that used by the old DriveSpace 3 compression support), which doesn't leave much room to run anything else. F-Prot for DOS can run under these conditions, but will fail to scan entire NTFS volumes as the NTFS driver fails to recurse the full directory tree properly. In any case, the free NTFS driver is read only, so a DOS antivirus would be unable to clean anything.
The fee TSR takes a different approach by acting as a wrapper for the hard drive installation's own NTFS code. This may improve the depth and version-compatibility of NTFS support, but also means that corruption or infection of the relevant hard drive code can pose problems.
One can use a free non-TSR utility from www.NTFS.com to view and copy off subtrees from NTFS volumes under DOS mode, though once again, LFNs will be lost. ReadNTFS takes a while to scan each directory and has to rescan these anew if you retrace your steps; you can't select multiple items to copy off, but you can select a directory and it will copy everything that contains.
The Recovery Console can be booted from any complete, non-OEM-crippled XP CD-ROM. It is a useful grab-bag of canned fixes for several problems, but it is not an OS; you cannot run external programs from it at all. Unless you have set certain registry values in advance, it cannot see volumes other than C: and cannot copy anything from C: to some other disk; even if you do set the relevant values, it cannot copy via wildcards such as *.*
In addition, it has to recognize a viable XP installation on the hard disk, and match that installation's (typically nul) password before you can do anything.
These limitations make Recovery Console useless for detecting malware, and tedious for managing malware identified via some other method. For data recovery, it ranges from totally useless to very tedious; at best, you can use it to copy individual files by name, one at a time. Unlike ReadNTFS, it cannot copy off entire subtrees.
If NT advocates think Recovery Console is an adequate successor to DOS mode as a post-FATxx mOS, they are living in a dream world.
(C) Chris Quirke, all rights reserved - April 2004, updated July 2004