July, 2009

  • The Old New Thing

    How organizations inadvertently confirm facts when they try not to


    On the Media in its story "Fact? Check!" forwarded the revelation (uncovered by the PBS program Frontline in the first part of their "News War" series) that the fact that the United States Justice Department launches a leak investigation implicitly confirms the leak! That's because one of the prerequisites for a leak investigation is that the leaked information actually be true.

    Lowell Bergman: The information has to be accurate?

    Dave Szady: Yes.

    Lowell Bergman: So when the government announces a leak investigation and it comes to your office, it's confirming that the report in the newspaper, for example, or on television, was true.

    Dave Szady: Yes. Indirectly, yes.

    That reminded me of a similar "inadvertent confirmation" from a local news story many years ago. Someone was admitted to the hospital with acute poisoning, and the local newspaper called to determine whether it was an attempted suicide. The hospital confirmed that the person had been admitted, but declined to discuss whether it was due to a suicide attempt. "Our privacy policy forbids us from revealing any further information about patients who are admitted after an attempted suicide."

  • The Old New Thing

    What is the difference between Directory and Directory\Background?


    One item I left off the list of special progids is Directory\Background.

    Recall that Directory is the progid for file system folders (a subset of Folder which represents all shell folders, both file system and virtual). Closely related is Directory\Background, which isn't really a progid, but it is a place where shell extensions can register themselves. Specifically, it's where context menu handlers can register if they want to appear when the user right-clicks on a blank space of a file system folder.

  • The Old New Thing

    How do I quickly position two windows side by side using only the keyboard?


    alexx is looking for a keyboard-only equivalent to the ctrl+click trick I mentioned a few days ago.

    • Ctrl+Shift+Esc: This opens Task Manager.
    • From the Applications tab, use Ctrl+Space to select the two windows you want.
    • Alt+W (open the Windows menu)
    • V (Tile Vertically)

    Not as quick, but it still works. And it works even if the windows you want got converted into a group.

    Of course, on Windows 7, you can use the Win+Left and Win+Right hotkeys. (Users with multiple monitors can couple this with Win+Shift+Left and Win+Shift+Right.)

  • The Old New Thing

    What is the difference between CSIDL_DESKTOP and CSIDL_DESKTOPDIRECTORY?


    Among the various CSIDL values you can pass to functions like SHGetSpecialFolderLocation are CSIDL_DESKTOP and CSIDL_DESKTOPDIRECTORY. What's the difference between them?

    The CSIDL_DESKTOP is the virtual folder that represents the desktop. The contents of this virtual folder is what gets displayed on top of your wallpaper.

    The CSIDL_DESKTOP virtual folder is populated from various locations, some of them virtual, and some of them physical. The CSIDL_DESKTOPDIRECTORY special folder is a physical folder that contains the files that you think of as on your desktop. These are the files that you've saved to your desktop, files that you've dragged to your desktop, that sort of thing. Some files on the desktop come from CSIDL_COMMON_DESKTOPDIRECTORY, which is the shared desktop. Files in the shared desktop directory are visible to all users.

    What does this mean for you, the programmer? (Well, assuming you are still using CSIDL values and haven't switched over to the new FOLDERID model.)

    Programs shouldn't care about CSIDL_DESKTOPDIRECTORY; they should just operate on CSIDL_DESKTOP, because that's what the user sees. If you want to generate an ITEMIDLIST for a file on the desktop, use the CSIDL_DESKTOP folder. The physical folder behind the desktop can change (for example, due to roaming user profiles), but the logical location on the desktop remains fixed. If you had generated the ITEMIDLIST based on CSIDL_DESKTOPDIRECTORY, then the experience for your users will be much more annoying: They will get file not found errors if the user profile roams to another machine (since the directory has changed). If they perform a Save As operation, the default save location will be some deep file system path instead of just being the desktop.

    The CSIDL_DESKTOPDIRECTORY is the plumbing behind the scenes. Don't show it to the user; it's ugly.

  • The Old New Thing

    The advantage of knowing your limits of discrimination


    A story a while back about ridiculously expensive speaker cables and James Randi's challenge to tell the difference between them and modestly-priced cables reminded me of a conversation I had with a wine-loving friend of mine.

    He went on a wine tasting tour and sampled wines of varying quality and price. His conclusion was that he could detect the correlation between price and quality up until about $75/bottle. Beyond that point, the wines all tasted roughly equally great.

    Conclusion: There's no point in my friend spending more than about $75 on a bottle of wine. Once you know the limit of your discrimination, you can use it to avoid wasting money. (One might argue that this is one advantage of having a coarse palate: You can get away with cheaper wine!)

    Related: Commenter Eff Five notes that researchers have determined that people perceive the same wine as tasting better if they are told that it is more expensive.

  • The Old New Thing

    How do I put a window at the edge of the screen without triggering the automatic positioning behavior?


    Last time, we saw that Windows 7 lets you position windows to fill the left or right half of the screen by just dragging the window to the appropriate edge. (This also works for the top and bottom half of the screen.) But what if you just want a window near the edge without the automatic positioning?

    Just grab the window from the far edge.

    The auto-positioning behavior is triggered by the mouse position, not the window position. (This is hinted at in the animation that accompanies the docking: The ripple effect is centered on the mouse, not the window. Here are more details on Aero Snap design.) If you don't want auto-positioning to kick in, just keep the mouse away from the edge of the screen. For example, suppose you want to place a window against the left edge of the screen, but you don't want the automatic positioning to kick in. Just grab the caption bar by the area near the minimize/maximize/close buttons, then drag the window to the left edge of the screen. Since you grabbed it from the right-hand part of the caption, you can position the window freely without the mouse getting anywhere near the edge of the screen.

    Similarly, if you want to position a window near the right edge, grab it near the left hand part of the caption bar (near the caption icon).

    If this feature offends you so much that you would rather have it permanently disabled, you can do so from Control Panel | Ease of Access Center | Make the mouse easier to use | Prevent windows from being automatically arranged when moved to the edge of the screen. (Note that this is a dreaded negative checkbox. It should have been phrased Arrange windows automatically when moved to the edge of the screen.) As a shortcut for those first three steps, you can hit the Windows key and then type better mouse into the Start menu search box, then click Change how your mouse works.

  • The Old New Thing

    Mr. Lee CatCam lets you see what a cat does all day


    Jürgen Perthold modified a lightweight camera and hung it around his cat's neck, snapping a picture every few minutes. Join Mr. Lee on a trip through the neighborhood. If those trips aren't enough, you can also see what Jacquie is up to.

  • The Old New Thing

    How do I quickly position two windows side by side?


    Commenter n/a posted a laundry list of feature requests. I'm not going to address all of them here (though I inadvertently addressed one of them a while ago). But today I'm going to address request number two, "A simple switch to create two windows, one alongside the other, vertically split."

    That feature has been around since Windows 95, possibly even before that but I haven't bothered to check.

    In the taskbar, click the button for the first window you want to position, then hold the Ctrl key and right-click the button for the second window. Select Tile Vertically. Bingo, the two windows are positioned side by side.

    (If you pick Tile Horizontally then they appear one above the other.)

    Of course, the upcoming Windows 7 makes this operation much easier with a set of window-positioning features that collectively are known as Snap. Just drag one window to the left edge of the screen, and drag the other to the right edge of the screen. But what if you don't want the windows to auto-dock? We'll pick that up next time.

    Bonus chatter: In case you missed it, the Engineering Windows 7 team blog the history of window arrangement in Windows in a multi-part series: Part 1, Part 2, and Part 3: Aero Snap.

  • The Old New Thing

    Conway-Kochen Free Will Theorem: Lecture series


    Some time ago, there was a bit of excitement when researchers John H. Conway (best known to geeks as the inventor of The Game of Life, a Turing-complete cellular automaton) and Simon Kochen (best known to geeks as, um, okay, he's not known to geeks) concluded that if human beings have free will, then so too do elementary particles.

    In 2009, Conway gave a series of six one-hour lectures on this theorem. The lectures have been recorded and are available online. (I also found a nice summary of a public lecture by John Conway on the same subject, for those who are impatient and just want the one-page version.)

    Bonus Conway Chatter: There are actually two noted mathematicians named John Conway. In addition to John H. Conway, whose work leans more toward group and number theory, there is also John B. Conway, whose work is primarily in functional analysis. (In a rough sense, John H. Conway studies discrete things, whereas John B. Conway studies continuous things.) The group theorist is by far the more famous of the two, and he told me that he had the opportunity to meet with his functional analysis counterpart, who noted that people outside the upper echelons of mathematics often mistook him for the far more famous group theorist.

    "When I'm introduced to people, they will recognize the name and say, 'Oh, Dr. Conway, it's such a pleasure to meet you. I'm a big fan of the Game of Life.' I then have to tell them that they are thinking of the other John Conway."

    Which is why John H. Conway was amused when he was introduced at some mathematics get-together or other, and the other person enthusiastically responded, "Oh, Dr. Conway, it's such a pleasure to meet you. I'm a big fan of your book on complex variables."

  • The Old New Thing

    Polling by sleeping versus polling by waiting with a timeout


    Commenter Francois Boucher asks it's better to write a background worker thread that polls with Sleep() and a flag, or polls by waiting for an event with a timeout?

    // method A
    while (fKeepGoing) {
     .. a little work ..
    // method B
    do {
     .. a little work ..
    } while (WaitForSingleObject(hEvent, 50) == WAIT_TIMEOUT);

    "Which scenario is better? The first one uses only 1 handle for the thread. The second one will use 2. But is the first scenario wasting more thread time? Is it worth using the event (kernel object)?"

    Yeah, whatever.

    I don't quite understand why you want to pause every so often. Why not just do the work at low priority? When there are more important things to do, your background thread will stop doing whatever it's doing. When there is an available CPU, then your background thread will do its thing as fast as it can (until something with higher priority arrives).

    The only thing I can think of is that by adding the pauses, your program won't look like it's consuming 100% CPU while the background processing is going on. Which is true, but then again, that's not much consolation. "Wow, with these changes, my spell check takes only 10% of the CPU. But then again, it also takes 10 times as long." Is that an improvement? You made your customer wait ten times as long for the document to be spell checked. That's ten times less battery life for your laptop.

    And generally speaking, polling should be avoided because it carries negative consequences for system performance. So we're basically asking, "Which is better, hammering with a screwdriver or hammering with pliers?"

    But let's say for the sake of argument that this "back off periodically" polling loop is actually the right design, and the only argument is which of the above two methods is "better" in terms of the criteria listed above (handles, thread time).

    It still doesn't matter.

    Method A has one fewer handle, but one more flag. So the total number of things you have to keep track of is the same either way.

    "Oh, but I save the overhead of an additional handle."

    Dude, you're already burning a thread. A single handle to an event is noise compared to the cost of a thread.

    "But I save the cost of validating the handle and following the reference to the underlying kernel object."

    Dude, you're about to go to sleep for 50 milliseconds. Saving a few thousand clocks is noise compared to 50 milliseconds.

    The flag method does have some other problems, none of which are deal-breaking, but are things to bear in mind.

    First, that flag that you're checking. There's no synchronization on that variable, so the background thread may run a smidge longer than necessary because the change hasn't yet propagated to the CPU running the loop. Similarly, the sleep loop does take a little longer to notice that it should stop working. If the fKeepGoing flag is set to FALSE during the sleep, the sleep will still run to completion before the loop finds out.

    In the grand scheme of things, however, the extra 50 to 100 milliseconds are probably not a big deal. The background thread is a little slow to shut down, that's all. The user will probably not even notice that the CPU meter was higher than normal for an additional tenth of a second. After all, the typical human reaction time is 100 milliseconds anyway.

    I'm assuming that the code that signals the background thread doesn't sit around waiting for the background thread to clean up. If it does, then this 100ms delay may start to combine with other delays to turn into something the user may start to notice. A tenth of a second here, a tenth of a second there, soon you may find yourself accumulating a half second's delay, and that's a delay the human brain can perceive.

Page 1 of 5 (42 items) 12345