July, 2012

  • The Old New Thing

    How your taskbar auto-hide settings can keep getting overwritten

    A customer reported that they were observing that some users were finding their taskbar set to auto-hide even though the standard configuration in the company is for the auto-hide feature to be disabled. Going into Taskbar Properties shows Auto-hide the taskbar checked. None of the users had changed their setting to auto-hide manually, so the question was raised to the Windows team, "Are there any cases where Explorer will set the auto-hide setting on its own?"

    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?

    1. Initially, auto-hide is off.
    2. Program A remembers that auto-hide was off and sets it on.
    3. Program B remembers that auto-hide was on and sets it on.
    4. Program A exits and restores auto-hide to off.

    Oops, now we have a problem: Program B wants auto-hide on, but Program A just turned it off.

    1. Program B exits and restores auto-hide to on.

    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 the box? 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 instead of looking for a local solution to their local problem, in this case creating a fullscreen window that covers the taskbar.

  • The Old New Thing

    The continuing battle between people who offer a service and others who want to hack into the service


    In 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 piggybacking company.) 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 their application. 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.

    Reminder: The ground rules prohibit "trying to guess the identity of a program whose name I did not reveal."

  • The Old New Thing

    You already got your answer, why are you re-asking the question?


    Today's rant is a blend of two earlier rants: People didn't answer your first email for a reason and 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 fishing expedition.

    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 three times, 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 more detail.

    "By what mechanism does SetWidgetColor inform the widget that its color state has changed?"

    The widget receives an OnColorChanged event.

    "By what mechanism does SetWidgetColor inform the widget that its color state has changed?"

    The widget receives an OnColorChanged event.

    "By what mechanism does SetWidgetColor inform the widget that its color state has changed?"

    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 they wanted. They just wanted to know "everything" about widget color changes.

  • The Old New Thing

    Tracking shortcuts and the early history of multiple monitors

    Commenter Roni put two suggestions in the suggestion box in the same entry, which is a problem for me because I feel like I'm forced to answer both of them or neither.

    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 question. 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 question suggestion, so today's entry is more like a clip show. "Remember the first time I talked about multiple monitors?"

    Windows 98 was the first version of Windows to support multiple monitors. (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 multiple monitors, 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 or resolution, because 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. Literally. The maximum number of monitors was increased from nine to ten. Who knows, maybe someday it will go to eleven.

Page 3 of 3 (24 items) 123