• The Old New Thing

    Bringing cryptic command lines to Windows


    The CMD.EXE batch language can be awfully cryptic, but for those who miss the richness of command lines like

    kill -1 $(ps -ef | grep inetd | grep -v grep | tr -s " " | cut -f2 -d " ")
    or bursts of line noise masquerading as a pipeline of "find", "sed", and "awk" processes, Microsoft Windows Services for Unix is available for free download.

  • The Old New Thing

    Alton Brown book appearance report


    Right on schedule, Alton Brown appeared at the Elliot Bay Book Company bookstore in downtown Seattle. One of my friends wondered aloud, "Wait a second, he's promoting his cookbook. How do you do a reading from a cookbook?"

    He didn't read from his cookbook.

    To an overflow crowd that probably violated a few fire codes, Alton Brown discussed what inspired him to tackle a book on baking, riffed with the audience (he's quite funny when interacting with a crowd), then fielded questions. Alton Brown trivia:

    • At the New England Culinary Institute, he drove his teachers crazy by constantly asking the sorts of questions that he answers on his show. "What is going on chemically?" "What is the purpose of eggs in this recipe?" "Where does the water go?" They thought they were rid of him when he graduated, but AB got the last laugh: The school now gets applications which say "I want to cook like Alton Brown."
    • Why does he wear Hawaiian shirts on Good Eats? Because the material they're made from doesn't rustle against the microphone.
    • The wacko camera angles come from his background in directing television commercials. The show was originally up against The West Wing and used its irreverent style as a form of counter-programming.
    • AB claims that all the actors on the show are really production crew members brought in front of the camera. How much of this you choose to believe is up to you.
    • Each episode takes about three days to film. (Note: This doesn't count all the writing and research time.) Compare this to traditional cooking shows which film three episodes in one day!
    • The Good Eats theme is exactly ten notes long, at AB's specific request. It was allegedly inspired by the last track on the Get Shorty soundtrack CD.
    • On Iron Chef America he does not himself taste any of the dishes. Any more. He learned this lesson the hard way after trying Hiroyuki Sakai's trout ice cream.
    • Before trying any of the recipes in the book, check AB's web site for corrections. The most notorious misprint is the mysterious "aspirin" substitution on page 238. (You also have to watch out for the spelling mistakes. "Nickle"?)

    Afterwards, he signed books for ages and managed to be a good sport about it throughout. Then again, this is a book tour, after all. During that time, he's mastered the ability to sign a book and talk at the same time. I, on the other hand, am a rank amateur and couldn't even talk and watch him sign my book at the same time.

  • The Old New Thing

    Why are kernel HANDLEs always a multiple of four?


    Not very well known is that the bottom two bits of kernel HANDLEs are always zero; in other words, their numeric value is always a multiple of 4. Note that this applies only to kernel HANDLEs; it does not apply to pseudo-handles or to any other type of handle (USER handles, GDI handles, multimedia handles...) Kernel handles are things you can pass to the CloseHandle function.

    The availability of the bottom two bits is buried in the ntdef.h header file:

    // Low order two bits of a handle are ignored by the system and available
    // for use by application code as tag bits.  The remaining bits are opaque
    // and used to store a serial number and table index.
    #define OBJ_HANDLE_TAGBITS  0x00000003L

    That at least the bottom bit of kernel HANDLEs is always zero is implied by the GetQueuedCompletionStatus function, which indicates that you can set the bottom bit of the event handle to suppress completion port notification. In order for this to work, the bottom bit must normally be zero.

    This information is not useful for most application writers, which should continue to treat HANDLEs as opaque values. The people who would be interested in tag bits are those who are implementing low-level class libraries or are wrapping kernel objects inside a larger framework.

  • The Old New Thing

    Hyperlinking to Hutchison Whampoa Limited forbidden


    Maybe they don't want people to find them.

    The copyright notice for the web site of Hutchison Whampoa Limited states,

    Copyright Hutchison Whampoa Limited. 2003. All rights reserved.

    No person, whether an individual or a body corporate, shall create or establish a hyperlink to the HWL Corporate Website by hypertext reference or imaging without the written permission of Hutchison.

    I can't create a hyperlink so you'll have to find it yourself.

    This isn't an issue of deep linking; they are banning even links to their home page.

  • The Old New Thing

    A 90-byte "whereis" program


    Sometimes people try too hard.

    You can download a C# program to look for a file on your PATH, or you can use a 90-character batch file:

    @for %%e in (%PATHEXT%) do @for %%i in (%1%%e) do @if NOT "%%~$PATH:i"=="" echo %%~$PATH:i
  • The Old New Thing

    CreateProcess does not wait for the process to start


    The CreateProcess function creates a new process, but it doesn't wait for the process to get off the ground before returning. It just creates the process object and lets it go to do its thing.

    The Win32 process model is that each process initializes itself in context. When a process object is created, it is practically empty, save for enough information to get the program execution procedure started. When the thread in the process object is scheduled, it starts doing the real work of loading DLLs, initializing them in the correct order, then calling to the program's entry point.

    If, along the way, one of these process startup steps fails, the process is killed, and the exit code is the reason why the process couldn't get started. For example, if the problem was that a function could not be found in a DLL, the exit code will be STATUS_ENTRYPOINT_NOT_FOUND.

    (And don't forget that you can use the SetErrorMode function to disable the error dialog.)

  • The Old New Thing

    The importance of error code backwards compatibility


    I remember a bug report that came on in an old MS-DOS program (from a company that is still in business so don't ask me to identify them) that attempted to open the file "". That's the file with no name.

    This returned error 2 (file not found). But the program didn't check the error code and though that 2 was the file handle. It then began writing data to handle 2, which ended up going to the screen because handle 2 is the standard error handle, which by default goes to the screen.

    It so happened that this program wanted to print the message to the screen anyway.

    In other words, this program worked completely by accident.

    Due to various changes to the installable file system in Windows 95, the error code for attempting to open the null file changed from 2 (file not found) to 3 (path not found) as a side-effect.

    Watch what happens.

    The program tries to open the file "". Now it gets error 3 back. It mistakenly treats the 3 as a file handle and writes to it.

    What is handle 3?

    The standard MS-DOS file handles are as follows:

    handle name meaning
    0stdinstandard input
    1stdoutstandard output
    2stderrstandard error
    3stdauxstandard auxiliary (serial port)
    4stdprnstandard printer

    What happens when the program writes to handle 3?

    It tries to write to the serial port.

    Most computers don't have anything hooked up to the serial port. The write hangs.

    Result: Dead program.

    The file system folks had to tweak their parameter validation so they returned error 2 in this case.

  • The Old New Thing

    How did MS-DOS report error codes?


    The old MS-DOS function calls (ah, int 21h), typically indicated error by returning with carry set and putting the error code in the AX register. These error codes will look awfully familiar today: They are the same error codes that Windows uses. All the small-valued error codes like ERROR_FILE_NOT_FOUND go back to MS-DOS (and possibly even further back).

    Error code numbers are a major compatibility problem, because you cannot easily add new error code numbers without breaking existing programs. For example, it became well-known that "The only errors that can be returned from a failed call to OpenFile are 3 (path not found), 4 (too many open files), and 5 (access denied)." If MS-DOS ever returned an error code not on that list, programs would crash because they used the error number as an index into a function table without doing a range check first. Returning a new error like 32 (sharing violation) meant that the programs would jump to a random address and die.

    More about error number compatibility next time.

    When it became necessary to add new error codes, compatibility demanded that the error codes returned by the functions not change. Therefore, if a new type of error occurred (for example, a sharing violation), one of the previous "well-known" error codes was selected that had the most similar meaning and that was returned as the error code. (For "sharing violation", the best match is probably "access denied".) Programs which were "in the know" could call a new function called "get extended error" which returned one of the newfangled error codes (in this case, 32 for sharing violation).

    The "get extended error" function returned other pieces of information. It gave you an "error class" which gave you a vague idea of what type of problem it is (out of resources? physical media failure? system configuration error?), an "error locus" which told you what type of device caused the problem (floppy? serial? memory?), and what I found to be the most interesting meta-information, the "suggested action". Suggested actions were things like "pause, then retry" (for temporary conditions), "ask user to re-enter input" (for example, file not found), or even "ask user for remedial action" (for example, check that the disk is properly inserted).

    The purpose of these meta-error values is to allow a program to recover when faced with an error code it doesn't understand. You could at least follow the meta-data to have an idea of what type of error it was (error class), where the error occurred (error locus), and what you probably should do in response to it (suggested action).

    Sadly, this type of rich error information was lost when 16-bit programming was abandoned. Now you get an error code or an exception and you'd better know what to do with it. For example, if you call some function and an error comes back, how do you know whether the error was a logic error in your program (using a handle after closing it, say) or was something that is externally-induced (for example, remote server timed out)? You don't.

    This is particularly gruesome for exception-based programming. When you catch an exception, you can't tell by looking at it whether it's something that genuinely should crash the program (due to an internal logic error - a null reference exception, for example) or something that does not betray any error in your program but was caused externally (connection failed, file not found, sharing violation).

  • The Old New Thing

    Cleaner, more elegant, and harder to recognize


    It appears that some people interpreted the title of one of my rants from many months ago, "Cleaner, more elegant, and wrong", to be a reference to exceptions in general. (See bibliography reference [35]; observe that the citer even changed the title of my article for me!)

    The title of the article was a reference to a specific code snippet that I copied from a book, where the book's author claimed that the code he presented was "cleaner and more elegant". I was pointing out that the code fragment was not only cleaner and more elegant, it was also wrong.

    You can write correct exception-based programming.

    Mind you, it's hard.

    On the other hand, just because something is hard doesn't mean that it shouldn't be done.

    Here's a breakdown:

    Really easy Hard Really hard
    Writing bad error-code-based code
    Writing bad exception-based code
    Writing good error-code-based code Writing good exception-based code

    It's easy to write bad code, regardless of the error model.

    It's hard to write good error-code-based code since you have to check every error code and think about what you should do when an error occurs.

    It's really hard to write good exception-based code since you have to check every single line of code (indeed, every sub-expression) and think about what exceptions it might raise and how your code will react to it. (In C++ it's not quite so bad because C++ exceptions are raised only at specific points during execution. In C#, exceptions can be raised at any time.)

    But that's okay. Like I said, just because something is hard doesn't mean it shouldn't be done. It's hard to write a device driver, but people do it, and that's a good thing.

    But here's another table:

    Really easy Hard Really hard
    Recognizing that error-code-based code is badly-written
    Recognizing the difference between bad error-code-based code and not-bad error-code-based code.
    Recognizing that error-code-base code is not badly-written
    Recognizing that exception-based code is badly-written
    Recognizing that exception-based code is not badly-written
    Recognizing the difference between bad exception-based code and not-bad exception-based code

    Here's some imaginary error-code-based code. See if you can classify it as "bad" or "not-bad":

    BOOL ComputeChecksum(LPCTSTR pszFile, DWORD* pdwResult)
      HANDLE h = CreateFile(pszFile, GENERIC_READ, FILE_SHARE_READ,
      HANDLE hfm = CreateFileMapping(h, NULL, PAGE_READ, 0, 0, NULL);
      void *pv = MapViewOfFile(hfm, FILE_MAP_READ, 0, 0, 0);
      DWORD dwHeaderSum;
      CheckSumMappedFile(pvBase, GetFileSize(h, NULL),
               &dwHeaderSum, pdwResult);
      return TRUE;

    This code is obviously bad. No error codes are checked. This is the sort of code you might write when in a hurry, meaning to come back to and improve later. And it's easy to spot that this code needs to be improved big time before it's ready for prime time.

    Here's another version:

    BOOL ComputeChecksum(LPCTSTR pszFile, DWORD* pdwResult)
      BOOL fRc = FALSE;
      HANDLE h = CreateFile(pszFile, GENERIC_READ, FILE_SHARE_READ,
      if (h != INVALID_HANDLE_VALUE) {
        HANDLE hfm = CreateFileMapping(h, NULL, PAGE_READ, 0, 0, NULL);
        if (hfm) {
          void *pv = MapViewOfFile(hfm, FILE_MAP_READ, 0, 0, 0);
          if (pv) {
            DWORD dwHeaderSum;
            if (CheckSumMappedFile(pvBase, GetFileSize(h, NULL),
                                   &dwHeaderSum, pdwResult)) {
              fRc = TRUE;
      return fRc;

    This code is still wrong, but it clearly looks like it's trying to be right. It is what I call "not-bad".

    Now here's some exception-based code you might write in a hurry:

    NotifyIcon CreateNotifyIcon()
     NotifyIcon icon = new NotifyIcon();
     icon.Text = "Blah blah blah";
     icon.Visible = true;
     icon.Icon = new Icon(GetType(), "cool.ico");
     return icon;

    (This is actual code from a real program in an article about taskbar notification icons, with minor changes in a futile attempt to disguise the source.)

    Here's what it might look like after you fix it to be correct in the face of exceptions:

    NotifyIcon CreateNotifyIcon()
     NotifyIcon icon = new NotifyIcon();
     icon.Text = "Blah blah blah";
     icon.Icon = new Icon(GetType(), "cool.ico");
     icon.Visible = true;
     return icon;

    Subtle, isn't it.

    It's easy to spot the difference between bad error-code-based code and not-bad error-code-based code: The not-bad error-code-based code checks error codes. The bad error-code-based code never does. Admittedly, it's hard to tell whether the errors were handled correctly, but at least you can tell the difference between bad code and code that isn't bad. (It might not be good, but at least it isn't bad.)

    On the other hand, it is extraordinarily difficult to see the difference between bad exception-based code and not-bad exception-based code.

    Consequently, when I write code that is exception-based, I do not have the luxury of writing bad code first and then making it not-bad later. If I did that, I wouldn't be able to find the bad code again, since it looks almost identical to not-bad code.

    My point isn't that exceptions are bad. My point is that exceptions are too hard and I'm not smart enough to handle them. (And neither, it seems, are book authors, even when they are trying to teach you how to program with exceptions!)

    (Yes, there are programming models like RAII and transactions, but rarely do you see sample code that uses either.)

  • The Old New Thing

    User interface design for interior door locks


    How hard can it be to design the user interface of an interior door lock?

    Locking or unlocking the door from the inside is typically done with a latch that you turn. Often, the latch handle is in the shape of a bar that turns.

    Now, there are two possible ways you can set up your lock. One is that the a horizontal bar represents the locked position and a vertical bar represents the unlocked position. The other is to have a horizontal bar represent the unlocked position and a vertical bar represent the locked position.

    For some reason, it seems that most lock designers went for the latter interpretation. A horizontal bar means unlocked.

    This is wrong.

    Think about what the bar represents. When the deadbolt is locked, a horizontal bar extends from the door into the door jamb. Clearly, the horizontal bar position should recapitulate the horizontal position of the deadbolt. It also resonates with the old-fashioned way of locking a door by placing a wooden or metal bar horizontally across the face. (Does no one say "bar the door" any more?)

    Car doors even followed this convention, back when car door locks were little knobs that popped up and down. The up position represented the removal of the imaginary deadbolt from the door/jamb interface. Pushing the button down was conceptually the same as sliding the deadbolt into the locked position.

    But now, many car door locks don't use knobs. Instead, they use rocker switches. (Forwards means lock. Or is it backwards? What is the intuition there?) The visual indicator of the door lock is a red dot. But what does it mean? Red clearly means "danger", so is it more dangerous to have a locked door or an unlocked door? I can never remember; I always have to tug on the door handle.

    (Horizontally-mounted power window switches have the same problem. Does pushing the switch forwards raise the window or lower it?)

Page 391 of 455 (4,543 items) «389390391392393»