December, 2005

  • The Old New Thing

    Music to slip into a playlist to see if anybody is listening


    When I was visiting my brother earlier this year, I found this CD in my sister-in-law's collection. Oy vey's mir! There's just something fundamentally wacked out about the whole idea. (Maybe that's why I liked it. Here's what other people think.)

  • The Old New Thing

    Beware the Image File Execution Options key


    Beware the Image File Execution Options key (more). Its power can be used for evil as well as for good.

    Its intended use is to force a program to run under a debugger regardless of how it is launched (and secondarily to alter how the system treats the program). It's handy if you need to debug a program "in the wild" rather than under the controlled environment of your favorite IDE. For example, you can use it if you want to debug how a program runs when it is launched by some other program you can't debug.

    Two things people often forget:

    • If you err in specifying the debugger, the program won't launch at all. For example, if you get the path to the debugger wrong or if you subsequently uninstall the debugger, you'll get ERROR_FILE_NOT_FOUND when you try to run the target program since the system can't find the debugger.
    • Remember to delete the entry for your program when you no longer need it. Otherwise you'll wonder why the debugger keeps launching for no apparent reason.

    Evil can be done with the Image File Execution Options key. Malware can install themselves as the "debugger" for a frequently-run program (such as Explorer) and thereby inject themselves into the execution sequence.

    Note that the ability to use the Image File Execution Options key for evil purposes is not a security hole. To modify the key in the first place requires administrator permissions. Consequently, anybody who can exploit this feature already owns your machine.

  • The Old New Thing

    The Dead Sea Scrolls are coming to Seattle


    Coming to the Pacific Science Center in September 2006 the Dead Sea Scrolls, "considered by many experts to be the most significant archaeological find of the twentieth century". Tickets went on sale yesterday. Volunteer opportunities also available.

  • The Old New Thing

    When hyperthreading is enabled, all the processors are virtual


    A common problem when answering technical questions is that people sometimes ask a question that can't or shouldn't be answered because it is based upon a misunderstanding. What's particularly frustrating is when they insist that you answer their question as posed, even when you try to explain to them that their question is itself flawed.

    It's as if somebody asked you the question, "Do I have to use the remote control to lock my kangaroo?" You could answer the question literally ("No"), but the person asking the question would walk away with the wrong conclusion ("Wow, kangaroos are self-locking!"). Robert Flaming recalls a similar analogy I made with balsa wood and nails.

    Here's an example of a question that betrays misunderstanding.

    I just enabled hyperthreading on my dual-Xenon machine, and Task Manager now shows four processors instead of two. Which of them are the physical processors and which are the virtual ones?

    When you turn on hyperthreading, each individual physical processor acts as if it were two virtual processors. From Task Manager's point of view, the computer has four virtual processors. The two virtual processors associated with each physical processor are completely equivalent. It's not like one is physical and one is virtual. They are both virtual and compete equally for a share of the one physical CPU. When you set processor affinities, you set them to virtual processors.

    To find out which virtual processors are associated with the same physical processor, you can call the GetLogicalProcessorInformation function.

  • The Old New Thing

    A note to headhunters: Check your links


    If you're going to try to recruit me, you might want to check that the links in your email actually work.

    Just sayin'.

    I'm going to mock you regardless, but you should at least make me have to work for it.

  • The Old New Thing

    You probably don't want to run programs directly off your USB memory drive


    You probably wouldn't want to run Windows or applications directly off your USB memory drive, even if you could. The reason is that the solid-state memory used by these drives support only a limited number of write cycles per block. (Originally measured in the thousands, though I'm led to believe that it's gone up since then.) Most software assume that a disk's lifetime is essentially infinite and have no qualms about writing to a file multiple times. For example, your program might decide to group its data in chunks. To modify a byte of the file, you would load a chunk, modify the byte, then write the chunk out. You've "spent" a write cycle for an entire chunk of data even though you really might have been able to get away with updating a single sector. What's more, if that one byte gets modified three times in a row, you just paid for three writes when you could have gotten away with just one if you had just done a little more caching.

    Operating systems often update a file's metadata with high frequency. The last-modified time on a directory entry gets rewritten each time the file is updated. The free block bitmap is updated each time disk space is allocated or released. The page file gets updated constantly. A database application will update its database index very frequently. Even a simple application will probably update its history and settings files often. These "hot spots" are most likely to wear out first on a drive. Unfortunately, these hot spots also tend to coincide with nonrelocatable critical file system metadata; as a result, once the sector responsible for, say, the free cluster table goes bad, the drive is useless (in the absence of hardware sector remapping).

    I know some people who wrote a so-called "Flash File System" specifically designed for this class of devices. It spread the writes out across the disk so that it wore uniformly, avoiding the "hot spot" problem. The file system came out in the early 1990's and promptly died because the hardware hadn't yet caught up to the software. It was a solution ahead of its time.

    Note that my information about the number of write cycles of flash memory is pretty old. Can modern USB drives handle millions of writes before wearing out?

  • The Old New Thing

    Whole lotta cranking going on


    Slashdot covered hand-cranked radios and other electronica a while ago. I keep an old-model Freeplay flashlight in the trunk of my car. It sort of fits the whole energy-counter-culture ethos, since I drive an early-model Toyota Prius.

    Freeplay is a South African company, and one of my South African colleagues pointed out that the Freeplay devices sold in South Africa are heavier than the ones sold in the States. Not for any technical reason, mind you. It's psychological, I'm told. Apparently, in South Africa, you want your equipment to be good and heavy, since that makes it seem solid and dependable.

    When I was in London a few years ago, I joined a friend in a day trip to the Victoria and Albert Museum. The museum is far too large for you even to pretend to see it all so we created for ourselves a one-day tour on the theme "The history of British furniture from 1500 to the present". Yeah, it sounds stupid on paper, but it was actually quite fun. (We saw how the British were fond of Japanese teacups but couldn't get over the fact that they don't have handles. They solved this problem by building a metal cage with a handle; into the cage was placed the teacup. Now you can drink your tea out of the lovely Japanese teacup with the added civility of a proper handle. Yet for some reason, this didn't catch on in Japan.) When we got to the late twentieth century, one of the items on display was... a Freeplay radio.

  • The Old New Thing

    On the ambiguity of uniqueness


    The MSDN documentation for System.Object.GetHashCode says

    [T]he implementation of GetHashCode provided by the String class returns unique hash codes for unique string values.

    This is another case of ambiguous use of the word "unique". The intended meaning is "for each string value, the same hash code is returned".

    Even though "unique" means "one and only one", the domain in which the term applies is often left unsaid, as here, where the domain of comparison is "all the hash codes returned for a specific string value". If you instead misinterpreted the domain as "all the hash codes returned for all string values", then you end up erroneously concluding that no two strings hash to the same value.

    Another conflicting sense of "unique" is "you get the same one each time" as opposed to "you get a different one each time".

    • GetCurrentProcessId returns a unique value that identifies the process. You get the same one each time.
    • CoCreateGuid returns a unique GUID. You get a different one each time.

    In the original C standard, malloc(0) is permitted to return NULL or "a unique pointer". What does "unique" mean here? Does it mean that the non-NULL return value is always the same? Can I assert(malloc(0) == malloc(0))? Or does it mean that the non-NULL return value is a value distinct from any other return value from malloc()?

    In Technical Corrigendum 1, this ambiguity was resolved by removing the word "unique". Instead, the specification says "as if the size were some nonzero value" which makes it clear that it is the second interpretation that is intended.

    My suggestion: Don't use the word "unique". It's too ambiguous.

  • The Old New Thing

    We Microsoft bloggers do talk to each other occasionally, y'know


    Every so often, somebody will spam all the Microsoft blogs with a survey or a plea for a job or some other boilerplate message. Don't think you're fooling anyone. It's not like each blogger lives in a separate world and never talks to anyone else. In reality, we exchange information quite freely and even occasionally get together—usually under the aegis of our overworked leader Betsy—for an informal face-to-face (usually lubricated with beer).

    Which reminds me: That April get-together was held at Fadó Seattle, and at some point during the evening, I excused myself and went into the main part of the pub. I headed for what appeared to be a promising hallway, but which instead was merely a large wall covered in thematic decorations. I scanned the wall for a few seconds, then someone walking past said to me, "It's over there, through that room, on your left."

    I found it intriguing that the gentleman knew exactly what I was looking for based on the fact that I was staring at a wall at the edge of a bar near the kitchen entrance.

  • The Old New Thing

    Experiencing the world from flight level 210


    Here are some airline-related web logs that I follow.

    • Fly with Me, a sort-of monthly podcast from a professional airline pilot. A glimpse into the world behind that cockpit door.
    • Flight Attendant Betty, another podcast, this one from your friendly flight attendant. (Though I have to admit, in Episode 2, I skipped over the disaster story and listened just to the stories of the world's stupidest hijackers.)
    • Yu Hu Stewardess, a flight attendant who isn't afraid to talk about all the stupid passengers she has to put up with (Do you recognize yourself?) and talk about what life is like when you spend a significant fraction of your nights away from home.
    • Doing Boeing, the web log of a Boeing database administrator. From the original technology company in the Seattle area.
    • The 777 Flight Test Journal. I had been looking for something to replace Randy Baseler's blog in my Boeing blogroll because Randy's was just all marketing hot air. The Flight Test Journal still feels a bit too heavily-managed, but it's a big improvement.

    Ry Jones recommends FlightAware, a web site for all your planespotting needs.

Page 2 of 4 (33 items) 1234