May, 2012

  • The Old New Thing

    Why are the Windows 7 system notification icons colorless?


    Mike wondered why the system notification icons went colorless in Windows 7 and why they went back to regular tooltips instead of the custom tooltips.

    I don't know either, so I asked Larry Osterman, who was in charge of the Volume icon.

    And he didn't know either. He was merely given new icons by the design team.

    But that doesn't stop me from guessing. (Which is what I do most of the time here, I just don't explicitly say that I'm guessing.)

    My guess is that the design team looked at the new Windows 7 taskbar and noticed that all the system-provided pieces were subdued and unobtrusive, with two exceptions: The Start button itself and the notification icons. The Start button kept its bright colors because, well, it's the Start button. But the notification icons? They are peripheral elements; why do they stand out on an otherwise neutral-looking taskbar? Isn't that just drawing the user's attention to something that doesn't deserve attention?

    So boom, make them monochromatic to fit with the other taskbar elements. The clock is monochromatic. The Show Desktop button is monochromatic. The taskbar itself is monochromatic. Hooray, aesthetic unity is restored.

    As for the return to standard tooltips, that's easy: The custom tooltip was a violation of the user interface guidelines.

    The old Windows Vista custom tooltip did not provide any useful information beyond the standard tooltip, so you paid the cost of developing and maintaining a custom tooltip for very little benefit. In the volume tooltip's case, the developers were spending effort fixing little bugs here and there (for example, there were painting glitches under certain accessibility conditions), effort that was detracting from other work that could be done, and switching to the standard tooltip made all the problems go away.

  • The Old New Thing

    How does the MultiByteToWideChar function treat invalid characters?


    The MB_ERR_INVALID_CHARS flag controls how the Multi­Byte­To­Wide­Char function treats invalid characters. Some people claim that the following sentences in the documentation are contradictory:

    • "Starting with Windows Vista, the function does not drop illegal code points if the application does not set the flag."
    • "Windows XP: If this flag is not set, the function silently drops illegal code points."
    • "The function fails if MB_ERR_INVALID_CHARS is set and an invalid character is encountered in the source string."

    Actually, the three sentences are talking about different cases. The first two talk about what happens if you omit the flag; the third talks about what happens if you include the flag.

    Since people seem to like tables, here's a description of the MB_ERR_INVALID_CHARS flag in tabular form:

    MB_ERR_INVALID_CHARS set? Operating system Treatment of invalid character
    Yes Any Function fails
    No XP and earlier Character is dropped
    Vista and later Character is not dropped

    Here's a sample program that illustrates the possibilities:

    #include <windows.h>
    #include <ole2.h>
    #include <windowsx.h>
    #include <commctrl.h>
    #include <strsafe.h>
    #include <uxtheme.h>
    void MB2WCTest(DWORD flags)
     WCHAR szOut[256];
     int cch = MultiByteToWideChar(CP_UTF8, flags,
                                   "\xC0\x41\x42", 3, szOut, 256);
     printf("Called with flags %d\n", flags);
     printf("Return value is %d\n", cch);
     for (int i = 0; i < cch; i++) {
      printf("value[%d] = %d\n", i, szOut[i]);
    int __cdecl main(int argc, char **argv)
     return 0;

    If you run this on Windows XP, you get

    Called with flags 0
    Return value is 2
    Value[0] = 65
    Value[1] = 66
    Called with flags 8
    Return value is 0

    This demonstrates that passing the MB_ERR_INVALID_CHARS flag causes the function to fail, and omitting it causes the invalid character \xC0 to be dropped.

    If you run this on Windows Vista, you get

    Called with flags 0
    Return value is 3
    Value[0] = 65533
    Value[1] = 65
    Value[2] = 66
    Called with flags 8
    Return value is 0

    This demonstrates again that passing the MB_ERR_INVALID_CHARS flag causes the function to fail, but this time, if you omit the flag, the invalid character \xC0 is converted to U+FFFD, which is REPLACEMENT CHARACTER. (Note that it does not appear to be documented precisely what happens to invalid characters, aside from the fact that they are not dropped. Perhaps code pages other than CP_UTF8 convert them to some other default character.)

  • The Old New Thing

    How does Explorer calculate the folder size information in the folder tooltip?


    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 "Size". 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.

  • The Old New Thing

    Why is there sometimes a long delay between pressing a hotkey for a shortcut and opening the shortcut?


    Via a customer liaison, we received a problem report from a customer.

    The customer is facing issues with delayed desponses to opening a .lnk file by pressing its keyboard shortcut hotkey. This delay does not appear when the shortcut is double-clicked.

    For example, the customer has created a shortcut to Notepad and assigned it the shortcut Ctrl+Alt+X. Pressing the keyboard combination sometimes takes 5 or 6 seconds for Notepad to open. As noted above, double-clicking on the shortcut causes Notepad to open without delay.

    This issue is not consistently reproducible, but it appears to be independent of the shortcut file itself. Any shortcut with a hotkey exhibits this problem.

    All the shortcuts in question are on the desktop.

    The short answer is "There is a program running on your machine that occasionally stops responding to messages. If you press a shortcut hotkey during those moments, you will experience this problem. Identify the program that stops responding to messages and fix it."

    Okay, that sort of cuts to the chase, but the interesting part is the journey, not the destination.

    First, observe that if you associate a hotkey with a shortcut to say Notepad, and you press the hotkey twice, you do not get two copies of Notepad. The first time you press the hotkey, Notepad launches, but the second time you press the hotkey, focus is put on the existing copy of Notepad. This is one of those things that's so natural you may not even realize that it's happening.

    When you press the hotkey assigned to a shortcut, Explorer receives the hotkey and needs to decide what to do about it. Before it can launch the shortcut, it needs to see if the shortcut target already has a window open, in which case it should just switch to that window.

    Finding out whether a window has a hotkey is done by sending the window the WM_GETHOTKEY message. When you press a hotkey that is assigned to a shortcut, Explorer goes to all the windows already on the screen and asks each one, "Hey, what's your hotkey?" If any window says, "My hotkey is Ctrl+Alt+X," then Explorer says, "Oh, sorry to step on your toes. The user pressed your hotkey, so here, go ahead and take focus."

    If no window cops to having Ctrl+Alt+X as its hotkey, Explorer says, "Okay, well, then I guess I have to make one." It launches Notepad and tells it, "Oh, and your hotkey is Ctrl+Alt+X."

    If there is a window that is not responding to messages, then when Explorer asks it, "Hey, what's your hotkey?", the window just sits there and doesn't answer. After about three seconds, Explorer gives up. "Yeesh, I was just asking a question. Don't have to give me the silent treatment."

    And that petulant window is the source of the 3-second delay. It takes Explorer 3 seconds before it finally gives up and says, "Forget it. Even if that was somebody's hotkey, they're being a jerk, so I'm just going to pretend they didn't have a hotkey. Let me open a new window instead and just deal with the hotkey conflict."

  • The Old New Thing

    What happened to the Summary information created on Windows 2000 and Windows XP?


    In Windows 2000 and Windows XP, you could add Summary information on the Details property page to files of all types. Text files, image files, some crazy file your grandmother sent you in a file format you don't know how to open. If Windows supports storing the Summary information in the file itself (for example, in EXIF tags or in Structure Storage properties), then the information gets stored there. Otherwise, Windows stashes the information in an alternate data stream. Windows Vista dropped support for storing Summary information in alternate data streams. What happened?

    Support for storing Summary information in an alternate data stream was dropped in Windows Vista because alternate data streams were found to be too fragile. If you back up the file to a CD-ROM or email it to a friend or copy it to a thumb drive or upload it to a Web site or store it in a ZIP file, the alternate data stream ends up lost. It was determined that it was better simple not to allow users to create data that was so easy to destroy accidentally.

Page 3 of 3 (25 items) 123