• The Old New Thing

    Why can't the default drag/drop behavior be changed?


    A common reaction to my explanation of whether dragging a file will result in a move or copy was that there should be a setting that lets you change the algorithm by which Explorer decides whether you want to move or copy.

    There are a few reasons why this is a bad idea.

    First, if there were such a setting, then it removes some of the predictability from the user interface. One of the benefits of a common user interface is that once you learn it, you can apply the rules generally. But if each user could customize how drag/drop works, then the knowledge you developed with drag/drop wouldn't transfer to other people's machines.

    Some people view infinite customizability as a good thing. But each added bit of customizability increases the possibility that a particular combination of settings won't get tested as heavily as perhaps it should. ("What do you mean, this doesn't work if you have the notification icons set to hide after only 5 seconds, the taskbar's auto-hide delay customized to a value larger than 5 seconds, the taskbar buttons customized to a boldface font larger than 14pt, and drag/drop operations defaulting always to move? How could you have missed that combination in your testing? Surely you should have anticipated the interaction between an auto-hide delay longer than the notification auto-hide delay combined with a nondefault drag on a network with fewer than 50 machines!")

    Infinite customizability also means that you can't just sit down in front of somebody's machine and start using it. You first have to learn how they customized their menus, button clicks, default drag effects, and keyboard macros. "Oh, on this machine, you paste by shift-right-clicking. Sorry. On my machine, I use ctrl-alt-middle-click to paste." Imagine if everybody could easily customize the order of the clutch, brake, and gas pedals in their car to suit their fancy.

    There is also the branding element. Like the Mac, Windows tries to cultivate a specific "look" that makes people say, "Hey, this computer is running Windows; I know how to use it!" My DVD player and my car both show the manufacturer's logo when they are booting up. So too does Windows.

    Even if the "change the default drag/drop behavior" option passed "settings court" and was deemed worth the additional test cost, you still have the problem that it affects only Explorer. Other programs would continue to use the old algorithm, at least until you found their settings to change how they perform default drag/drop as well, if such a setting existed at all. Imagine the confusion if Windows Explorer followed one set of rules, but Microsoft Outlook followed a different set of rules. "Oh right, this is a mail message I'm dragging; the default operation is going to be a move, not a copy."

  • The Old New Thing

    Can you trust the Man on the Street interview?


    Occasionally, in a news story, the reporter will ask for comments or opinion from a passer-by (nicknamed "the man on the street"). Greg Packer has created a second career as that man.

    In the last 10 years, he's been quoted at least a dozen times by the New York Post. He's been quoted at least 14 times by the Daily News, most recently just last week. He was quoted in the Atlanta Journal-Constitution two weeks ago. And Packer has been quoted or photographed at least 16 times on separate occasions by the Associated Press. ...

    [H]e checks the newspapers for concerts, sports games, parades, book signings - anywhere media trucks might be camped out. Then, he requests time off from his job as a highway worker on Long Island and shows up early, scanning the crowd for reporters.

    It got so bad that the Associated Press issued an internal memo instructing reporters not to talk to the guy any more!

    That story from On the Media reminded me of a related incident back when the hype surrounding Star Wars: The Phantom Menace was building. The New York Times sent a reporter to cover the people who had been waiting in line for months. The first person interviewed is Sangay Kumar, who claims to have flown in from Bombay just to see the movie.

    A friend of mine read the article and started laughing.

    Because my friend knows Mr. Kumar, who it turns out is not actually from Bombay. He's from Baltimore. He was just waiting in line with everybody else and saw a reporter coming and decided to put on a campy Indian accent and make up a nutty story. And the reporter bought it.

  • The Old New Thing

    Why don't control panel programs and property sheets show up in the taskbar?


    Control panel programs and property sheets don't show up in the taskbar. Why not?

    As I recall, the explanation was that control panel programs and property sheets aren't applications. They are auxiliary helper windows that assist you with a task, but they aren't a program in their own right. Therefore, they don't get a taskbar button.

    I've always been kind of suspicious of that explanation, but there it is, make of it what you will. (I don't mind the behavior—putting them in the taskbar just creates clutter—but the explanation I found kind of wanting.)

  • The Old New Thing

    Answer to quick puzzle about security and synchronization


    As many people quickly figured out, the reason why the the WaitForSingleObject returns immediately is that the call is failing. The reason is that the second process opened the handle with EVENT_MODIFY_STATE access, which grants permission to call the SetEvent function, the ResetEvent function, and the fatally flawed PulseEvent function, but it doesn't include SYNCHRONIZE access, which is necessary if you intend to synchronize on the object (i.e., wait on it).

    The fix is for Process B to ask for SYNCHRONIZE access instead of EVENT_MODIFY_STATE.

    The fact that it's happening in a second process is a red herring. You can put this code in the same process and it will fail/succeed in the same way:

    HANDLE hEventA = CreateEvent(NULL, FALSE, TRUE, TEXT("MyNamedEvent"));
    HANDLE hEventB = OpenEvent(EVENT_MODIFY_STATE, FALSE, TEXT("MyNamedEvent"));
    WaitForSingleObject(hEventB, INFINITE); // fails

    Indeed, the fact that the object is named is a red herring. It has nothing to do with named/unnamed objects.

    HANDLE hEventA = CreateEvent(NULL, FALSE, TRUE, NULL);
    HANDLE hEventB;
    DuplicateHandle(GetCurrentProcess(), hEventA,
                    GetCurrentProcess(), &hEventB,
                    EVENT_MODIFY_STATE, FALSE, 0);
    WaitForSingleObject(hEventB, INFINITE); // fails

    In all three cases, the fix is to change EVENT_MODIFY_STATE to SYNCHRONIZE.

  • The Old New Thing

    What if two programs did this?


    The thought experiment "Imagine if this were possible" is helpful in thinking through whether Windows lets you do something or other. (A special case of this is "When people ask for security holes as features.") If the possibility leads to an obvious contradiction or the violation of generally-accepted rules of metaphysics, then you can be pretty sure that Windows doesn't support it. (Of course, the absence of such a contradiction doesn't prove that Windows does support it. But you can use it to rule out obvious bad ideas.)

    The question "What if two programs did this?" is also helpful in evaluating a feature or a design request. Combining this with "Imagine if this were possible" leads to an impressive one-two punch. Here are a few examples:

    "How do I create a window that is never covered by any other windows, not even other topmost windows?"

    Imagine if this were possible and imagine if two programs did this. Program A creates a window that is "super-topmost" and so does Program B. Now the user drags the two windows so that they overlap. What happens? You've created yourself a logical impossibility. One of those two windows must be above the other, contradicting the imaginary "super-topmost" feature.

    "How do I mark my process so that it always the first/last to receive the system shutdown notification? I want to do something before/after all other programs have shut down."

    Imagine if this were possible and imagine if two programs did this. You now have two programs both of which want to be first/last. But you can't have two first or two last things. One of them must lose. (This of course generalizes to other things people might want to be first or last.)

    "How do I make sure that my program is always the one that runs when the user double-clicks an .XYZ file?"

    Imagine if this were possible and imagine if two programs did this. Now the user double-clicks an .XYZ file. Which program runs?

    In this case, the solution is to leave the user in charge of their file associations; if they decide that they want your competitor's program to be used for .XYZ files, then that's their decision and you should respect it.

    My colleague Zeke [link fixed 11am], who is responsible, among other things, for the way file associations work in Explorer, provides a few alternatives:

    Here is the entry point in MSDN to the documentation on file associations in Explorer.

    For many of these "I want to be the X-est"-type questions, you can often come up with some sort of hack, where you run a timer that periodically checks whether you are still X, and if not, pushes you back into the X-position. And then you stop and think, "What if two programs did this?" and realize that it's a bad idea. At least I hope you do.

    Even with this explanation, some people still don't get it. I'll ask them to consider, "What if two programs did this? They'll be fighting back and forth," and the answer I get back is, "Then I can have the second program check if the first program is already running." They don't understand that they didn't write the second program.

    When two programs "duke it out" like this, you can't predict which one will win, but you can predict with 100% certainty who will lose: The user.

    I remember well when one of my colleagues called me into his office to show me two very popular commercial programs that both wanted to guarantee that they were the program that ran when the user double-clicked an .XYZ document. Since there is no such guarantee, they faked it with the timer hack.

    You installed the first program, it set itself as the .XYZ file handler, and everything seemed normal. You then installed the second program, it set itself as the new .XYZ file handler, and the first program noticed and said, "Uh-uh, I'm the program that runs .XYZ files", and changed things back. Then the second program said, "No way, I'm the program that runs .XYZ files" and set itself back.

    This childish game of "Nuh-uh/Yuh-huh!" went on while the user sat there dumbfounded and helpless, watching the icon for their .XYZ files flicker back and forth between the two programs, both of whom egotistically believed they were doing the user a "favor" by insisting on being the program that runs .XYZ files.

  • The Old New Thing

    Adam Felber teaches us how to avoid setting off motion detectors


    In a sidebar discussion on this week's episode of Wait Wait, Don't Tell Me, Adam Felber explains that "you can foil most motion detectors with a pair of insulated gloves, a piece of plywood, and a hat." [Windows Media] [RealPlayer]

  • The Old New Thing

    A quick puzzle about security and synchronization


    This quick puzzle floated past one of our internal discussion groups.

    // in process A
    hEventA = CreateEvent(NULL, FALSE, TRUE, TEXT("MyNamedEvent"));
    // in process B
    hEventB = OpenEvent(EVENT_MODIFY_STATE, FALSE, TEXT("MyNamedEvent"));
    WaitForSingleObject(hEventB, INFINITE);

    In Process B, the OpenEvent succeeds, but the WaitForSingleObject returns immediately instead of waiting. Explain.

    [Correction: I confused the matter by passing TRUE as the third parameter, thereby creating an event that is initially signalled. Change it to FALSE so that the event is created non-signalled, in which case the WaitForSingleObject would be expected to wait.]

  • The Old New Thing

    Why does Windows XP SP2 sometimes forget my CD autoplay settings?


    It didn't forget them; it's just double-checking with you.

    The developer responsible for CD autoplay in Windows XP SP2 explained it to me. There were two problems with the way Windows XP handled CD autoplay.

    First, when you installed a new program that included CD autoplay capability, many users didn't know where in the UI to go to select that new program as their default CD autoplay program. If they had previously selected a program and ticked "Always perform this action", there was no easily-discoverable way to undo the "always" flag to make the dialog reappeared and allow the user to select the new program instead.

    Second, many programs, upon installation, secretly hacked the undocumented CD autoplay settings in order to set themselves as the default CD autoplay handler, gleefully overriding the user's previously-stated preference. Because these programs egotistically believed themselves to be the coolest most amazing program ever written in the history of mankind.

    In other words, the two problems were, "I just installed this program and I want it to be the CD autoplay program" and its converse "I just installed this program and I don't want it to be the CD autoplay program".

    Windows XP SP2 introduced new behavior related to CD autoplay in an attempt to address these problems: When it sees that a new CD autoplay handler is available, it shows you the CD autoplay dialog one more time. This gives you a chance to (a) pick that new program you just installed, or (b) un-pick that program you just installed (if it was presumptuously rude enough to set itself as your default).

    The first time you insert a CD into your computer after upgrading to Windows XP SP2, you will also get the CD autoplay dialog. This is a "better late than never" dialog to cover for any handlers that were installed before you upgraded to Windows XP SP2.

    What's the moral of the story? Whereas in the old days, you only had to worry about helping other programmers interface with your feature, in the new software landscape, you also have to worry about stopping programmers who are trying to abuse your interface.

  • The Old New Thing

    The 2005 Seattle Chicken Tour


    Mark your calendars for the 2005 Seattle Chicken Tour, scheduled this year for July 16th.

    Seattle Tilths Annual City Chickens and Coop Tour July 16, 2005   10 am — 4 pm
    $10 per family or group of four

    Seattles city chickens owners invite you into their backyards for a first-hand look at raising chickens. Discover the variety of breeds that might be nesting in your neighborhood, learn about raising chickens, see how families integrate chickens into their organic gardening practices, as well as the ingenious coops that shelter these chickens. You will need a car to travel on this self-guided tour of over a dozen backyard chicken broods. Bring the whole family, and your out-of-town visitors, for this unique view of Seattles backyards.

    I am not certain whether advance registration is required, so if you're interested, you should contact Seattle Tilth sooner rather than later.

  • The Old New Thing

    If strncpy is so dangerous, why does Visual Studio 2005 still support it?


    In response to the news that strncpy is so dangerous, at least one person has called for Visual Studio to revoke support for such a dangerous function, considering the continued support for the function grounds for holding the compiler manufacturer liable for any defects in programs compiled with that compiler.

    Well, for one thing, while it's true that strncpy is dangerous if used improperly, it is still a valid function, and my original discussion explained the history behind strncpy and the very specific scenario in which it is still useful. It just so happens that most people don't use the function in the manner it was intended, but instead treat it as a sort of "copy string with a character limit" function, which it isn't really.

    For another thing, just because something is dangerous doesn't mean it shouldn't be supported. Pointers and casts are dangerous, but I don't see them disappearing from C or C++ any time soon.

    Third, support for strncpy is mandated by the C standard. If you removed it, you couldn't call yourself a C compiler any more. (Not to mention breaking compatibility with existing source code that uses the strncpy function. How would you like it if you bought a so-called C compiler and found that it couldn't compile a large class of valid C programs?)

Page 377 of 453 (4,527 items) «375376377378379»