May, 2006

  • The Old New Thing

    Do it for Katie


    A story in honor of Katie Couric's final day at the Today show.

    Last month I happened to run into a former member of the shell team who worked on the Windows XP Welcome screen. He told me a story from CES 2001, where Windows XP's interface (code-named Luna) was unveiled. There was going to be a segment on the Today show, and the Welcome screen was going to make an appearance, but the designers wanted to make one last tweak before it showed up on national television.

    Two hours before air time.

    So with a hard deadline of two hours, my colleague connected back to the computer at the office, made the requested changes, compiled a new binary, transferred it back to Las Vegas, installed it onto a laptop, and handed it over to the production crew. Everybody crossed their fingers.

    It worked.

    They did it for Katie.

  • The Old New Thing

    Mellifluous NPR reporter name: Ofeibea Quist-Arcton


    I first heard Ofeibea Quist-Arcton when she reported for the BBC. Now she's on NPR (you can listen to her discuss corruption in Nigeria in this recent report), thereby wresting the title of "most mellifluous NPR reporter name" from its previous holder, Sylvia Poggioli. (Sylvia Poggioli's dirty secret: She was born and grew up in the United States!)

    Other NPR personalities with cool-sounding names: Andrei Codrescu, Mandalit del Barco, Snigdha Prakash, and Eric Westervelt.

    Christiane Amanpour has a nice name, too, but she works for CNN, not NPR.

  • The Old New Thing

    People are very sensitive to how the icons look


    Windows XP shipped with new icons for many common items in the shell, and Windows Vista will have even more and newer icons. One of the things the designers have to be careful about with drawing these icons is to make sure they don't actually look like anything. Let me clarify.

    The folder icon, for example, is not based on any actual physical folder you can buy in the store. If it were a rendition of an actual folder, Windows would become vulnerable to a copyright infringement charge from the manufacturers of that folder. Instead, the manila folder icon is just something the designers made up from their fertile imagination.

    As another example, Windows XP came with new icons for the drives in your My Computer folder. One company complained that the icon for removable mass storage devices too closely resembled the drive manufactured by their competitor. The designers had to go back and draft a new icon that looked even less like any actual drives out on the market, yet which users would still recognize as a removal mass storage device.

    That's why icons can't look like anything.

  • The Old New Thing

    Every discipline has its crackpots: Stories of mathematics


    I'm sure every discipline has its share of crackpots. I suspect the physicists get it the worst, starting with the old standbys of perpetual motion machines and faster-than-light travel, then tossing in quantum mechanics and nuclear physics, and stirring with large quantities of long rambling text that makes no sense. But my experience is with mathematics.

    When I was in college, the mathematics department would post "interesting letters" onto the bulletin board. The ones I remember:

    • A claimed proof of Fermat's Last Theorem by means of music theory. It started with 3² + 4² = 5², then somehow converted this into musical notation, transposed it into another key, and then concluded that the proof was complete. There were many "proofs" of Fermat's Last Theorem on the bulletin board.
    • A letter from an inmate at a correctional facility who had developed a system for winning the lottery and merely needed a printout of all possible ways of choosing 6 numbers from a pool of 46.

    A number theorist working on factorization explained to me that he would frequently receive "manuscripts" from people who claim to have found a high-speed algorithm for factoring large numbers. At first, he would take the time to study these manuscripts, and each time he would determine that the algorithm boiled down to trial division, often cleverly-disguised trial division, but trial division nevertheless. (Though when this was pointed out, the authors often rejected his analysis.) Eventually, he realized that he could separate the wheat from the chaff very easily by simply replying with the following message:

    Thank you for your fascinating manuscript on the factorization of large numbers. There are some numbers that have been giving me difficulty of late. I would be most appreciative if you could use your technique to factor this one for me.

    Upon which he would include a number whose factorization would take years on generally-available computational hardware at the current state of understanding. He never heard back from these people.

    Another of my professors told a story of one "correspondent" who was convinced that the speed of light could be overcome. (Yes, that's actually a physics question, not a mathematics question, but it was sent to the math department anyway.) The professor started by trying to explain the principles of special relativity to his new pen-pal but quickly realized that wasn't going to lead anywhere. The correspondence was quite pleasant; the other person was a retired gentleman who gardened and enjoyed going for walks when he wasn't working on pushing the envelope of modern physics. At one point, the correspondent wrote back a multi-page letter consisting of crayon drawings that proved that the speed of light could be exceeded. It went something like this:

    The first page consisted of a drawing of the earth with a little rocket ship in orbit around it.

    Consider a rocket ship that circles the earth once a day. This rocket is travelling at 463.831019 meters per second.

    Say what you will, but these people never suffer from the problem of too few significant digits.

    Now imagine that each day, the time it takes to circle the earth SHRINKS IN HALF.
    So that on the SECOND DAY it takes only twelve hours to circle the earth at a speed of 927.662037 METERS PER SECOND.

    The rocket ship on the second day has a few extra zoom-lines on it.

    By the THIRD DAY it takes only SIX HOURS to circle the earth at a speed of 1855.32407 METERS PER SECOND.

    The rocket ship on the third day is going a little faster.

    Each page consisted of a daily status report on our little rocket ship, illustrated in glorious crayon, each drawing more elaborate than the last. As the rocket ship goes faster and faster, the report on its speed gets bigger and bigger. I'll skip ahead a bit.

    the rocket ship circles the earth in 164.794922 MILLISECONDS
    at a speed of 243,181,037 METERS PER SECOND.

    Finally, the hammer falls:

    the rocket ship circles the earth
    in only 82.3974609 MILLISECONDS
    at a speed of 486,362,075 METERS PER SECOND.

    The professor realized the jig was up. He wrote back, "Yes, it looks like you've done it."

  • The Old New Thing

    Wordplay (the movie)


    This morning I saw a screening of Wordplay, a documentary on crossword puzzles featuring Will Shortz. If you're a crossword puzzler, this movie is a must-see. In addition to Will, there are plenty of other rock stars of the crossword puzzle subculture who play major roles: Merl Reagle, Trip Payne, and Ellen Ripstein. (I was particularly amused by this entry. Hey, if you're not going to appreciate Ellen Ripstein's autograph, give it to somebody who will!)

    The audience loved this movie, laughing so hard in places that it drowned out the dialogue. (And gasping in horror when... well, you'll have to watch the movie to find out.) Crowd-pleasing one-liners (paraphrased):

    • Getting Merl Reagle to compose a Tuesday puzzle is like getting Barry Bonds to play on your Little League team. — Daniel Okrent reacts to seeing Merl Reagle's byline on a Tuesday puzzle. (Monday puzzles are easiest, with the difficulty increasing as the week progresses.)
    • I had a boyfriend who would put me down, but I would just come back with, "Oh yeah? And what are you the best in America at?" — Ellen Ripstein, 2001 American Crossword Puzzle Tournament champion.
    • "I hate, hate, hate, hate, hate you. Sincerely..." — Will Shortz reads a letter from a frustrated puzzle solver.

    As a recovering crossword-aholic myself, I found myself using the on-screen clues to race against Al Sanders as he himself raced the clock to solve a New York Times crossword. Although I'm no crossword slouch, I'm no match for Al Sanders.

    Wholeheartedly recommended.

  • The Old New Thing

    Assaulting users with dialog box after dialog box


    Increasingly, I'm seeing solving problems by adding more dialog boxes. Asking the user too much is as bad as not asking enough.

    "You clicked on the Notepad icon. Do you wish to run Notepad?"

    Okay, nobody would write a dialog box that stupid, would they? But the following dialog boxes don't really help much either:

    "You clicked on an mp3 file. Do you want to open it with that program you just installed?"

    "You clicked on an avi file. Do you want to open it with that program you just installed?"

    "You clicked on an mpg file. Do you want to open it with that program you just installed?"

    "You clicked on a wmv file. Do you want to open it with that program you just installed?"

    "You clicked on a wma file. Do you want to open it with that program you just installed?"

    A phenomenon known as "Dialog box fatigue" quickly sets in (with a big dose of "You stupid computer" thrown in for good measure). The system today is already filled with so many dialog boxes that users are conditioned just to click "Yes" to everything. If you click "Yes", then the computer does the thing you told it do. If you click "No", then nothing happens. In other words, users have already learned to interpret these dialog boxes as saying "Click Yes to do the thing you want to do or No to give up and cancel." Why would anybody click "No"?

    Moving to the specific case of programs that display media content: I am led to believe that all the media players include a page in their install wizard that list the file types they are capable of playing and give you a chance to check/uncheck the ones you want them to assume responsibility for. I believe this was the armistice that resulted after a bunch of industry wrangling wherein companies were busy accusing each other of sabotaging each other's file types. The upshot is that all reputable media players have already gotten your permission to take over playback of those media types. Why ask the user to confirm something they have already confirmed? "Stupid computer."

    Okay, so those dialog boxes are unnecessary for reputable media players. What about the disreputable ones? Well, once you've established that you're dealing with disreputable media players, they're just going to go in and hack the settings to say, "Oh, the user already confirmed this take-over, don't bother asking. It's all good."

    So you now have a dialog box that (1) is redundant with reputable media players, and (2) has no effect for disreputable media players. What did this dialog box accomplish again?

  • The Old New Thing

    Using Yoda on an x86 may be hazardous to your systems' health


    In former times very cross-platform NTVDM was.

    If you view NTVDM.EXE in a hex editor, you'll find the message "Using Yoda on an x86 may be hazardous to your systems' health" buried inside it. Yoda was the name of the internal debugger that was used to debug the MS-DOS emulator, also known as the Virtual DOS Machine or VDM. (Buried inside the Yoda source code are such wonderful variables as "luke" and "chewy".)

    The Intel 80386 has a mode known as "Virtual-8086 mode" or just "V86 mode" wherein the CPU ran as if it were an 8086, except that if the program did anything interesting like issue a privileged instruction, call a software interrupt, or fault, control would return to the protected-mode supervisor for handling. (Win386 used this same CPU mode to support multiple MS-DOS sessions.) When running on an 80386-class processor, NTVDM used this mode to do its emulation, making the CPU do the heavy lifting of decoding instructions and emulating them, which took place at very close to full speed.

    On the other hand, NTVDM on the non-x86 processors (Alpha, PPC, MIPS, etc.) had to implement an entire 8086 emulator, with all the decoding and execution performed in software. Yoda was the debugger you used if you needed to debug the emulator.

    And that's why NTVDM has a message warning you not to use Yoda on an x86. Because on an x86, there is no instruction emulator. There is nothing to debug.

    (My thanks to Andrew McLaren and Tony Gaston for providing historical background.)

  • The Old New Thing

    Beware the C++ implicit conversion


    Today's topic was inspired by a question from a customer:

    I am working on a stack overflow bug. To reduce the size of the stack frame, I removed as many local variables as I could, but there's still a a lot of stack space that I can't account for. What else lives on the stack aside from local variables, parameters, saved registers, and the return address?

    Well, there's also structured exception handling information, but that's typically not too much and therefore wouldn't be the source of "a lot" of mysterious stack usage.

    My guess is that the code is generating lots of large C++ temporaries. Consider the following program fragment:

    class BigBuffer
     BigBuffer(int initialValue)
       { memset(buffer, initialValue, sizeof(buffer)); }
     char buffer[65536];
    extern void Foo(const BigBuffer& o);
    void oops()

    "How does this code even compile? The function Foo wants a BigBuffer, not an integer!" Yet compile it does.

    That's because the compiler is using the BigBuffer constructor as a converter. In other words, the compiler inserted the following temporary variable:

    void oops()
     BigBuffer temp(3);

    It did this because a constructor that takes exactly one argument serves two purposes: It can be used as a traditional constructor (as we saw with BigBuffer temp(3)) or it can be used to provide an implicit conversion from the argument type to the constructed type. In this case, the BigBuffer(int) constructor is being used as a conversion from int to BigBuffer.

    To prevent this from happening, use the explicit keyword:

    class BigBuffer
     explicit BigBuffer(int initialValue)
       { memset(buffer, initialValue, sizeof(buffer)); }
     char buffer[65536];

    With this change, the call to Foo(3) raises a compiler error:

    sample.cpp: error C2664: 'Foo' : cannot convert parameter 1 from
         'int' to 'const BigBuffer &'
         Reason: cannot convert from 'int' to 'const BigBuffer'
         Constructor for class 'BigBuffer' is declared 'explicit'
  • The Old New Thing

    Raymond makes a psychic prediction for 2006


    I have gazed into my crystal ball and emerged with a prediction for 2006. Revealing my prediction now may influence the event itself, so I will post only the hash for the prediction. I will post the actual prediction at the end of the year.

    using System.Security.Cryptography;
    using System;
    class Prediction {
     static void DoHash(byte[] bytes, string name, HashAlgorithm hash)
      byte[] result = hash.Hash;
      for (int i = 0; i < result.Length; i++) {
       Console.Write("{0:X2}", result[i]);
       if (i % 32 == 31) Console.WriteLine();
      if (result.Length % 32 != 0) Console.WriteLine();
     static void Main()
      string msg = "prediction goes here";
      Console.WriteLine("length {0}", msg.Length);
      byte[] bytes = (new System.Text.ASCIIEncoding()).GetBytes(msg);
      DoHash(bytes, "MD5", MD5.Create());
      DoHash(bytes, "SHA1", SHA1.Create());
      DoHash(bytes, "SHA256", SHA256.Create());
      DoHash(bytes, "SHA384", SHA384.Create());
      DoHash(bytes, "SHA512", SHA512.Create());

    The output of this program (after you replace "prediction goes here" with the actual prediction, of course) is as follows:

    length 45
  • The Old New Thing

    That mysterious J


    In e-mail from Microsoft employees, you may find a stray J like this one at the end of a message from Rico Mariani. Some of you might see it; others might not. What's the deal with the J?

    The J started out its life as a smiley-face. The WingDings font puts a smiley face where the letter J goes. Here, let me try: <FONT FACE=WingDings>J</FONT> results in J. As the message travels from machine to machine, the font formatting may get lost or mangled, resulting in the letter J appearing when a smiley face was intended. (Note that this is not the same as the smiling face incorporated into Unicode as U+263A, which looks like this: ☺. Some of you might see it; others might not.)

    I recall a story (possibly apocryphal) of somebody who regularly exchanged a lot of e-mail with Microsoft employees and who as a result started signing their own messages with a J, figuring this was some sort of Microsoft slang. The Microsoft employees who got the J-messages scratched their heads until they were able to figure out how their correspondent arrived at this fabulous deduction.

    And now, the mysterious J has come full circle, because some people use it ironically, intentionally just writing a J without setting the font, in the same way people making fun of "leet" writing may "accidentally" type "1"s (or even more absurdly, the word "one") into a row of exclamation points.

Page 1 of 4 (35 items) 1234