November, 2010

  • The Old New Thing

    The quiet fading away of the CtlPanelClass

    • 23 Comments

    If you search MSDN for CtlPanelClass, you'll find a few really old Knowledge Base articles that include it in a list of "class names of common Windows applications." I'm not sure why the Knowledge Base articles bothered to list those classes; there is no technical reason for applications to need to know this, and including the information merely encourages programmers to rely on the window class name in strange undocumented ways. (This is another one of those cases where a Knowledge Base article written to assist in troubleshooting becomes interpreted as formal documentation.)

    Windows Vista finally got rid of that window class. It took only ten years.

    The window class was used by the old Windows 3.1 Control Panel application. Back in Windows 3.1, the Control Panel was a standalone application and was not integrated into the shell namespace (in large part because there was no such thing as a shell namespace back then for it to be a part of).

    There was one program which not only searched for a window of that specific class name, but it also sent the window WM_COMMAND messages, since of course it knew what the menu IDs were for the Control Panel application, and it knew that the Windows developers would never change the IDs or replace the standalone Control Panel application with anything else.

    When the standalone Control Panel application was converted to a virtual folder, it also came with some decoys in order to maintain compatibility with older programs that relied on the old behavior in strange undocumented ways.

    One of those decoys, the CtlPanelClass was removed for Windows Vista. A crash was traced back to a bug in the decoy window which manifested itself if a control panel took more than ten seconds to launch itself. To fix the bug, we just removed the decoy window, but we were prepared to write a compatibility shim in case there were people still running that ancient application from 1993. We didn't actually turn the compatibility shim on, but we were ready just in case.

    We removed the decoy and crossed our fingers.

    We got lucky. Nobody noticed.

  • The Old New Thing

    The wisdom of seventh graders: Being President

    • 28 Comments

    Today is Election Day in the United States. Some years ago, seventh grade students (age 12) were asked to imagine they had just been elected president and to give an address to the nation on one thing they would change.

    Remember, these are only the most entertaining ideas. Do not assume all student ideas are like these.

    • Ban "all types of non-purpose car racing."
    • Defend against zombie attack.
    • Withdraw from Iraq and use the money to fund electric cars and ban smoking.
    • Repeal all taxes.
    • Name Arnold Schwarzenegger as Vice President.
    • Shorten all school days to increase learning.
    • Build a holographic wall at the border. For the immigrants who don't fall for it and run right through, station border patrol just behind it.
    • Shut down all cigarette factories. "If you somehow manage to get cigarettes, we don't care."
    • Make chocolate milk the official drink.

    And this sentence came from a student destined for greatness as a politician: "Something must be done, and I will make it happen."

  • The Old New Thing

    Saying that your case is different doesn't make it so

    • 24 Comments

    A customer wanted to do one of those user-hostile things that Windows doesn't make easy to do (the sort of thing I tend to call out on this Web site). After receiving an explanation that Windows doesn't provide a way of doing what they want because it abuses the component in question and goes against user expectations, the customer countered, "Yes, we understand that, but our case is different."

    The customer then proceeded to explain how they intended to use this newfound power (if only they could figure out how to do it) and under what circumstances they intend to invoke it. Their explanation was interesting in that the description could be applied to any other program on the planet.

    Yes, we understand that, but our case is different. We would do this only after the user installs the program or reconfigures it from the Add or Remove Programs control panel. After a few days, we would stop doing it, unless triggered by a reinstall or a reconfiguration.

    So far, there's nothing here that explains why your program should be able to do this, but not, say, Photoshop. There is no evidence that this program is any different from the tens of thousands of other programs out there, many of which probably want to do that very same thing this program wants to do.

    Just because you say that your case is different doesn't make it so.

  • The Old New Thing

    Why doesn't the End Task button end my task immediately?

    • 64 Comments

    Commenter littleguru asks, "Why does the End Now button not kill the process immediately?"

    When you click the End Now button, the process really does end now, but not before a brief message from our sponsor.

    When you kill a hung application, Windows Error Reporting steps in to record the state of the hung application so it can be submitted to the mother ship (with your permission). If you are running Windows XP or Windows Vista, you can briefly see a process called dumprep.exe or WerFault.exe; these are the guys who are doing the data collection.

    After being uploaded to Microsoft, these failure reports are studied to determine why the application stopped responding and what could be done to fix it. I've been asked to do quite a few of these analyses myself, and sometimes it's something pretty mundane (an application sends a cross-thread message while holding a critical section, and the thread can't receive the message because it's stuck waiting for the critical section that the sender is holding—classic deadlock), and sometimes it's something pretty weird (application has a bug if the number of sound output devices is not equal to one). Whatever the reason, I write up my analysis, and the people who are in charge of such things make arrangements for the information to be sent back to the vendors who wrote the application (assuming the vendors are registered with Winqual).

    If you don't want Windows Error Reporting to collect application crash and hang reports, you can disable it from the Group Policy Editor under Windows Error Reporting. Of course, if you do this, then you don't get to vote on which program crashes and failures Microsoft should work on fixing.

    Note: This entry is an experiment: I mentioned Windows Error Reporting and WHQL. If people complain about digital certificate authorities, that'll just confirm my bias against returning to those old debugging stories.

    Update: Experimental results obtained. No more stories involving Windows Error Reporting and WHQL.

Page 3 of 3 (24 items) 123