May, 2008

  • The Old New Thing

    The dead desktop computer: From good, bad, and ugly back to dead

    • 41 Comments

    When last we left my dead desktop computer, it had returned to the world of the living with the assistance of the onboard video adapter. The screen was fuzzy because I was running my LCD monitor through the analog VGA cable. Performing an auto-adjust helped a little but it was still blurry. Still, it was within the realm of acceptability for casual low-volume use.

    Well, the computer once again died, and before it finally kicked the bucket, the onboard video card started pumping out corrupted pixels. My suspicion that my motherboard ate video cards was correct. In fact, its appetite for video cards was so voracious, it ate itself.

    Okay, so here are the options I've been able to come up with so far.

    1. Feed the computer video cards.
    2. Replace just the motherboard.
    3. Replace the entire computer.

    The first option is out because the rate of consumption appears to be one video card per month, which is a rather expensive diet.

    The second option is a possibility, but the computer was purchased pre-assembled from a name-brand manufacturer, so the odds of finding a motherboard that exactly fits into the original case are pretty slim. I'll probably have to move everything to a new case.

    The third option is the lazy way out, and is in fact the solution employed by most non-technical users.

    For now I'm going to investigate option two. I'll have to take the computer apart to get at the motherboard anyway, and then I can investigate what type of replacement I need to get. (In terms of socketry and stuff.) Though who knows how long it will be before I actually get around to fixing the computer.

    Meanwhile, my laptop which was manufactured back in 2000 continues to chug along happily.

  • The Old New Thing

    Why always "Windows XP" and "Windows Vista" and not just "XP" and "Vista"?

    • 53 Comments

    When the Internet Explorer folks announced that they were going to call their next version of Internet Explorer Internet Explorer 7 for Windows XP and Internet Explorer 7 in Windows Vista, many people responded to the awkward name by suggesting that it be shortened to Internet Explorer 7 XP and Internet Explorer 7 Vista. Why the longer names?

    Lawyers.

    Microsoft's own trademark guidelines† specify that the product names are Windows XP and Windows Vista and not just XP and Vista. The trademark is on the entire phrase, not just the last word. Furthermore, the trademark guidelines specify that products may not append just XP or Vista to their names; they have to say X for Windows XP or X for Windows Vista.

    In an earlier era, you had to be careful to say Windows NT and not just NT for the same reason. You see, the name NT is a registered trademark of Northern Telecom, and part of the agreement with "the other NT" is that the Windows product would always be used with the word Windows in front.

    If you took a close look at the Windows 2000 box, you may have seen the phrase "Built on NT Technology." I don't know how hard it was to do, but I suspect a good amount of negotiations with Northern Telecom took place to allow Microsoft to use that alternate formulation without the word Windows in front. Indeed, if you looked really closely at the box, you'd have found a trademark acknowledgement for Northern Telecom deep in the fine print.

    Lawyers by training are very cautious people. After all, a new lawsuit against Microsoft gets filed approximately once every thirty seconds.¶ They're probably also responsible for all your Office# shortcuts on the Start menu being named Microsoft Office This 2007 and Microsoft Office That 2007 instead of This 2007 and That 2007, or even (shocking!) just This and That. It's a daring move, and lawyers don't like to be daring. Nobody ever got sued for playing it safe.††

    Nitpicker's corner (guest appearance)

    *Just burning off a footnote marker because I don't like asterisks.

    †I myself violate some of these guidelines because I try to write like a human being and not a robot. Only robots say Windows-based programs.‡

    ‡That statement is not literally true. Here's a reformulation of that statement for the benefit of robots:§ "People who say Windows-based programs sound like robots."

    §That statement is also not literally true. Here's a reformulation of that statement for the benefit of people who take a robotic approach to reading: "Here's a reformulation of that statement for the benefit of people who take a robotic approach to reading:"

    ||Burning off another footnote marker because I don't like parallel lines either.

    ¶An exaggeration, not a statement of fact.

    #s/Office/Microsoft® Office™ System/**

    **I have not researched whether that's the correct way of writing it.

    ††Okay, maybe somebody somewhere has gotten sued for playing it safe. It was just a catchy sentence, not a statement of fact.

  • The Old New Thing

    The Big Red Switch really was big and red

    • 34 Comments

    In this article on compatibility between the .NET Framework versions 1.1 and 2.0, there is a passing mention of a setting nicknamed the "Big Red Switch".

    The power switch on the original IBM PC really was big and red. Well, orange-red. Here's a picture of the power switch on an IBM PC-AT. Decide for yourself what color it is.

    In college, the hallway that led to the basement lab where most of the computer science students did their work had a big red switch, a pushbutton, labeled "Emergency power shutoff". Nobody was sure whether it actually was hooked up to anything or was simply a joke, but nobody wanted to take the chance of finding out, either. I remember one evening some people were goofing off with a basketball, and somebody missed a pass, and the ball hit the wall dangerously close to the big red switch. They (and everybody in the lab) immediately realized what had almost happened, and the group sheepishly took their ball outside.

    Some time later, the legend of the big red switch was ultimately resolved. The morning after a particularly bad rainstorm, one of my colleagues came into the computing center and explained that he had gone down to the computer lab the previous evening and found it flooded, with water still coming in. Realizing that electricity plus water equals danger, he went over to the big red switch and pushed it. And true to its label, it shut off the power to the lab and the central file server. We were all in awe that he got to push the big red button for a legitimate reason. An opportunity like that comes only once in a lifetime.

  • The Old New Thing

    In Lisbon, walk/don't walk signs are mostly decorative

    • 40 Comments

    In Lisbon, walk/don't walk signs are mostly decorative. The real rule for crossing the street is look both ways and cross when safe. There's no requirement that you use a designated crosswalk. As long as the coast is clear, you can cross the street anywhere. When my host for the conference accompanied me to the conference center, we crossed the street and my host pointed out, "You know, we're actually using the official crosswalk this time."

    I was talking with one of the faculty members of the computer science department at IST and mentioned that in Seattle, the police issue tickets for crossing the street incorrectly. The faculty member responded, "In Portugal, there is no such thing as crossing the street incorrectly."

    (For what it's worth, people in Madrid restrict themselves to crossing at crosswalks and generally observe the walk/don't walk signs, although if the light says don't walk and there are no cars anywhere nearby, they will cross anyway. This evaluation of Madrid crosswalk behavior is probably skewed by the higher concentration of tourists.)

  • The Old New Thing

    How do I flash my window caption and taskbar button manually?

    • 19 Comments

    Commenter Jonathan Scheepers wonders about those programs that flash their taskbar button indefinitely, overriding the default flash count set by SysteParametersInfo(SPI_SETFOREGROUNDFLASHCOUNT).

    The FlashWindowEx function and its simpler precursor FlashWindow let a program flash its window caption and taskbar button manually. The window manager flashes the caption automatically (and Explorer follows the caption by flashing the taskbar button) if a program calls SetForegroundWindow when it doesn't have permission to take foreground, and it is that automatic flashing that the SPI_SETFOREGROUNDFLASHCOUNT setting controls.

    For illustration purposes, I'll demonstrate flashing the caption manually. This is generally speaking not recommended, but since you asked, I'll show you how. And then promise you won't do it.

    Start with the scratch program and make this simple change:

    void
    OnSize(HWND hwnd, UINT state, int cx, int cy)
    {
      if (state == SIZE_MINIMIZED) {
        FLASHWINFO fwi = { sizeof(fwi), hwnd,
                           FLASHW_TIMERNOFG | FLASHW_ALL };
        FlashWindowEx(&fwi);
      }
    }
    

    Compile and run this program, then minimize it. When you do, its taskbar button flashes indefinitely until you click on it. The program responds to being minimzed by calling the FlashWindowEx function asking for everything possible (currently the caption and taskbar button) to be flashed until the window comes to the foreground.

    Other members of the FLASHWINFO structure let you customize the flashing behavior further, such as controlling the flash frequency and the number of flashes. and if you really want to take control, you can use FLASHW_ALL and FLASHW_STOP to turn your caption and taskbar button on and off exactly the way you want it. (Who knows, maybe you want to send a message in Morse code.)

  • The Old New Thing

    Mother's Day is for all mothers, not just your own mother

    • 28 Comments

    This upcoming Sunday is Mother's Day in the United States, and I'm reminded of a little story from several years ago.

    One day, we asked a colleague how he and his new child were planning to celebrate Mother's Day.

    "Yup, I'm all over that. I mailed a gift to my mother earlier this week, and I'll call her on Sunday."

    — Um, aren't you forgetting somebody?

    "I'm not sure what you're talking about."

    — What about your wife Betty?

    A beat.

    "I should do something for Betty's mother?"

    Let this be a cautionary tale for new fathers.

  • The Old New Thing

    Data breakpoints are based on the linear address, not the physical address

    • 6 Comments

    When you ask the debugger to set a read or write breakpoint, the breakpoint fires only if the address is read from or written to by the address you specify. If the memory is mapped to another address and modified at that other address, then your breakpoint won't see it.

    For example, if you have multiple views on the same data, then modifications to that data via alternate addresses will not trigger the breakpoint.

    The hardware breakpoint status is part of the processor context, which is maintained on a per-thread basis. Each thread maintains its own virtualized hardware breakpoint status. You don't notice this in practice because debuggers are kind enough to replicate the breakpoint state across all threads in a process so that the breakpoint fires regardless of which thread triggers it. But that replication typically doesn't extend beyond the process you're debugging; the debugger doesn't bother replicating your breakpoints into other processes! This means that if you set a write breakpoint on a block of shared memory, and the write occurs in some other process, your breakpoint won't fire since it's not your process that wrote to it.

    When you call into kernel mode, there is another context switch, this time between user mode and kernel mode, and the kernel mode context of course doesn't have your data breakpoint. Which is a good thing, because if that data breakpoint fired in kernel mode, how is your user-mode debugger expected to be able to make any sense of it? The breakpoint fired when executing code that user mode doesn't have permission to access, and it may have fired while the kernel mode code owned an important critical section or spinlock, a critical section the debugger itself may very well need. Imagine if the memory were accessed by the keyboard driver. Oops, now your keyboard processing has been suspended. Even worse, what if the memory were accessed by a a hardware interrupt handler? Hardware interrupt handlers can't even access paged memory, much less allow user-mode code to run.

    This "program being debugged takes a lock that the debugger itself needs" issue isn't usually a problem when a user-mode debugger debugs a user-mode process, because the locks held by a user-mode process typically affect only that process. If a process takes a critical section, sure that may deadlock the process, but the debugger is not part of the process, so it doesn't care.

    Of course, the "debugger is its own world" principle falls apart if the debugger is foolish enough to require a lock that the program being debugged also uses. Debugger authors therefore must be careful to avoid these sorts of cross-process dependencies. (News flash: Writing a debugger is hard.) You can still run into trouble if the program being debugged has done something with global consequences like create a fullscreen topmost window (thereby covering the debugger) or installed a global keyboard hook (thereby interfering with typing). If you've tried debugging a system service, you may have run into this sort of cross-process deadlock. For example, if you debug the service that is responsible for the networking client, and the debugger tries to access the network (for example, to load symbols), you've created a deadlock since the debugger needs to access the network, which it can't do because the networking service is stopped in the debugger.

    Hardware debugging breakpoints are a very convenient tool for chasing down bugs, but you have to understand their limitations.

    Additional reading: Data breakpoint oddities.

  • The Old New Thing

    The economics of soccer penalty kicks

    • 20 Comments

    I'm fascinated by economics, specifically the application of economic theories to things you wouldn't normally consider as economics. Back during the World Cup, Slate's undercover economist column took a look at the economics of penalty kicks.

    Steven D. Levitt, co-author of another paper on the subject, writes in more detail on the unusually low percentage of penalty kicks taken straight ahead. I wasn't aware of the "straight ahead" strategy, but the more I read about it (and watched a video of a successful execution) the more fascinated I was by this rarely-used strategy.

    Levitt highlighted the "anti-straight-ahead bias" of the press, pointing out that the second Swiss shooter hit the crossbar and was not lambasted. But isn't that worse than shooting straight ahead and being stopped? I mean, if you hit the crossbar, it means that the opposing goalie didn't even have to be there. He could've been playing Nintendo or picking his nose. You'd think the cardinal rule of taking a penalty kick is at least make it a shot on goal.

  • The Old New Thing

    Gentle reminder: On a dialog box, do not give OK and Cancel accelerators

    • 34 Comments

    I know most of you know this, but I'm going to say it for the record. When you have a dialog box with an OK and/or Cancel button, do not give the keys accelerators. In other words, simply write

        DEFPUSHBUTTON "OK", IDOK, ...
        PUSHBUTTON "Cancel", IDCANCEL, ...
    

    The dialog manager already has those buttons covered. The hotkey for the OK button is Enter (since it is the default pushbutton), and the hotkey for the Cancel button is ESC (since its ID is IDCANCEL).

    Note of course that during the lifetime of a dialog box, the default pushbutton may change, but the principle still stands: Do not give the OK button a keyboard accelerator.

    Oh, and while you're there, don't forget that the recommended minimum size for pushbuttons is 50dlu by 14dlu.

  • The Old New Thing

    The new dietary restriction landscape

    • 25 Comments

    Non appetit, the modern quandary of preparing a dinner for people who all have different types of dietary restrictions. Depending on whom I invite to dinner, I may have to put together a meal that conforms to one or more of the following restrictions: low-fat, pescetarian, vegetarian, nondairy, non-pork, non-beef. (Yes, many of these categories overlap.) To the best of my knowledge, none of my dinner guests have had nut allergies or been gluten intolerant.

    I remember telling a story once and mentioning that the subject of the story was a vegetarian. The person I was telling the story to (who is from an older generation) asked, "Are they so poor that they can't afford meat?" Because in an older era, people were vegetarians because they had no choice.

Page 3 of 4 (39 items) 1234