February, 2007

  • The Old New Thing

    Public service announcement for United States taxpayers: In tax year 2006, you can claim a $30 refund if you owned a telephone


    The United States government authorized a one-time refund of long-distance excise taxes paid between March 2003 and July 2006, but early returns suggest that many taxpayers are unaware of this refund. (Here's the IRS press release that goes into more detail and includes a list of most common mistakes people have been making.) The easy way to claim this is merely to take the standard deduction of $refund; the hard way is to collect all your telephone bills from that period and compute how much long distance excise tax you actually paid.

    This entry also illustrates how all the nitpicking from commenters over the years has altered the way I write, forcing me to put all sorts of clarifying information into the subject line—making it rather unwieldy—so that people won't carp about how the entry applies only to United States income taxes. Remember when blogs were an informal communication mechanism? Where you could leave mathematical precision behind, relying on your readers to fill in the gaps? When you could toss together a sample program without people obsessing over the grayscale algorithm you used? Or use phrases like "regular people like you and me" without being taken to task for implying that other people aren't regular? I miss those days. Blogging isn't all that much fun now; it's more of a chore.

    (And I predict that somebody is going to nitpick my article and lambaste me for missing the fact that the exact amount of the refund varies depending on how many exemptions you claim. So here's the disclaimer: This entry is provided for informational purposes only and should not be construed as providing tax advice. Consult with an attorney or tax professonal regarding any specific legal or tax situation.)

  • The Old New Thing

    Please feel free to stop using DDE


    A commenter asked, "As an application programmer, can I really ignore DDE if I need to interact with explorer/shell?"

    The answer is, "Yes, please!"

    While it was a reasonable solution back in the cooperatively-multitasked world of 16-bit Windows where it was invented, the transition to 32-bit Windows was not a nice one for DDE. Specifically, the reliance on broadcasts to establish the initial DDE conversation means that unresponsive programs can jam up the entire DDE initiation process. The last shell interface to employ DDE was the communication with Program Manager to create program groups and items inside those groups. This was replaced with Explorer and the Start menu back in Windows 95. DDE has been dead as a shell interface for over ten years.

    Of course, for backwards compatibility, the shell still supports DDE for older programs that choose to use it. You can still create icons on the Start menu via DDE and you can still register your documents to launch via DDE if you really want to, but if you take a pass on DDE you won't be missing anything.

    On the other hand, even though there is no technological reason for you to use DDE, you still have to be mindful of whether your actions will interfere with other people who choose to: If you stop processing messages, you will clog up DDE initiation, among other things. It's like driving an automatic transmission instead of a manual transmission. There is no requirement (in the United States, at least) that you own a manual transmission or even know how to operate one. But you still have to know to ensure that your actions do not interfere with people who do have manual transmissions, such as watching out for cars waiting for the traffic light to change while pointed uphill.

  • The Old New Thing

    The network interoperability compatibility problem, second follow-up


    I post this entry with great reluctance, because I can feel the heat from the pilot lights of the flame throwers all the way from here.

    The struggle with the network interoperability problem continued for several months after I brought up the topic. In that time, a significant number of network attached storage devices were found that did not implement "fast mode" queries correctly. (Buried in this query are some of them; there are others.) Some of them were Samba-based whose vendors did not have an upgrade available that fixed the bug. But many of them used custom implementations of CIFS; consequently, any Samba-specific solutions would not have helped those devices. (Most of the auto-detection suggestions people proposed addressed only the Samba scenario. Those non-Samba devices would still not have worked.) Even worse, most of the devices are low-cost solutions which aren't firmware-upgradable or have any vendor support.

    Some of the reports came from people running fully-patched well-known Linux distributions. So much for being in all the new commercially supported offerings over the next couple months.

    Furthermore, those buggy non-Samba implementations mishandled fast mode queries in different ways. For example, one of them I was asked to look at didn't return any error codes at all. It just returned garbage data (most noticeably, corrupting the file name by deleting the first five characters). How do you detect that this has happened? If the server reports "I have a file called e.txt", is Windows supposed to say, "Oh, I don't think so. I bet you're one of those buggy servers that chops off the first five letters of file names and that you really meant to say (scrunches forehead in concentration) readme.txt"? What if you really had a file called e.txt? What if the server said, "This directory has two files, 1.txt and 2.txt"? Is this a buggy server? Maybe the files are really abcde1.txt and defgh2.txt, or maybe the server wasn't lying and the files really are 1.txt and 2.txt.

    One device simply crashed if asked to perform a fast mode query. Another wedged up and had to be reset. "Oh, looks like somebody brought their Vista laptop from home and plugged it into the corporate network. Our document server crashed again."

    Given the much broader ways that servers mishandled fast queries, any attempt at auto-detecting them will necessarily be incomplete and fail to detect broken servers. This is fundamentally the case for servers which return perfectly formed, but incorrect, data. And even if the detection were perfect, if it left the server in a crashed or hung state, that wouldn't be much consolation.

    Given this new information, the solution that was settled on was simply to stop using "fast mode" queries for anything other than local devices. The most popular file system drivers for local devices (NTFS, FAT, CDFS, UDF) are all under Microsoft's control and they have already been tested with fast mode queries.

    Such is the sad but all-too-true cost of interoperability and compatibility.

    (To address other minor points: It's not the case that the Vista developers "knew the [fast mode query] would break Samba-based devices since late 2005". The fast mode query was added, and the incompatibility with Samba wasn't discovered until March 2006. "Why didn't you notify the Samba team?" Because by the time we found the problem, they had already fixed it.)

  • The Old New Thing

    Why can't you set the command prompt's current directory to a UNC?


    If you try to set the current directory of a command prompt, you get the error message "CMD does not support UNC paths as current directories." What's going on here?

    It's MS-DOS backwards compatibility.

    If the current directory were a UNC, there wouldn't be anything to return to MS-DOS programs when they call function 19h (Get current drive). That function has no way to return an error code, so you have to return a drive letter. UNCs don't have a drive letter.

    You can work around this behavior by using the pushd command to create a temporary drive letter for the UNC. Instead of passing script.cmd to the CreateProcess function as the lpCommandLine, you can pass cmd.exe /c pushd \\server\share && script.cmd.

    (Griping that seems to happen any time I write about batch files, so I'll gripe them pre-emptively: Yes, the batch "language" sucks because it wasn't designed; it just evolved. I write this not because I expect you to enjoy writing batch files but because you might find yourself forced to deal with them. If you would rather abandon batch files and use a different command interpreter altogether, then more power to you.)

  • The Old New Thing

    How to get your laptop to resume from standby in under two seconds


    One of my colleagues recently posted the story of the work he did to get laptops to resume quickly. The fun part was implementing the optimizations in the kernel. The not-fun part was finding all the drivers who did bad things and harassing their owners into fixing the bugs.

    One some laptops, he could get the resume time down to an impressive one second. And then entropy set in.

    It's likely you've never seen a real off-the-shelf laptop resume this quickly. And the reason is that as soon as you stop twisting the arms of all the driver writers, they stop worrying about how fast your laptop resumes and go back to worrying about when they can get their widget driver mostly working so they can get through WHQL and sell their widget.

    But now you have some tools to fight back, at least a little bit. The second half of that article explains how to use the event viewer to track down which drivers are ruining your resume time and disable them.

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

  • The Old New Thing

    The ironic thing about fixing a bug


    The ironic thing about fixing a bug, or at least once I mention on this web site that I fixed a particular bug, is that people immediately complain that I didn't fix some other bug. One school of complaint believes that cosmetic bugs should be fixed first: "You suck. I mean, look at these egregious cosmetic bugs. If you can't get even those right, then obviously you can't get the other stuff right either." The opposite school believes that cosmetic bugs should be fixed last: "You suck. I mean, why are you fixing cosmetic bugs when there are these other bugs!"

    But at least both camps agree on one thing: I suck.

    I think I'd be better off if I said I didn't fix any bugs at all.

  • The Old New Thing

    Final remarks on LockWindowUpdate


    Now that you understand the intended purpose of LockWindowUpdate, I'm going to tell you why you don't want to use it, not even for its intended purpose!

    You have to go back to the historical context in which LockWindowUpdate was created. Rewind back to 16-bit Windows, specifically Windows 3.1. Back in these days, memory was expensive. Video drivers were pretty limited in functionality. There was no DirectX. There was no AlphaBlend function. All you had was a screen buffer. The LockWindowUpdate function let you take control over one window's portion of that screen buffer so you could apply your fancy effects to the window without that window's knowledge.

    It's been over a decade since Windows 3.1, and in the meanwhile, we gained DirectX overlays, regional windows, layered windows, alpha blending, desktop composition, all sorts of cool graphical effects that weren't available back in the old days. In particular, those layered windows and regional windows pretty much let you do nearly all of the stuff you would have wanted to do with LockWindowUpdate anyway. If you want to draw a highlight around a window, you can position a regional window around it. If you want to draw a drag image over a window, you can just create layered window and position it over the target window. Give the layered window a region and whatever fancy alpha channel you want, and let the graphics engine do the heavy lifting of alpha blending and composition. Even better, the layered window can extend outside the window you are dragging over, something that LockWindowUpdate can't do. (You can see this effect in Windows XP if you do a "select all" in an Explorer window and drag the entire selection around the screen. Notice that the drag image is not constrained to the boundaries of the window you are dragging over.)

    What's more, in the exciting new composited world of Vista's desktop window manager, LockWindowUpdate is even less desirable. Locking a particular window for update isn't so bad since the desktop window manager can just give you the backing bitmap for the window. But if you lock the entire screen (which I've seen may people do), the desktop window manager needs to compose all of the windows into an actual bitmap that it can give you when you call GetDCEx with the DCX_LOCKWINDOWUPDATE flag. The desktop window manager does composition on the fly with the help of DirectX and accelerated video drivers. The result of all this composition normally goes straight to the screen without actually residing in a "composited" bitmap anyway. But if you lock the screen and ask for a DC to it, the desktop window manager needs to emulate the old behavior and give you access to something that represents what you would have gotten if there were no composition in the first place. That ain't cheap.

    Epilogue. I'm not sure if this series was a success or not. My goal was just to help people use LockWindowUpdate more effectively and guide them towards alternatives when LockWindowUpdate is the wrong tool for the job. In other words, it's an article about LockWindowUpdate, not function documentation. I tried to keep the presentation light, but I guess my jokes fell flat, and people just used them as a springboard for negative comments.

    And extra thanks to the people who took it as an opportunity to complain about the documentation. I mean, duh, if the documentation were perfect, I wouldn't have written this series in the first place. Though these people also neglected to read all of the documentation; they looked only at the function description page. There's more to documentation than dry function descriptions, people! The function description is a reference; you go there when you already know what's going on and you just need to fine-tune a detail. The real learning happens in the overviews and articles. If you want to learn how to operate your radio, you don't read the schematic first.

    I think Ronald D. Moore is really onto something when he says, "You have to be tough enough to listen to the podcast."

  • The Old New Thing

    The politician's fallacy and the politician's apology


    I learned this from Yes, Minister. They call it the politician's fallacy:

    1. Something must be done.
    2. This is something.
    3. Therefore, we must do it.

    As befits its name, you see it most often in politics, where poorly-thought-out solutions are proposed for urgent problems. But be on the lookout for it in other places, too. You might see somebody falling victim to the politician's fallacy at a business meeting, say.

    Something else I picked up is what I'm going to call the politician's apology. This is where you apologize for a misdeed not by apologizing for what you did, but rather apologizing that other people were offended. One blogger coined the word "fauxpology" to describe this sort of non-apology. In other words, you're not apologizing at all! It's like the childhood non-apology.

    "Apologize to your sister for calling her ugly."

    "I'm sorry you're ugly."

    In the politician's apology, you apologize not for the offense itself, but for the fact that what you did offended someone. "I'm sorry you're a hypersensitive crybaby."

    The president regretted any hurt feelings his statements may have caused.

    Another form of non-apology is to state that bad things happened without taking responsibility for causing them:

    There should not have been any physical contact in this incident. I am sorry that this misunderstanding happened at all, and I regret its escalation and I apologize.

    This particular non-apology even begins with the accusation that the other party was at fault for starting the incident!

    What bothers me is that these types of non-apologies are so common that nobody is even offended by their inadequacy. They are accepted as just "the way people apologize in public". (It's become so standard that Slate's William Saletan has broken it down into steps for us.)

  • The Old New Thing

    Why did Explorer say "The target you specified is on the desktop"?


    In Windows 95, if you had a shortcut to a file on the desktop, view the shortcut's properties, and then clicked "Find Target", you got the message "The target you specified is on the desktop". It also selected the item on the desktop to help you find it.

    But why didn't it just open an Explorer window that viewed the desktop?

    Because in Windows 95, you couldn't display the desktop in an Explorer window. The only way to see the desktop was to minimize all your application windows. There wasn't a "Show Desktop" button in Windows 95 either. Therefore, the shortcut property sheet did as much as it could: It highlighted the item on the desktop, but it couldn't open Explorer or show the desktop. Instead, it just told you "Hey, it's on your desktop," with an implied, "I took you as far as I could, sorry."

    Fortunately, the inability to show the desktop in an Explorer window was removed in later versions of Windows, and the strange dialog box disappeared as well.

Page 1 of 4 (39 items) 1234