February, 2007

  • The Old New Thing

    Technology hypochondriacs


    One phenomenon I've noticed quite a bit is something I'm going to call "technology hypochondria", the belief that you are suffering from whatever problem you just read about. It reminds me of this joke:

    A man goes to his doctor. "Doctor," he says, "I'm pretty sure I've got this disease here. All the symptoms match. I'm suffering from fatigue, sleeplessness, irritability, and memory loss."

    "Mr. Jenkins," the doctor responds, "I'm fairly certain you aren't suffering from menopause."

    One of my relatives who is a medical doctor in a public hospital explained to me that in his experience, you should never trust the diagnosis of a med student. "When we bring them along on rounds and show them a patient and ask them what they think the problem might be, they always answer with the disease they just studied last week."

    When I describe one way a program can become unresponsive, that doesn't necessarily mean that that's why your program is unresponsive. A program can become unresponsive for any of a million reasons, most of which have the same basic symptoms: "When I click on the program, nothing happens." That's really not enough information from which to make a diagnosis. To make a diagnosis, you need to whack a debugger under the program and see why the UI thread isn't processing messages. (Mark Russinovich did exactly that to investigate a process startup delay he was experiencing, and the cause in his case was something I hadn't seen before.)

    If you post a comment to one of my articles asking, "Could this be why my program also has a similar problem?", don't expect much of an answer from me. It's like writing a letter to a newspaper's medical advice column saying, "I'm suffering from fatigue and loss of appetite. Do I have AIDS?"

  • The Old New Thing

    Email tip: Barry Leiba expounds on subject lines


    Barry Leiba extends my previous remarks on choosing meaningful subject lines with his own contribution to the cause. Of particular interest is his note on how to choose a subject line for meeting requests.

  • The Old New Thing

    Email tip: Don't add people to a thread without saying why


    If you add me to an existing discussion, you have to say why. Do you have a specific question for me? Do you want my opinion on something? Are you just sharing a funny joke?

    Sometimes, I'll get a piece of mail that goes like this:

    From: Xxxxx
    To: Aaaaa; Bbbbb; Ccccc; Raymond

    Adding Raymond.

    --- Original Message ---

    Gee, that's very nice of you to add me, but you didn't say why. Is this a FYI? Is there a question you want answered? Often, the discussion is just "Gosh, there's this bug, person A proposes a theory, person B proposes a counter-theory, person C runs some tests and has some preliminary results, adding Raymond."

    It's like "Adding Raymond" is a ritual phrase people sprinkle into a mail thread. They don't know what'll happen when they say it, they don't even have any expectations, but it doesn't hurt to say it, right? "When in doubt, add Raymond."

    If you don't explain why you added me to a thread, I'm just going to killfile it.

  • The Old New Thing

    Performance evaluation euphemisms invading everyday speech (ironically)


    There was a morning meeting event at which donuts were provided as an enticement. Someone commented on the food thus: "These donuts failed to meet expectations."

    Peter Sagal remarked that the phrase "emerging to standard" has entered currency in his family as a euphemism for "substandard". (Opening panel round, final question, time code 1:20.) However, the proposal to replace "failed" with "deferred success" was ultimately defeated.

  • The Old New Thing

    Why doesn't the window manager unregister window classes when the owning DLL unloads?


    If you look at the documentation for the UnregisterClass function, you'll see that it calls out different behavior depending on whether you're running Windows 95 or Windows NT. Commenter Vipin asked why Windows NT doesn't follow Windows 95's lead.

    Back in the old days, 16-bit Windows did unregister classes automatically when a DLL unloaded. It had to do this since all of 16-bit Windows ran in a single address space. If a module's classes were not unregistered when it was unloaded, then all of these leaked classes would clog up the system until it was restarted. Since instance handles were just selectors, and by their nature, selectors could be re-used, it meant that a leaked window class could prevent some totally unrelated program from starting.

    With 32-bit Windows and separate address spaces, a leaked window class affects only the process into which it was leaked. The scope of the damage was contained, and indeed, the scope was limited precisely to the program that did something wrong. If a program leaked a class, it affected only itself. (I suspect there is a contigent of my readership who considers this a good thing. Make programs that screw up pay for their mistake, but don't let them impact other programs.)

    In addition to the philosophical reason for not unregistering classes, there is also a technological one: Sure, you can unregister the classes, but a DLL that forgets to unregister its classes may very well be so careless as to unload itself while there were still windows left undestroyed! Even if you unregistered the class, those windows are going to crash once the windows receive a message and the window procedure is called.

    There's also the issue of subclassing. If the module had subclassed a window, unloading the module will leave the subclassed window procedure dangling. The problem isn't solved; it's just papered over.

    The third reason is architectural. Unregistering a module's classes when it unloads means that there is now an "upward dependency": You've made the kernel call into the window manager. When a module unloads, the kernel needs to call into the window manager to say, "Hey, I just unloaded this module. You might want to clean up stuff." This means that non-GUI programs still have a dependency on the window manager, something you hard-core command line junkies probably would find distasteful. "Why does my non-GUI program have a dependency on the GUI?"

    There was no such thing as a command line 16-bit Windows program, so this sort of upward dependency wasn't really a problem. But upward dependencies violate modern software design principles. A low-level component should not depend on a higher-level component. Since Windows NT was a "next generation" operating system, the designers chose to take it as an opportunity to clean up some of the expediencies that had built up in 16-bit Windows.

    This is another example of "no matter what you do, somebody will hate it." The Windows NT folks decide to do some architectural clean-up, the sort of thing one faction of my readership applauds, while another faction argues that, no, it should have made the architecture dirtier in order to solve the problem so applications don't have to.

  • The Old New Thing

    Long Zheng interviews Hamad Darwish about those Windows Vista wallpapers


    Long Zheng followed up on the story of where the default wallpapers in Windows Vista came from and managed to score an interview with Hamad Darwish, one of those amateur photographers.

  • The Old New Thing

    Do I need rush processing? Beats me!


    During the preparations for the 2005 PDC, I was filling out an application for a corporate credit card. (The rant behind why I was filling out this application in the first place will have to wait for another day.) One of the options was to check a box to request rush processing at an additional charge of $10.

    There was one key piece of information missing: How much faster is rush processing compared to regular processing?

    I needed the card in three weeks. The web site didn't say how long normal processing took. It didn't say how long rush processing took. It just asked me if I wanted to pay extra to go faster.

    I took my chances and decided not to request rush processing. The confirmation page included the standard information, giving me an order number and confirming various bits of information that I had previously entered. And then it said, "This will typically take 7 to 10 business days."

    Thanks a lot for giving me that crucial information after it's too late for me to do anything about it. Fortunately, ten days was plenty of time.

  • The Old New Thing

    Who is most likely to be awarded a MacArthur Fellowship?


    You can count on The Annals of Improbable Research to produce groundbreaking results. One of my favorites is Who is most likely to be awarded a MacArthur Fellowship?, in which researcher (and AIR editorial board member) Eric Schulman performs a careful statistical analysis of previous winners of the MacArthur Fellowship in order to determine who is most likely to win the next one.

    Schulman also correctly predicted the outcome of the 2004 U.S. presidential election using much more complicated reasoning.

  • The Old New Thing

    Why does my property sheet blink and the immediately disappear?


    Occasionally, a customer will ask, "I'm trying to display a property sheet, but when I call the PropertySheet function, the property sheet blinks onto the screen and then immediately disappears. What is wrong?"

    Recall that displaying a property sheet entails filling out a PROPSHEETHEADER structure, which in turn contains a pointer to either an array of HPROPSHEETPAGEs, or more often, an array of PROPSHEETPAGE structures. Each HPROPSHEETPAGE or PROPSHEETPAGE structure describes one page of the property sheet.

    When you ask for a property sheet to be displayed, the property sheet manager looks up each of the pages you specified in order to get its title, and then it starts off by displaying the page you specified in the PROPSHEETHEADER.nStartPage member.*

    Of course, in order to display the page to the user, the property sheet manager needs to create the dialog whose template you specified. And that's where the property sheet can blink out of existence: If the property sheet manager tries to create the dialog corresponding to a property sheet page, but the call to CreateDialog fails†, then the property sheet manager deletes that page and tries the next page. Now you see how the rookie mistakes we've been looking at so far combine to form a sophomore mistake.

    If you make a rookie mistake and either specify the wrong dialog template or fail to register all the classes that your dialog template requires, then the property sheet manager will try to create your first property sheet page and fail. "Fine, let's try the second one, then." And that fails. "How about the third one?" And that fails. Finally, the property sheet manager has tried every single page and none of them could be created. That's when it gives up and tears down the property sheet.

    This also explains why you might see a property sheet page that disappears once you click on its tab. The same thing happened: The property sheet manager tried to create the dialog, but the CreateDialog failed, so it deleted that page and tried the next page.

    This is what often gets mistaken for psychic debugging. You just explore the space logically, consider at each step what could go wrong, and from that list of possible mistakes, choose the one that sounds the most likely. If you just jump directly to your conclusion, people will think you're psychic.

    "I call PropertySheet and the property sheet appears on the screen for a split second, and then vanishes. What am I doing wrong?"

    "My psychic powers tell me that you forgot to call InitCommonControlsEx."

    "Wow, that's amazing! How did you know that?"

    Sherlock Holmes used the same technique to draw startling conclusions in many of Arthur Conan Doyle's stories. Each step in the chain of reasoning was relatively simple and straightforward, but by chaining them together and announcing the conclusion directly, people will think you're psychic.

    Nitpicker's corner

    *You can override the title by setting the PSP_USETITLE flag and putting the custom title into the pszTitle member, and you can use the PSP_USEPSTARTPAGE flag to switch to using the PROPSHEETHEADER.pStartPage member to specify the starting page.

    †Actually, it's CreateDialogParam since the lParam of the WM_INITDIALOG message points to a property sheet page structure.‡

    ‡Nitpicking a nitpick, if you use PSP_DLGINDIRECT, then the function to create the dialog is naturally CreateDialogIndirectParam.

  • The Old New Thing

    Maintaining standards of Japanese food abroad


    They've been nicknamed the sushi police. In response to horror stories from Japanese travelling abroad and being shocked by what passes for Japanese food outside their borders, the Japanese agriculture ministry is developing certification standards for restaurants abroad that want to call themselves Japanese. Their results are supposed to be out at the end of this month with inspections to begin in April.

    You can't say that the Japanese aren't looking out for the psyche of their citizens abroad. (But if they've made the effort to travel to another country, shouldn't they be eating the local food instead of Japanese food?)

Page 3 of 4 (39 items) 1234