• The Old New Thing

    Found blog: The Piehole

    • 8 Comments

    I have no idea who this person is, but she's all attitude all the time. Like this entry from October 18, 2005 when Jennifer was recovering from a foot injury:

    Men love a girl who can't run away quickly

    I got "wooey!"-ed by a garbage man on my way back to the office from lunch today... Because I'm so HAWT hobbling down the street. He could not resist my hobbling! I am hobbleicious! Sssssssss! *

    And just so you know, being followed down the street by a garbage truck with someone screaming "YEAH BABY!" and "what's your phone number?" is TOTALLY CLASSY!

    * This is the sound of me sizzling!

    It's the asterisk that's the icing on the cake.

    From that web site's blogroll you can springboard to a whole new world of outrageous content. Like My Boyfriend is a Twat or Inappropriately Dressed.

  • The Old New Thing

    Why is inline autocomplete disabled by default?

    • 33 Comments

    Earlier versions of Internet Explorer used inline autocomplete, but newer versions use drop-down autocomplete that requires you to press the down-arrow key to select an item from the drop-down. Why the change?

    Because it interferes with normal keyboard operation.

    Suppose http://www.microsoft.com/windows/ is in your history, but you want to go to http://www.microsoft.com/. As you type the desired destination, inline autocomplete kicks in and fills in the remainder of the URL for you, http://www.microsoft.com/windows/. If you aren't watching the screen and just hit Enter, you end up going to the autocompleted URL instead of the URL you typed. Oops.

    To me, this is a fatal flaw, namely that one has to be watching the screen to perform an operation that one would think consisted purely of typing. In particular, this creates problems for people with limited visual capability who necessarily "type blind" most of the time.

    Even using Tab as the autocomplete character suffers from the same flaw. Consider the Run dialog or IE's address bar. In those places, the Tab key moves you around the window. (To the OK, Cancel, and Browse buttons on the Run dialog, or into the web page itself for IE.) If the Tab key were the autocomplete completion key, it wouldn't be possible to Tab around the dialog/window any more. For example, suppose you want to browse around your C drive, so you type C:\ into the Run dialog and hit Tab three times to get to the Browse button. But, oops, the Tab key autocompletes, so instead of browsing C:\, you're browsing whatever directory in your C: drive the autocomplete engine decided to show you.

  • The Old New Thing

    Bicycling from Mercer Island to Microsoft main campus

    • 8 Comments

    I asked four people who commute by bicycle eastbound over the I-90 bridge to Microsoft main campus what route they take, and they gave three different answers. I've given them meaningless names just to tell them apart.

    The yellow route

    First half (markers A1 through A5) | Second half (markers B1 through B5).
    Animated version: Click markers 1 through 5 in order then markers 1 through 5 in order.
    Pro: Avoids downtown Bellevue
    Con: You're stuck on Bel-Red

    • Get to the I-90 bridge eastbound.
    • After crossing the bridge, stay on the trail when it twists under I-90; do not get off into the neighborhood. You will be on a trail parallel to SE Lake Rd (marker A1).
    • You will reach a fork in the trail. Bear right and take the bridge.
    • Ride through the park until the trail ends, putting you on 118th Ave SE (marker A2).
    • Turn left (north). Bellevue Transportation Department recommends riding on west (left) side to reach bike path.
    • Turn right onto SE 8th St (marker A3) and go under I-405.
    • Cross Lake Hills Connector; the road name changes to SE 7th Pl.
    • Turn left onto 128th Ave SE (marker A4).
    • The road turns to trail after NE 7th St; turn right onto NE 8th St (marker A5 = marker B1).
      • Alternate route: Turn right onto Main St. and zig-zag through the neighborhood for a less hilly approach.
    • Turn left onto 132nd Ave NE or 134th Ave NE, depending on traffic (marker B2).
    • Turn right onto Bel-Red Road (marker B3).
    • Take Bel-Red Road to Microsoft main campus (markers B4 and B5).

    The blue route (two votes)

    First half (markers C1 through C5) | Second half (markers D1 through D5).
    Animated version: Click markers 1 through 5 in order then markers 1 through 5 in order.
    Pro: Avoids downtown Bellevue and Bel-Red
    Con: Extremely hazardous intersection at the end

    • Get to the I-90 bridge eastbound.
    • After crossing the bridge, stay on the trail when it twists under I-90; do not get off into the neighborhood. You will be on a trail parallel to SE Lake Rd (marker C1).
    • You will reach a fork in the trail. Bear right and take the bridge.
    • Ride through the park until the trail ends, putting you on 118th Ave SE (marker C2). Turn right (south).
    • Hazardous crossing - busy street, look both ways: Immediately after the underpass, turn left to get back on the I-90 trail (marker C3). Note: hill climb.
    • Cross Richards Road, ascend hill, turn left at 142nd Pl SE (marker C4).
    • Take the 142nd Pl bridge into Bellevue Community College and meander through the campus to 145th Pl SE (marker C5 = marker D1).
    • Turn right onto Lake Hills Blvd (marker D2).
    • Take Lake Hill Blvd across 148th, 156th, turning left onto 164th Ave SE (marker D3).
    • Follow 164th Ave SE until it ends at NE 30th St (marker D4).
    • Turn left and stop at Bel-Red Road (marker D5).
    • Extremely hazardous intersection. Cross Bel-Red, taking the back entrance to Microsoft main campus.

    You can avoid the hazardous intersection by taking a left onto NE 24th St. and turning right onto 156th Ave NE.

    The brown route

    First half (markers E1 through E5) | Second half (markers F1 through F5).
    Animated version: Click markers 1 through 5 in order then markers 1 through 5 in order.
    Pro: Overall low exposure to traffic
    Con: Tricky left turn in Factoria, extremely hazardous intersection at the end

    • Get to the I-90 bridge eastbound.
    • After crossing the bridge, stay on the trail when it twists under I-90; do not get off into the neighborhood. You will be on a trail parallel to SE Lake Rd (marker E1).
    • You will reach a fork in the trail. Bear right and take the bridge.
    • Ride through the park until the trail ends, putting you on 118th Ave SE (marker E2). Turn right (south).
    • Hazardous crossing - busy street, look both ways: Immediately after the underpass, turn left to get back on the I-90 trail (marker E3). Note: hill climb.
    • Turn left at Richards Road (marker E4).
    • Immediately after underpass, turn right onto Eastgate Way (marker E5 = marker F1). Note: hill climb.
    • Turn left at 161th Ave SE (marker F2).
    • When the road ends, turn right onto SE 24th St (marker F3).
    • Follow the road as it winds its way counter-clockwise around Phantom Lake; its name changes to 168th Ave SE and SE 16th St as it turns.
    • Turn right onto 164th Ave SE (marker F4).
    • Follow 164th Ave SE until it ends at NE 30th St (marker F5).
    • Turn left and stop at Bel-Red Road.
    • Extremely hazardous intersection. Cross Bel-Red, taking the back entrance to Microsoft main campus.

    As with the blue route, you can avoid the hazardous intersection by taking a left onto NE 24th St. and turning right onto 156th Ave NE.

    I haven't tried any of these routes myself since I live on the north side of town, and if I need to head to Mercer Island, I start from my house, not from work. Still, these are useful routes to know, so I'm recording them here for reference.

  • The Old New Thing

    Välkommen till Saerige?

    • 4 Comments

    Ballard is the Scandinavian neighborhood in Seattle, and they ordered some stone slabs for a new seating area in Bergen Place Park. What they didn't expect was that the Swedish stone would read S∀ERIGE. I mean, yeah, those Swedes do strange things with their A's, like put dots and circles over them, but I'm pretty sure they don't turn them upside-down and treat them as V's.

  • The Old New Thing

    The COM interface contract rules exist for a reason

    • 17 Comments

    Some people believe that the COM rules on interfaces are needlessly strict. But the rules are there for a reason.

    Suppose you ship some interface in version N of your product. It's an internal interface, not documented to outsiders. Therefore, you are free to change it any time you want without having to worry about breaking compatibility with any third-party plug-ins.

    But remember that if you change an interface, you need to generate a new Interface Identifier (IID). Because an interface identifier uniquely identifies the interface. (That's sort of implied by its name, after all.)

    And this rule applies even to internal interfaces.

    Suppose you decide to violate this rule and use the same IID to represent a slightly different interface in version N+1 of your program. Since this is an internal interface, you have no qualms about doing this.

    Until you have to write a patch that services both versions.

    Now your patch is in trouble. It can call IUnknown::QueryInterface and ask for that IID, and it will get something back. But you don't know whether this is the version N interface or the version N+1 interface. If you're not even aware that this has happened, your patch will probably just assume it has the version N+1 interface, and strange things happen when it is run on version N.

    Debugging this problem is not fun. Neither is fixing it. Your patch has to use some other cues to decide which interface it actually got back. If your program has been patched previously, you need to have the version numbers of every single patch so that you can determine which version of the interface you have.

    Note that this dependency can be hidden behind other interfaces. Consider:

    [
        uuid("ABC")
    ]
    interface IColorInfo
    {
        HRESULT GetBackgroundColor([out] COLORREF *pcr);
        ...
    };
    
    [
        uuid("XYZ")
    ]
    interface IGraphicImage
    {
        ...
        HRESULT GetColorInfo([out] IColorInfo **ppci);
    };
    

    Suppose you want to add a new method to the IColorInfo interface:

    [
        uuid("DEF")
    ]
    interface IColorInfo
    {
        HRESULT GetBackgroundColor([out] COLORREF *pcr);
        ...
        HRESULT AdjustColor(COLORREF clrOld,
                            COLORREF clrNew);
    };
    
    [
        uuid("XYZ")
    ]
    interface IGraphicImage
    {
        ...
        HRESULT GetColorInfo([out] IColorInfo **ppci);
    };
    

    You changed the interface, but you also changed the IID, so everything is just fine, right?

    No, it isn't.

    The IGraphicImage interface is dependent upon the IColorInfo interface. When you changed the IColorInfo interface, you implicitly changed the IGraphicImage::GetColorInfo method, since the returned interface is now the version N+1 IColorInfo interface.

    Consider a patch written with the version N+1 header files.

    void AdjustGraphicColorInfo(IGraphicImage* pgi,
                                COLORREF clrOld, COLORREF clrNew)
    {
     IColorInfo *pci;
     if (SUCCEEDED(pgi->GetColorCount(&pci)) {
      pci->AdjustColor(clrOld, clrNew);
      pci->Release();
     }
    }
    

    If run against version N, the call to IGraphicImage::GetColorCount will return a version N IColorInfo, and that version doesn't support the IColorInfo::AdjustColor method. But you're going to call it anyway. Result: Walking off the end of the version N vtable and calling into space.

    The quick solution is to change the IID for the IGraphicImage function to reflect the change on the IColorInfo interface on which it depends.

    [
        uuid("UVW")
    ]
    interface IGraphicImage
    {
        ...
        HRESULT GetColorInfo([out] IColorInfo **ppci);
    };
    

    A more robust fix would be to change the IGraphicImage::GetColorInfo method so that you pass the interface you want to receive.

    [
        uuid("RST")
    ]
    interface IGraphicImage
    {
        ...
        HRESULT GetColorInfo([in] REFIID riid,
                             [iid_is(riid), out] void** ppv);
    };
    

    This allows interfaces on which IGraphicImage depends to change without requiring a change to the IGraphicImage interface itself. Of course, the implementation needs to change to respond to the new value of IID_IColorInfo. But now the caller can feel safe in the knowledge that when it asks for an interface, it's actually getting it and not something else that coincidentally has the same name.

  • The Old New Thing

    Night of the Knitting Dead

    • 1 Comments

    Okay, wrong zombie movie, but I couldn't resist the pun. Knit zombies reenact Dawn of the Dead. Now playing on Flickr.

  • The Old New Thing

    The Hallowe'en-themed lobby

    • 12 Comments

    During the Windows 95 project, the window manager team stayed late one night and redecorated the lobby. They suspended a variety of Hallowe'en-themed objects from fishing lines: spiders, ghosts, witches, jack-o'-lanterns, that sort of thing. The fishing line went up and over pulleys, rigged so that the objects spookily rose and fell seemingly of their own volition. It was quite an impressive display.

    The fishing lines were anchored to various doors in the building. Since the doors they chose were highly-trafficked, this assured a random pattern of motion for the objects suspended from the fishing line. Of course, no spooky Hallowe'en display would be complete without a spider rigged to the front door, rapidly descending upon the poor victim coming in for a meeting.

  • The Old New Thing

    Even in the enlightened year of 2005, we have programs that don't handle long file names

    • 42 Comments

    When I saw Tim Sneath's description of the root cause for all the Windows Vista product key problems, I was amazed that the reason was something my readers tend to go completely ballistic over: Long file names.

    It so happens that one of the ISO mounting tools that people were using for installing Windows Vista doesn't support long file names! (At least not by default.)

  • The Old New Thing

    How to recognize different types of sentinel timestamps from quite a long way away

    • 21 Comments

    Some time ago, I discussed several timestamp formats you might run into. Today we'll take a logical step from that information and develop a list of special values you might encounter. Note that if you apply time zone adjustments, the actual timestamp may shift by up to a day.

    Date Interpretation
    January 1, 0001 The value 0 as a CLR System.DateTime.
    January 1, 1601 The value 0 as a Win32 FILETIME.
    December 29/30, 1899 The value -1 or 0 as an OLE automation date.
    December 13, 1901 The value 0x80000000 as a time_t.
    December 31, 1969
    January 1, 1970
    The value -1 or 0 as a time_t.
    January 1, 1980 The beginning of the DOS date/time era. (Unlikely to be encountered since 0 is not a valid DOS date/time value.)
    January 19, 2038 The value 0x7FFFFFFF as a time_t.
    February 7, 2106 The value 0xFFFFFFFF as a time_t.
    September 14, 30828 The value 0x7FFFFFFF`FFFFFFFF as a FILETIME.

    All of these special values have one thing in common: If you see them, it's probably a bug. Typically they will arise when somebody fails to do proper error checking and ends up treating an error code as if it were a valid return value. (The special values 0, -1, and 0xFFFFFFFF are often used as error codes.)

  • The Old New Thing

    Without a doubt, the world's worst online Swedish lessons

    • 16 Comments

    Lesson 3: Schomething schtranger (mp3) is part three of a series of four (so far) horrifically bad Swedish lessons. (Warning: Off-color content and copious swearing, but nevertheless very funny.) Boz has been living in Sweden since June, and two of his so-called friends have been putting together Swedish language tapes for him. Listen along as he goes through the tapes, trying to repeat each of the phrases.

    Each of the lessons does illustrate a genuine detail of the Swedish language, even though Slaygon and Makke choose to illustrate the points using sentences you're unlikely to encounter in your average Swedish textbook...

    • Lesson 1: Homographs, words spelled the same but with different meaning, sometimes with different pronunciation.
    • Lesson 2: Inflections and compound words, where two words change meaning when combined into a single word.
    • Lesson 3: The sj and tj sounds, two difficult sounds. The "sj" sounds like rushing wind, which I tend to mispronounce as German frontal "ch" because I forget to lower my tongue and open my mouth cavity in order to get that echo-ey whistling effect. The "tj" sound is close to English "sh" (differing in some subtle way I have yet to learn).
    • Lesson 4: The letters K, G and Y. The pronunciations of "K" and "G" vary depending on context. The "Y" is a tricky rounded vowel.

    One fine point of pronunciation that doesn't get much attention in textbooks is the Swedish long "i" sound. Most sources just tell you to pronounce it like English "ee", but you're also supposed to push it towards the back of the mouth, so that you sound like Kermit the Frog. I tend to pronounce it like English "ee" and forget to do the Kermit thing. Just like with my problems with "sj", it's not that I don't know how to do it; I just forget.

Page 355 of 450 (4,494 items) «353354355356357»