Holy cow, I wrote a book!
Explorer does not set the auto-hide checkbox on its own.
Now, the taskbar does auto-hide even when the setting is unchecked
if it detects that the application is trying to go full-screen,
say, in order to show a slide show or
play World of Warcraft.
But that doesn't check the check-box.
Further investigation revealed that
the check-box was being checked programmatically
by one of the programs that the company used.
And it wasn't custom software but a commercial product
which targets the corporate market.
The customer reported back that the problem was sporadic.
They could not reproduce it consistently.
My guess is that the application in question was trying to
enable auto-hide temporarily for whatever reason.
At program startup, it checks the current auto-hide setting,
and if it's off, it programmatically turns auto-hide on.
previousState = IsAutoHideTaskbarEnabled();
When the program exits, it restores the original setting.
This is a highly fragile solution for several reasons:
What if the application crashes before it can restore the setting?
What if two people did this?
Oops, now we have a problem: Program B wants auto-hide on,
but Program A just turned it off.
Oops, the auto-hide setting was left in the 'on' state
after everybody thought they had restored it.
As a special case of What if two people did this?,
the Program B could be the Taskbar Properties page itself.
While your program is running, the user goes to Taskbar Properties
and sees that the checkbox is set incorrectly.
Maybe they go in and "fix it", and now Program A is running
with a visible taskbar.
What if the application tries to restore the state
after Explorer has already saved its settings?
When the user logs off, all processes are told to clean up their toys
and to go bed.
In response to WM_ENDSESSION,
Explorer saves out its settings and calls it a night.
What if this happens before the application programmatically unchecks
Explorer says, "Okay, I unchecked the box."
But Explorer already saved out its settings; these updated settings
aren't going to be saved again.
This is what happens when you expose a global setting programmatically.
People see the setting and think that twiddling it will solve their problem
looking for a local solution to their local problem,
in this case
creating a fullscreen window that covers the taskbar.
the history of the Internet, there have been many cases
of one company providing a service, and others trying to
piggyback off the service through a nonstandard client.
The result is usually a back-and-forth where the provider changes
the interface, the piggybacker reverse-engineers the interface,
back and forth, until one side finally gives up.
Once upon a time, there was one company with a well-known service,
and another company that was piggybacking off it.
(I first heard this story from somebody who worked at the
The back-and-forth continued for several rounds, until the provider
made a change to the interface that ended the game:
They exploited a buffer overflow bug in their own client.
The server sent an intentional buffer overflow to the client,
resulting in the client being pwned by the server.
I'm not sure what happened next, but presumably the server
sent some exploit code to the client and waited for the client to
respond in a manner that confirmed that the exploit had executed.
With that discovery, the people from the piggybacking company gave up.
They weren't going to introduce an intentional security flaw into
The service provider could send not only the exploit but also some
code to detect and disable the rogue client.
By an amazing stroke of good fortune,
I happened to also hear the story of this battle from somebody
who worked at the provider.
He said that they had a lot of fun fighting this particular battle
and particularly enjoyed timing the releases so they caused
maximum inconvenience for their adversaries,
like, for example, 2am on Saturday.
"trying to guess the identity of a program whose name I did not reveal."
Today's rant is a blend of two earlier rants:
People didn't answer your first email for a reason
If you didn't like the answer, asking the same question again is unlikely to help.
A customer submitted a list of questions
(via their customer liaison) to the Widgets discussion list,
and somebody wrote up a reply, which was sent back to the customer.
So far so good.
A few days later, the same list of questions was submitted
to the Gizmo discussion list via a different customer liaison.
Since the question was about Widgets, the question was forwarded
to the Widgets discussion list,
at which point the same answer was forwarded back.
Okay, so now we have a
Three weeks later, the same list of question was submitted
to the Gizmo discussion list via yet another customer liaison.
The fishing expedition continues.
The question was once again forwarded to the Widgets discussion
list, where the same answer was forwarded back.
When I asked why the same set of questions was being asked
the third customer liaison explained,
"The customer is looking for more detail."
Asking the same question over and over again is not a way to get
"By what mechanism does SetWidgetColor inform the widget that its
color state has changed?"
— The widget receives an OnColorChanged event.
— The widget receives an OnColorChanged event.
Why do you keep asking?
"I want more details."
If you want more details,
you have to say that you're asking for more details,
and you have to say
what kind of details you're looking for.
It turns out that this customer didn't even know what kind of details
wanted to know "everything"
about widget color changes.
The first question
suggestion has to do with how shortcuts can find their targets
even if they've been renamed.
This is something I had covered
nearly a year before the question was asked,
so the reason I'm not answering that question isn't that I'm ignoring the
It's that I already answered it.
While I'm at it, here are other questions that I've already answered:
The other question was a series of questions about the history of
multiple monitor support in Windows.
Actually, I think I've already discussed all of the parts of this
so today's entry is more like a
"Remember the first time I talked about multiple monitors?"
Windows 98 was the first version of Windows to support
(Code to support multiple monitors started being written
shortly after Windows 95 was out the door,
so my guess is that the preliminary design work overlapped
the end of the Windows 95 project.)
To facilitate development of code that takes advantage of
the multimon.h header file was introduced
so you could code as if multiple monitor support was present in the
operating system, and it would emulate the multimon APIs
(with a single monitor) if running on Windows 95.
In Windows 98, the maximum number of monitors was nine.
There was no restriction on color depth
the most common configuration involved one powerful graphics card
combined with one really lame one.
When support for multiple monitors was ported to Windows NT,
the Windows NT folks
figured they could one-up the Windows 98 team.
The maximum number of monitors was increased from nine to ten.
maybe someday it will
go to eleven.