On Tue, 20 Apr 2004 14:58:08 +0530, "Ramesh [MVP]"
Good idea, another difficulty here is the inconsistent naming conventions followed.
It may be Qnnnnnn or KBnnnnnn sometimes. Another instance :
"C:\windows\$NtUninstallKB823980_RTM$" referenced in the registry as:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\KB823980
and not
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\KB823980_RTM$
OK... tho I guess the uninstaller has to tie these together. At this
point one is tempted to wave the %variable% notion about ;-)
Therefore, reading the folders programatically and mapping them to it's registry key
(or Vice-Versa) might prove erroneous sometimes.
Is a patch-specific uninstaller or uninstall script, then - else the
same uninstall logic would be expected to have the same problem?
Patch naming conventions are a biggie, especially where different
patch .EXE for different OSs have exactly the same file name. There's
value in 8.3 conformity, which restricts you to (now that patches are
monthly) something like AAyymmii.EXE where ii is an index number.
Ideally, any .EXE patch should start off with a self-documenting
dialog, stating what OS or product it's for, what the threshold and
not-needed versions are, and perhaps a "more info" button that pulls
up the /kb article. Resist the temptation to link that to a web site;
ASCII (even Unicode) is cheap, stick it inside
Beyond that, the challenge is to have a way of authenticating the
patch is genuine and unmodified. "Unmodified" is easy, but "genuine"
(i.e. not a malware look-alike) is less so.
With all of those ducks in place, patch re-distribution and
re-usability (important in DUN, offline/production/predelivery or
dare-not-connect situations) just got a whole lot better!
Yup. That's a great idea as well.
If I could add one "shell folder", it would be "Suspect". All
downloads, archive workspace, IM and email attachments etc. would go
there and you could point a tiered layer of on-demand av at it (.bat,
QuickLaunch and Start /W are your friends)
This is in fact what I've been doing since Win95 now, and NTFS
issues/opportunities potentially add value to the concept. For
example, locating this in FATxx space means it can be scanned from a
DOS-based AV without running ?infected Windows; even if you can't
catch the active malware that way, you could get pointers towards what
you may be dealing with and do some research for caveats.
As it is, MS's shell folder approach has no clue that incoming
material really should NOT be dumped into the data and backup space.
MS even recommends dumping arb .EXE (e.g. downloaded self-installing
archives) in the data set to stop SR fiddling with them <grr>
Potential result (as I've seen ITW):
- unexplained catastrophic file system corruption
- rebuild software, restore data backup
- malware restored along with the data
- repeat and fade
-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
