I agree with you, Bill.  I also have had to go into MS-DOS to fix things that
I could not within the GUI (Graphical User Interface) of Windows even in safe
mode I have been unable to fix everything at different points in time.
Thanks Chris and Bill because I was at a lose for words to explain my
theories to Brian A.

On Sun, 6 Mar 2005 02:48:31 -0700, "Bill in Co."

You can have the best of both worlds; the safety and maintainability
of FATxx with the stability and scalability of XP.  Tips:

1)  Keep C: as a FAT32 < 7.9G

This will ensure 4k clusters, which fit the processor's natural page
size for best virtual memory performance.

There are other goodnesses to a small C:
 - keeping C: de-bulked makes for sustained performance
 - faster defrag and Scandisk / Chkdsk / AutoChk for C:
 - most writes, thus corruption risk,  kept on C: (page/temp/TIF)
 - as data is off C:, it's safer from file corruption

2)  Install a Win9x DOS mode to HD

Easiest way is to format C: /S from a Win9x DOS mode before installing
XP; that way, the XP installation process will preserve the DOS mode
as a "Microsoft Windows" Boot.ini boot alternative.

3)  Use DOS Mode Scandisk, not XP's file system checker

I suspect XP's file system checker is pretty useless on FATxx volumes,
because if you rt-click such volumes and go Properties, Tools, Check
for errors, it zips through the process so quickly that I doubt if it
does anything at all.  I suspect this is where the XP vs. FATxx horror
stories come from; plain lack of decent file system maintenance.

4)  Shrink Temporary Internet Files (TIF) for each user account

FATxx is less efficient than NTFS when it comes to large numbers of
entries per directory - and that's a big problem with IE's ludicrous
huge duhfault TIF size.  Huge TIF also means the tiny files within TIF
get ancient before they are finally FIFO's out; hello, fragmented file
system!  Note that TIF is repeated for each user profile.

5)  Locate shell folders off C:

Now that you have volumes other than C: that are safer for data, you
want to relocate "My Docs" etc. off C:, and I'd also un-nest the bulky
"My Pics", "My Vids" and "My Music" and the dangerous "My Received
Files".  TweakUI for XP can do this, but once again, it has to be
repeated for each user account - and any newly-created user accounts
will start off with MS's duhfault shell locations and huge TIF.

6)  Use a compitent partitioning/formatting tool

XP is worse than useless when it comes to FAT32 volumes over 32G in
size, plus you want all volumes to be aligned such that if you do
convert to NTFS later, you won't be cursed with s-l-o-w 512-byte
clusters.  BING from www.bootitng.com fits the bill on all counts; you
don't need to install it to HD, just use it to manage partitions.

7)  Know the limitations of FATxx!

Choosing FATxx over NTFS is throwing away per-user security as a
tradeoff for better safety.  Many of XP's per-user and per-file
security features require NTFS to work, and if you convert a C: to
NTFS later, the installation will not be set up with the appropriate
NTFS security attributes that would have been in place had you set the
system up as NTFS in the first place.  Also, remember that NTFS is
required if you want single files to exceed 2G in size.

If you don't want to lose the security benefits of NTFS, but want some
measure of maintainability, you can use a hybrid approach; a mixture
of NTFS and FATxx volumes.  For example, you can route all incoming
material through FATxx so that it can be virus-scanned from DOS mode
as a pointer to what may have infected the system.  

You'd need to make decisions about C: as well as your data locations,
as to whether you want NTFS or FATxx for these.  If you see value in
security settings that require NTFS in order to protect the OS, you
may choose an NTFS C:; if you don't mind losing the ability to recover
data via Diskedit etc. and want NTFS's security benefits, you might
choose NTFS for your data set as well.

There's still no interactive file system repair tool (like Scandisk)
for NTFS, but you can formally scan NTFS from a Bart's PE CDR and
Trend's SysClean that you can drop and run from a USB stick.  Both
Bart's PE and Linux boot CDRs require USB sticks to be present at time
of boot, unlike XP which will detect them on the fly.

     "Why do I keep open buckets of petrol next to all the
     ashtrays in the lounge, when I don't even have a car?"

OK, let's chew this one out definitively   ;-)

Viruses are malware than "infect things" (i.e. add thier own code to
existing disks, files or systems) while worms are malware that spread
themselves through networks.  In practice, many auto-spreading malware
exhibit both worm and virus behaviour; these terms should be viewed as
refering to behaviors, rather than as nouns.

The purest code file virus (e.g. CIH) would exist purely as code
within existing code files.  It would spread by infecting other code
files on the system, and then rely on these files being distributed
off the system for the opportunity to infect other systems.

The purest network worm would spread via network packet traffic to
enter and run as an in-memory process, perhaps without ever existing
as a file.  It would send itself out from the hosts it infected, to
seek other hosts via the network, etc.  

Pure worms often never attempt to create files or integrate itself
into the startup axis, so that it's gone after a reboot - but back
again as soon as the server connects to the infected network (and the
Internet is the mother of all infected networks).  This makes sense
when you consider that servers are always running, always connected.

The first pure network worm I heard of was Code Red, which spread as
an in-memory server process via a defect within IIS on NT servers.

Sapphire / Slammer operated in the same way, this time by exploiting a
defect within SQL Server.  Once again, this was an NT Server issue
with little relevance to end users like me and thee, unless we had an
"SQL Lite" on the PC, as could happen as a side-effect of installing
some recent versions of MS Office.  

Sapphire / Slammer set the speed record for malware spread; global
within minutes, and at one point doubling the number of infected
systems every 8 seconds, I think it was.  Daily av updates are no
match for a big-bang Day Zero like this.

Pure network works ceased to be a server-only problem, once XP caused
NT to be rolled out to the masses.  

First, Lovesan / Blaster and a host of similar malware infected NT,
Win2000 and XP via one of a few  defects in the RPC service, which
CANNOT BE DISABLED as NT is structured to rely on this for *internal*
purposes.  This is the reason I consider NT's inherent focus on being
a "network client" as an unavoidable safety risk.  Next, Sasser and
others attacked NT, Win2000 and XP via a defect in the LSASS servive.

In both cases, the defects attacked by these worms had been patched by
MS.  The RPC hole was patched a month before the attacks, and the
LSASS hole was patched 2 weeks before the attacks.  The obvious trend
is that the lead time between patch and attack is falling, but the
hidden part of the iceberg is that these defects were present since
NT4 at least; if they had been elegantly exploited for all those years
by professional operators, we'd never know.

Now at this point, someone is going to say "just turn on XP's
firewall, or add a firewall to any version of Windows".  Which brings
us to Witty, a pure network worm that exploited a defect in a
3rd-party firewall called Black Ice Defender to infect systems.  Witty
had teeth; it tore up data by writing junk to random sectors on the
hard drive, NTFS's notional "security" notwithstanding.

Not all worms are pure, especially when the target is workstations
that are rebooted every day or so.  Such malware is more likely to mix
network spread with persistance across runtimes as files linked into
the system in some way.  This was the case with Nimda, a very complex
critter that makes you dizzy when you try to follow the whole story.

Even when Win9x has RPC/DCOM added to it, the Win9x form of this code
is not succeptable to attacks crafted for NT,e.g. Lovesan etc.  Thus
far, the closest Win9x has to pure network infective attacks are
malware that spread via File and Print Sharing, such as Opaserv;
Opaserv is unique in that this is the *only* way it spreads.

However, Win9x can be knocked over by broken network packets, unless
it is patched for these.  This is the crudest form of DoS (Denial of
Service) attack; there's no infection, or entry of malware code, the
broken packets just cause networking to fail or the PC to crash.

     "Why do I keep open buckets of petrol next to all the
     ashtrays in the lounge, when I don't even have a car?"

On Sun, 6 Mar 2005 13:44:36 -0600, "Brian A."

"As shipped is forever":
 - most folks leave as duhfault
 - most folks don't patch
 - any "just re-install" falls back to as-shipped patch levels
 - any "just wipe and reinstall" falls back to duhfault settings

To this day, there is such a large resourvoir of unpatched PCs
infected with Lovesan etc. and Sasser etc. that an unpatched XP system
with no firewall is attacked within minutes of connecting to the 'net.

Many drive-by consumer hacks start with a RAT that's arrived
accidentally.  A hacker may then search for RATs he can use, find the
RAT's tail on your infected PC, then settle down to chew on it.

If OTOH you are likely to attract the specific attention of hackers,
then you'd more likely to be up to speed with pro-grade security and
have the infrastructure (e.g. solid backups) to match.  In which case,
the security potential of XP is likely to bear fruit.

Assessment as above.

I'm not sure on that - do you have a URL there?  AFAIK, the only
cross-over were things like SDBot.RPC, i.e. malware that added use of
the exploit to other methods of spread.  IOW, a Win9x PC could "catch"
the malware via some other means, spread it via other means, and when
this was spread to NT systems, from there it would spread using the
exploit again.  So yes, in such cases, Win9x PCs add to the pool.

Yes, and that can work very well.  It was SOP where the LAN did not
require Internet access, as was common in a DUN world.

Just as XP hasa built-in firewall that you have to turn on, so it is
with protocol air-gap in Win9x; it's there, but not by duhfault.

By duhfault, Win9x binds everything to everything.  So your LAN
adapter has all 3 network protocols bound to it, your DUN has all
three protocols bound to it, and both have File and Print Sharing
(F&PS) bound to them if F&PS is enabled at all.

You'd fix that by setting DUN to use only TCP/IP and no F&PS, and LAN
to use only IPX and/or NetBEUI with F&PS in place.

When you add XP to such a LAN, problems arise, because (in my
experience) XP cannot do anything other than TCP/IP in such cases.
I've tried IPX, and the hidden-away "unsupported" NetBEUI; no joy.
I've heard that retro-fitting Win2000's NetBEUI may work better, but
the thought of version soup problems puts me off trying that.

Never turn your back on an installer program