cquirke (MVP Windows shell/user) said:
I'm going to read this reaaaly slowly - great content ahead!
...what I refer to as the "namespace object"
...what I refer to as the "file system location"
In XP, the difference was clear - the one would show the object name
and the other would show the directory name. The contents may or may
not look different and the icon would usually look the same (giving
you feedback that that particular location was "special").
In Vista, things get murky because object (rather than directory)
names are often appended at the end of the file system path.
I can't find that in XP SP2 but similar in
HKLM\Software\Microsoft\Windows\Shell etc.
In XP, the equivalent key is:
"HKCU\Software\Microsoft\Windows\ShellNoRoam\BagMRU"
Tell me more about these templates... in the IE4 era, we had
Desktop.ini pointing to *.htt files that allowed HTML scripting to be
bound to locations, in ways amenable to malware use - so that every
full-shared location was potentially a malware drop-and-run point.
When I say template, I'm refering to the choices that appear on the
'Customize' tab: 'All Items', 'Documents', etc. These govern the tasks
offered, default icon style, & default columns selected, etc. Nothing so
advanced as retaining HTML malware
Win98/SE/ME had the ability to kill "View as Web Page" to curb this
risk; a setting that no longer appears in XP and Vista.
Are these newer OSs cluefull enough to suppress "Web Page" scripts, or
dumb enough to integrate these with no option to disable them?
They're suppressed by default in XP, but could be activated:
http://support.microsoft.com/kb/819028/
I doubt they work at all in Vista, but I never really played with them, even
in XP.
Are there other opportunities to edit a Desktop.ini so as to invoke
code; say, via a CLSID? Let's leave aside pointing to a "specially
crafted" .ICO using the .ANI exploit for now.
There was under XP, but it was disabled by default in one of the updates,
but can reactived via a policy setting. Haven't checked under Vista -- I
assume it's at least disabled by default if not completely unavailable.
OK. Is this "CU before LM" order pervasive across all file
associations etc. as lumped together in the HKCR view?
Only items under 'HKCU\Software\Classes' & 'HKLM\SOFTWARE\Classes' merge to
form the HKCR key. User-specific takes precedence over machine-wide, but
'Defaults' uses a Binary data structure to hold the view settings and holds
more specific detail, such as column width, whereas 'FolderTypes' uses
individual values for Icon Style, default columns, etc -- there're not
identical keys/values like:
'HKLM\...\Explorer\HideDesktopIcons'
&
'HKCU\...\Explorer\HideDesktopIcons'
Thanks for a great article, BTW
You're welcome!
