June, 2005

  • 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?)

  • The Old New Thing

    Why don't you ever see a rat vomiting?


    Okay, maybe you never wondered why you never saw a vomiting rat, but the intrepid researchers at the Annals of Improbable Research have discovered that there's a good reason, and Anne's rat page will explain in more detail than you probably wanted.

  • The Old New Thing

    Using /LARGEADDRESSAWARE on 64-bit Windows for 32-bit programs


    Probably the biggest advantage of 64-bit Windows is not the larger registers but rather the expansive 64-bit address space. Recall that even when the /3GB switch is set, 32-bit programs receive only 2GB of address space unless they indicate their willingness to cope with addresses above 2GB by passing the /LARGEADDRESSAWARE flag.

    This flag means the same thing on 64-bit Windows. But since 64-bit Windows has a much larger address space available to it, it can afford to give the 32-bit Windows program the entire 4GB of address space to use. This is mentioned almost incidentally in Knowledge Base article Q889654 in the table "Comparison of memory and CPU limits in the 32-bit and 64-bit versions of Windows".

    In other words, certain categories of 32-bit programs (namely, those tight on address space) benefit from running on 64-bit Windows machine, even though they aren't explicitly taking advantage of any 64-bit features.

Page 4 of 4 (35 items) 1234