January, 2007

  • The Old New Thing

    Iced-over roads + people who can't drive = very expensive (and dangerous) game of billiards

    • 64 Comments

    Unbelievable video of people in Portland, OR who should know better trying to drive down an icy road. (Direct WMV link. Interview with the person who shot the video, but you're going to have to put up with the inane local news-anchor chatter. That last link includes images of cars that, yup, struck the fire truck.)

    It's as if these people had lost control of all rational thought. When your car slowly skids to a halt after crashing into a half dozen stopped cars and other roadside obstacles, your brain should be telling you, "Boy, that was a really stupid idea. I should stop now before I kill myself or a pedestrian." You do not punch the gas and accelerate into other cars like it's a demolition derby.

    I hope their insurance company sees this video.

  • The Old New Thing

    The family technical support department: Everything is Outlook

    • 63 Comments

    We're all in the same position. Since we work with computers all day, everybody in the extended family considers us the technical support department. One thing you all need to take away from your role as family technical support department is that normal people view computers completely differently from the way you and I do.

    One of my relatives calls every program Outlook.

    "I'm on the Internet checking the weather report and then Outlook keeps displaying these windows with advertisements in them."

    "I'm having trouble listening to music on Outlook."

    "How do I get Outlook to play that card game you showed me last time?"

    "I tried to save my spreadsheet and Outlook gave me this weird error message."

    Why is every program called Outlook?

    At work, this particular relative received word that the computer systems were being upgraded. The old system was a dedicated CAD system, but the new computers were PCs running CAD software and Outlook.

    "Okay, I know what CAD software is. That's what I've been doing for the past five years on the old system. Therefore, by process of elimination, everything else on the computer must be Outlook."

    When they got a home computer a year later, it didn't come with any CAD software on it. It was all Outlook.

    (One of my colleagues is in a similar position: His relatives call everything on the computer Microsoft X. It could be Microsoft Norton Utilities or Microsoft Quicken. I wouldn't be surprised if they even said Microsoft Google.)

    My colleague KC Lemson is in the unfortunate position of being the "Outlook expert" in her family, despite having not worked on Outlook for six years. It turns out that there have been a lot of versions of Outlook released since then, so her specialized knowledge is pretty badly outdated. That doesn't stop them from trying, though.

    She told me that she attended a family wedding some time ago, and heard from three separate people, "Oh, Alice [not her real name] has an Outlook question for you." The effect of this was perhaps not what those people expected, because KC spent the entire wedding trying to avoid Alice. KC explained, "If she'd just come up and asked the question herself, I probably would have been fine with it, but having such an early warning just scared me. Plus, sniff sniff, you want to be wanted for who you are and not what you know."

  • The Old New Thing

    Should all windows appear in the taskbar?

    • 63 Comments

    No new content today, just some follow-up discussion on the topic of windows that don't appear in the taskbar. The rules for which windows appear in the taskbar have been documented in MSDN for years, so changing the rules now would mean doing so after the game has ended. Consequently, this is not the sort of change that can be made lightly.

    First point is that the taskbar is called the "taskbar" and not something like the "open windows bar". The name already suggests that the purpose is to display tasks, not open windows. I find it interesting that people, in their zeal to turn the taskbar into a "windows bar" end up removing other features, such as "How do I make a window appear in the Alt+Tab list but not in the taskbar?" Are the people who want to create such a window "just plain wrong"? (There are so many of these people that the Windows Forms folks added a ShowInTaskbar property just for this purpose!) Think about it the next time you complain that Windows doesn't let you do something—there is somebody just like you on the other side who said, "No, that's just plain wrong". Besides, if you decided that all windows must appear in the taskbar, that means that the taskbar would be cluttered with tooltip windows, floating toolbars, desktop toolbars (those things that stick to the edge of the desktop), all sorts of stuff. Do you really want that?

    "The point of the taskbar is to show you what you have open." Strange, I don't remember you at the design meetings or the usability sessions.

    One commenter noted that it took "several service packs" before Microsoft "fixed" the "problem" where property sheets didn't appear in the Alt+Tab list. That was actually a design decision. I remember asking this question at the internal meeting when the new user interface was revealed. The answer was, "If you want to re-open the property sheet from the keyboard, just go back to the original object and ask to see its properties again." You may not like that decision (I sure didn't), but it wasn't a bug. It was on purpose. (A decision which was revisited and changed in Windows 2000, by the way, not a service pack.)

    Another commenter argued that any windows that don't appear in the taskbar should be always-on-top. I suspect a lot of people would be upset that all property sheets suddenly became always-on-top. Among other things, it would mean that you would have to close all your property sheets and control panels before you ran a business presentation or played a game.

  • The Old New Thing

    What('s) a character!

    • 53 Comments

    Norman Diamond seems to have made a side career of harping on this topic on a fairly regular basis, although he never comes out and says that this is what he's complaining about. He just assumes everybody knows. (This usually leads to confusion, as you can see from the follow-ups.)

    Back in the ANSI days, terminology was simpler. Windows operated on CHARs, which are one byte in size. Buffer sizes were documented as specified in bytes, even for textual information. For example, here's a snippet from the 16-bit documentation for the GetWindowTextLength function:

    The return value specifies the text length, in bytes, not including any null terminating character, if the function is successful. Otherwise, it is zero.

    The use of the term byte throughout permitted the term character to be used for other purposes, and in 16-bit Windows, the term was repurposed to represent "one or bytes which together represent one (what I will call) linguistic character." For single-byte character sets, a linguistic character was the same as a byte, but for multi-byte character sets, a linguistic character could be one or two bytes.

    Documentation for functions that operated on linguistic characters said characters, and functions that operated on CHARs, said bytes, and everybody knew what the story was. (Mind you, even in this nostalgic era, documentation would occasionally mess up and say character when they really meant byte, but the convention was adhered to with some degree of consistentcy.)

    With the introduction of Unicode, things got ugly.

    All documentation that previously used byte to describe the size of textual data had to be changed to read "the size of the buffer in bytes if calling the ANSI version of the function or in WCHARs if calling the Unicode version of the function." A few years ago the Platform SDK team accepted my suggestion to adopt the less cumbersome "the size of the buffer in TCHARs." Newer documentation from the core topics of the Platform SDK tends to use this alternate formulation.

    Unfortunately, most documentation writers (and 99% of software developers, who provide the raw materials for the documentation writers) aren't familiar with the definition of character that was set down back in 1983, and they tend to use the term to mean storage character, which is a term I invented just now to mean "a unit of storage sufficient to hold a single TCHAR." (The Platform SDK uses what I consider to be the fantastically awkward term normal character widths.) For example, the lstrlen function returns the length of the string in storage characters, not linguistic characters. And any function that accepts a sized output buffer obviously specifies the size in storage characters because the alternative is nonsense: How could you pass a buffer and say "Please fill this buffer with data. Its size is five linguistic characters"? You don't know what is going into the buffer, and a linguistic character is variable-sized, so how can you say how many linguistic characters will fit? Michael Kaplan enjoys making rather outrageous strings which result in equally outrageous sort keys. I remember one entry a while ago where he piled over a dozen accent marks over a single "a". That "a" plus the combining diacritics all equal one giant linguistic character. (There is a less extreme example here, wherein he uses an "e" plus two combining diacritics to form one linguistic character.) If you wanted your buffer to really be able to hold five of these extreme linguistic characters, you certainly would need it to be bigger than WCHAR buffer[5].

    As a result, my recommendation to you, dear reader, is to enter every page of documentation with a bias towards storage character whenever you see the word character. Only if the function operates on the textual data linguistically should you even consider the possibility that the author actually meant linguistic character. The only functions I can think of off-hand that operate on linguistic characters are CharNext and CharPrev, and even then they don't quite get it right, although they at least try.

  • The Old New Thing

    Where did the Windows Vista wallpaper images come from?

    • 49 Comments

    Windows Vista needed some new wallpapers. Where to get them? Historically, they were purchased from a professional service, which is expensive since Microsoft would need worldwide rights to reproduce (not just use) the image, and not just for a few months, but for decades. Besides, there are a lot of good amateur photographers at Microsoft who would be thrilled to have their work displayed on millions of computers all over the world.

    But why stop there? Creative Director Jenny Lam expanded the search to Flickr and contacted people who took really interesting pictures, asking them, "So, how would you like one of your photos included among the default wallpapers in Windows Vista?" The Flickr artists were excited to be a part of Windows Vista (one of them by an astonishing coincidence happened to be a beta tester), and after the lawyers had their say—because nothing is complete without lawyers getting involved—Microsoft sent the photographers on a commissioned photo shoot. Jenny tells me that these amateur photographers were great to work with. They don't have the ego problems that some professional photographers can have. (Another thing that I learned from Jenny is that photos which look great on paper do not always translate well to the screen.)

    Ultimately, Jenny studied over 50 gigabytes of low-resolution images. (Off the top of her head, she estimates that she evaluated over 10,000 images, but the math suggests it was a lot more.) About two thirds of the final wallpapers are licensed from various image libraries, with the rest split among amateur photographers recruited from Flickr, Microsoft employees who enjoy photography, and a professional photographer specifically hired for this purpose. Jenny confides that the ones from Flickr are her favorites.

    If you were wondering where those gorgeous pictures came from, the answer is many of them came from amateur photographers, regular people like you and me. (But with better taste.)

    [Update 9:15am: Long Zheng has a bit more on those wallpapers.]

  • The Old New Thing

    Not my finest hour: Where are my keys?

    • 44 Comments

    Tuesday was not my finest hour.

    Towards the end of the work day, I noticed that my coat was nowhere to be seen. I distinctly remember putting it on the back of my chair, but it's not there now. And where are my keys?

    After checking all the likely places (and several unlikely ones) in my office, I realized that we had gone out to lunch in my car, and it was a warm day, so I walked outside to my car and, yup, my coat is sitting there in the back seat. Now, my normal routine when locking the car is to hold my keys in one hand while locking the car with the other. Upon further consideration, I figured that I locked the car doors, slipped the key in my coat pocket, and then decided that since it was a warm day, I didn't need my coat, so I tossed the coat onto the seat before shutting the door.

    Fortunately, this was not the end of the world. I took the bus home (which includes a bit of walking since the bus stop is a twenty-minute walk from my front door), making a point to take an earlier run than I might normally, since I didn't want to get caught outdoors when the cold night set in. (I had a heavy sweater but no gloves.) I keep a spare house key in my wallet, so I was able to get inside. My plan was to bring my spare car keys with me when I rode my bicycle to work the following morning.

    Aha, an improvement to the plan. I made plans to have dinner with a friend at a restaurant near my house. My friend picked me up at my house and then dropped me off at work. Woo-hoo! Everything has been restored to balance! I used my spare car keys to get into my car and drive home. While waiting at a traffic light, I checked the pockets of the coat in the back seat. Empty. Rats.

    And then I realized, "Hey, where is the coat that I wore to the restaurant?" I must have left it at the restaurant. Well, I was headed in that direction anyway, so I took a slight detour to the restaurant and picked up my other coat. At least one problem was solved. But what about my keys?

    I concluded that my keys must still be in my office somewhere, so I drove back to work, set on finding the keys and resolving the last outstanding issue. Yes, this could have waited until the next morning, but I was determined by now. I went back to my table, checked the obvious locations again, and then moved on to less obvious locations. "Maybe they fell on the floor." I crawled under my table, and that's when I remembered.

    "Hey, wait a second, this isn't the first time today that I crawled under my table." Earlier in the day, I plugged my USB keychain drive into the back of a computer that hangs out under my table. I did this in order to call up a particular dialog box so I could take a screen shot. I crawled into an even more inconvenient spot under my table and, yup, there was my keychain, dangling off the back of one of my computers.

    When I start to think I'm a pretty clever guy, I just have to remember the day I lost my keys, and then lost my coat while looking for my keys.

  • The Old New Thing

    One Armstrong = 13.5 mph

    • 42 Comments

    Out of curiosity, I wanted to know how fast Tour de France riders go up l'Alpe D'Huez, the legendary mountain climb. Using information from the Wikipedia page, I calculated that Lance Armstrong's 2004 ascent had an average speed of approximately 13.5 mph (22 kph). Consequently, I invented the Armstrong, a unit of bicycle velocity, with one Armstrong equal to 13.5 mph. (If I were being fair, I would have used 1 Pantani = 14mph, since Marco Pantani holds the record for the fastest ascent of l'Alpe d'Huez. But I'm not being fair.)

    The day after I made this fantastic calculation, I glanced down at my speedometer and realized that my speed on flat ground was significantly less than one Armstrong. That's right, Lance Armstrong went up l'Alpe D'Huez faster than I rode to work on flat ground.

    Fortunately, subsequent investigation revealed that my bicycle's speedometer sensor had wiggled out of position and was reporting only about two thirds of my actual speed. My unofficial goal is to be able to go 13.5 mph up the comparatively tiny hills that I have to cross on my way to and from work. It's not l'Alpe d'Huez, but then again, I'm not Lance Armstrong.

  • The Old New Thing

    Email tip: Choose a subject line that is meaningful to the recipient, not to the sender

    • 40 Comments

    Presumably you want the recipient to read the message. That's why you sent it. It would behoove you to select a subject line which conveys to your reader the purpose of your message. Otherwise your reader is likely to ignore it for being too vague and uninteresting.

    Here are some actual bad subject lines I've seen.

    • Customer question
    • Question about Windows XP
    • New question
    • Help needed
    • Any help will be most appreciated
    • SR#314159276358
    • A tough problem!
    • Some questions on Windows
    • Urgent: Query regarding Windows
    • Request for information - URGENT!!
    • URGENT URGENT URGENT

    Suppose your Inbox had a hundred messages that all looked like this. Would you bother reading even one of them?

    I'm sure the subject line makes perfect sense to the person who sent the message. They have only one customer with a question, so "Question from my customer" captures the issue perfectly. But if you send this message to a list with 500 members, those other 499 people most likely will not know what your message is about based solely on the subject line.

    A good subject line would include enough information about the question so that the recipient can decide whether to read further or whether it's something they can't help with. For example, "Question about generics," or even better, "Question about covariant types in generics."

    Remember, choose a subject line that is meaningful to the person you're sending it to. It's only polite.

  • The Old New Thing

    Does Microsoft internally use MFC for writing Windows apps?

    • 38 Comments

    Craig Ward figures that if he asks enough questions I might answer one of them. "Does Microsoft internally use MFC for writing Windows apps? How about VB?"

    People use whatever they decide best meets the requirements for the task at hand. That could be a batch file, a C++ program, a perl script, a web page with a bunch of JScript, use your imagination. Is the number of solutions that use MFC and VB nonzero? I don't know for sure (I'm not in the habit of taking all the programs I see and trying to figure out what language they're written in), but I'd be very surprised if somebody somewhere hasn't thrown together an MFC or VB program to do something, be it a test suite, an install script, a graphical interface over a complicated command-line tool, or something else. It's a big company. I understand that in some parts of the company they even use Macintoshes.

    I'm not going to go into details of specific projects because (3) I am not authorized to talk about it. (I gave reasons one and two two years ago.)

  • The Old New Thing

    2006 storm aftermath: A look back

    • 34 Comments

    It's been about a month since the windstorm that brought the Seattle area to a standstill. Puget Sound Energy has posted a recap of the storm, including what I consider to be a wonderful euphemism:

    We thank those customers who called to update us with valuable outage status information.

    Translation: "We would like to acknowledge all the people who called in to complain."

    Not surprisingly, the storm got a lot of coverage in the local paper. Conspiracy theorists will be woefully dissatisfied with this explanation of how the utility companies decide which lines to repair first. I heard in a radio story that another factor is that a small outage may get fixed out of priority order if a repair crew happens to be nearby (presumably working on a higher priority repair) and the problem can be fixed quickly. It's a fascinating optimization problem, deciding how to deploy limited resources most efficiently, and a problem I am glad it's not my job to solve.

    Many local governments are looking at low-tech solutions to communications problems, since the power outage highlighted our dependence on electronic communications. One of my friends told me about a local government official who appeared on the radio to announce the opening of shelters for people who were out of power and needed a place to stay. When the local official said, "A list of all the locations can be found on our web site," the show host replied, "Um, people without electricity can't check the web site."

    A different friend told me about a caller to a radio talk show from one of the outlying areas who complained about the glacial pace at which municipal services were being restored. The host opined, "Yeah, well, that's what happens when you live in a rural area, I guess."

    The caller answered, "Well, I used to live in Seattle, but I left because the taxes were too high."

Page 1 of 4 (35 items) 1234