Holy cow, I wrote a book!
a customer had a question about migrating from Windows 2000
to Windows XP.
(That's right, this customer was still using Windows 2000 in the
Specifically, they noted that in Windows 2000,
they can select multiple languages in the
"Language settings for the system" portion of the Regional Options
and they couldn't find the corresponding control panel setting
in Windows XP.
In Windows 2000,
"Language settings for the system" provides the option to install
support (such as code pages, keyboard layouts, and fonts)
In Windows XP,
the big list of language groups was reduced to three
The Basic category is always installed.
To install the Complex or East Asia categories,
use the "Supplemental language support" section of the
Regional and Language Options control panel.
Someday, that customer might upgrade to Windows Vista,
so I may as well answer the question right now.
In Windows Vista and onward,
things were simplified even more:
All language groups are installed at all times.
The dialog box went away completely since there were no options remaining.
As it turns out, the customer's problem had nothing to do
with language support.
Of course, they didn't come out and describe the problem they were
rather, they reduced the problem into multiple pieces,
and then asked for help on one specific piece.
They tried out a solution based on this new information,
but it didn't solve the problem,
because as it turns out,
the Language settings for the system control panel
was a red herring.
If they had told us what their original problem was,
we could have told them
"But this setting will do nothing to solve your problem.
What you really need is over there."
Tomorrow, we'll look at the customer's actual problem.
(So please don't try to guess or you'll ruin the surprise.
I can't believe I had to write that.)
A customer reported that even after uninstalling their application,
the notification icon entry remains in the Notification Area Icons
Yup, that's right.
Explorer remembers the icon, even after the underlying program has
been uninstalled, because you might have uninstalled it with the
intention of immediately reinstalling it,
so Explorer remembers the icon in case it comes back.
But after one week, Explorer gives up and finally forgets about the icon.
"It's been a week, and the user hasn't reinstalled the application.
I'm going to give up waiting for it."
The customer wanted to know how they could remove their icon
immediately upon uninstall.
They reported that having the icon remain in the Notification Area Icons
control panel made it appear that the uninstall was unsuccessful.
There is no documented mechanism for removing the icon
(and the undocumented mechanisms destroy all the icon history,
not just the icon history for your icon, so don't do that either).
You'll just have to wait seven days for the icon to go away.
(One possibility that was considered was to have the
Notification Area Icons control panel check if the application
is still installed before showing it on the list.
This runs into problems, though, if the application resides on the
network or removable media.
It means that opening the Notification Area Icons control panel
can stall on network I/O,
generate security audits if you lost access to the network share,
and spin up external media.
Remember how much people hated it when Windows 95 spun up your
CD-ROM drive the first time you clicked on the address bar?)
If you type SysFader into your favorite search engine,
you'll find lots of hits from people asking,
"What is SysFader, and why is it always crashing Internet Explorer?"
When a program encounters a fatal error, the system crash
And it needs to put somebody's name in the title of the dialog
to indicate which application crashed.
it has the process name (iexplore.exe),
but it has this nagging feeling that it can do better.
After all, not everybody will know that
"AcroRd32.exe" is "The menu for my favorite restaurant that
I was looking at in Adobe Acrobat Reader".
So it goes looking for a window that belongs to the thread
so it can steal the window's title and use that to help
the user understand what it was that crashed.
And if can't find any visible windows, it will go for invisible ones,
on the theory that, "Well maybe the application crashed before
it could show the window."
Now let's see what happens when we apply this logic to SysFader.
SysFader is a helper window used by Internet Explorer to perform
It really doesn't do much, but it is a window,
albeit an invisible one when there are no animations in progress.
SysFader happens to run on a shared worker thread.
If that worker thread is being borrowed by some other background
and that background task crashes,
then when the crash dialog appears and looks around for a window
to put in the title,
it says "Rats, I don't have any visible windows,
but I do have this invisible one,
so I'll go ahead and put that one in the title bar.
Better than nothing."
It's sort of the error-reporting version of the
It's like your photo appearing in a newspaper article headlined
Robbery at Woodgrove Bank, Suspect At Large,
not because you're the suspect, but because you happen to have been
in the building at the time of the robbery.
You probably recognize the exception code as
an unhandled C++ exception.
Internet Explorer doesn't use C++ exceptions, so the exception
most likely came from a plug-in.
[Raymond is currently away; this message was pre-recorded.]
A customer reported an issue with the title
"The notification balloon for Low Disk Space does not appear
even if the free disk is very low."
They provided the following steps:
You read through the steps nodding,
"uh huh, uh huh", and then you get to the last step and you say,
"Wait a second, the subject of your report was that the balloon
doesn't appear at all, and now you're saying that it appears
after ten minutes.
So it does appear after all.
What is the problem?"
The customer explained that on earlier versions of Windows,
the Low Disk Space warning balloon appeared within one minute,
whereas in Windows 7 it can take up to ten minutes for the
balloon to appear.
Yup, that's right.
In previous versions of Windows, Explorer checked for low disk space
once a minute.
The Windows performance folks requested that the shell reduce the
frequency of checks to improve overall system performance,
and the shell team agreed to reduce the frequency to once every
(The performance team made other suggestions to reduce the impact of
that code that runs every ten minutes.)
So yes, in Windows 7, it may take up to ten minutes for
Explorer to report that you are low on disk space.
But Explorer never promised that those reports would be timely.
Or that they would even appear in the first place.
The behavior is not contractual;
it's just a courtesy notification.
How full does a hard drive have to get
before Explorer will start getting concerned?
How do I disable the low disk space notifications?
Some time back, I provided
regarding what types of files go into which folders.
Here are the official guidelines [pdf],
for those looking for something with more authority than just me
Ian Boyd wants to know
why the specific value of 500ms was chosen as the edit delay
in Windows Explorer.
Because it's your double-click time.
Since the double-click action (execute)
is not an extension of the single-click action (edit),
Explorer (and more generally, list view)
waits for the double-click timeout before entering edit mode
so it can tell whether that first click was really a single-click on its own
or a single-click on the way to a double-click.
If the timeout were shorter than the double-click time, then
double-clicking an item would end up having the first click trigger
edit mode and the second click selecting text inside the editor.
(If the timeout were longer, then everything would still work,
but you would just have to wait longer.)
"Through my testing it does not appear linked to configurable
My guess is that Ian changed the double-click timeout not by
but by whacking a registry value directly.
The values in the registry are loaded and cached at logon;
you can update them all you want at runtime, nobody will care.
A customer reported some inconsistency in how folder customizations
are handled by roaming profiles.
Why doesn't the C:\Temp customization roam?
Well, if you think about it, it makes sense that the
setting for C:\Temp doesn't roam
because C:\Temp doesn't roam either!
The C:\Temp on Server1 is not the same directory
the C:\Temp on Server2.
Let's change Step 2 slightly:
I think nobody would be surprised at the results of this second
The changes to Library\Documents are there because that folder
is part of your roaming profile.
The changes to \\server\share are there because
it is a global resource.
And the changes to C:\Temp are not there because
the first one is "C:\Temp on Server1" and the second is
"C:\Temp on Server2".
The shell saves icon size customizations in folders differently
based on whether it is a global resource (like a network share)
or a local resource (available only on the local machine).
Settings for local resources do not roam because, well, they're local
and have no meaning when roamed to another computer.
The Documents case manages to get the desired effect, but by different
Settings for libraries are based on how you customized the view
via things like the "Arrange by" menu.
Those customizations are saved in your roaming profile,
and they therefore roam with you.
reported a problem that occurred only when they
installed a particular application.
If they uninstalled it, then the problem went away.
After installing the application, the "Run As" context menu
option stopped working.
The customer didn't provide any other details,
but we were able to make an educated guess as to what was going on.
A common programming error in context menu extensions occurs in
extensions which add only one menu item.
These extensions ignore the parameters to the
IContextMenu::InvokeCommand and simply assume that
the only reason the method can be called is if the user selected
their menu item.
After all, if you have only one invokable item, there's no need
to figure out which one the user selected, because you have only
one to begin with!
The problem is that a context menu extension can be invoked
not because the user selected an item under its control
but because a verb is
being invoked programmatically,
and each handler is being asked,
"Do you know how to do this?"
The result is that the context menu host calls the extension to say,
"If you know how to do runas, then please do so,"
and the the extension says
"Sure, we do that" and starts doing its thing.
If you are unlucky and the grabby extension is asked the question
before the actual runas extension,
the runas command winds up being hijacked by the grabby
(This is the same mistake that causes
the Copy To and Move To commands to behave strangely if you add
them to the context menu:
They assume that the only reason they are invoked is that the user
invoked their command, because they weren't designed to be hosted
by context menus to begin with!
They were designed to go into the toolbar, and the toolbar hosting
code never invoked commands by name.
It's like taking a ladder and using it as a bridge between two tall
Sure, you can now cross from one building to another,
but you also run a serious risk of falling to your death.)
A variation on the initial problem is
"I found that after installing a particular program, I can't
run anything from the Start menu."
I know of at least two programs which install
context menu extensions which steal the "open" command
This problem is sufficiently prevalent that there is a
special compatibility flag that can be set on a shell extension
"This is a grabby shell extension that steals commands.
Never ask it if it supports anything, because it will
always say yes!"
Notice that the "MoveTo CopyTo Context Menu" is on the list,
which I find interesting because MoveTo/CopyTo was never meant
to go on the context menu in the first place.
Going back to our analogy, it'd be as if the ladder company
issued a safety bulletin to warn people of problems
that can occur if you use it as a bridge between two tall buildings!
In Windows Vista and Windows Server 2008,
if you go to a the advanced security settings for a directory
and uncheck "include inheritable permissions from this
then go back to the Sharing tab,
you'll find that the "Share" button is disabled.
Why is this?
We don't see this behavior on Windows 7 or
Windows Server 2008 R2.
(Yes, a customer actually noticed and asked the question.)
The sharing wizard in
Windows Vista and Windows Server 2008 does not support
folders with the SE_DACL_PROTECTED
security descriptor control bit
because it isn't sure that it can restore the ACL afterward.
And as the customer noted, this restriction was lifted in
Windows 7 and Windows Server 2008 R2.
This information is accurate as of Windows 7;
the algorithm may change for future versions of Windows.
The information is being provided for the edification of computer
network administrators, who are curious about random stuff like this
since it can affect their network load.
When you hover over a folder, Explorer shows an infotip (a special
type of tooltip) which contains information about the directory,
and the information that concerns network administrators is the
How does Explorer calculate the size?
Explorer calculates the size by performing a naïve recursive listing
of the directory and adding up the sizes of all the files it finds.
If the enumeration takes longer than three seconds, then Explorer
gives up after three seconds and reports the size as "larger than X"
where X was the size it managed to calculate so far.
If you don't want Explorer to do this calculation, you can disable
it from the Folder Options control panel
by unchecking the box labeled
Display file size information in folder tips.