• The Old New Thing

    Out of the deep fryer

    • 13 Comments

    McDonalds anonunced that it would no longer offer "Super Size" on its menu. The ostensible reason was that the addition of newer healthier options didn't leave room on the menu for "Super Size".

    This was of course laughable on its face.

    Now it's even more laughable, because it turns out that the so-called "healthy" options are even fattier than the burgers. You can see for yourself on McDonalds' own Interactive Nutrition Counter. A Caesar Salad with Chicken Premiere contains 18.4 grams of fat, compared to 11.5 grams of fat in a cheeseburger.

    [Raymond is currently on vacation; this message was pre-recorded.]

  • The Old New Thing

    @-notation was never legal in HTTP URLs anyway

    • 21 Comments

    Some people are in an uproar over IE's dropping of support for @ notation in HTTP URLs. What people fail to note is that The @ notation was never legal for HTTP URLs in the first place. If you go to RFC 1738 section 3.3 (HTTP), it explicitly states:

    An HTTP URL takes the form:

          http://<host>:<port>/<path>?<searchpart>
    

    where <host> and <port> are as described in Section 3.1. If :<port> is omitted, the port defaults to 80. No user name or password is allowed.

    (Emphasis mine.)

    So there are now three sides to the argument:

    • "I want Internet Explorer to be backwards-compatible with my invalid URLs." (These people want the @-syntax retained.)
    • "I want Internet Explorer to be more secure." (These people want the @-syntax removed.)
    • "I want Internet Explorer to be more standards-compliant." (These people also want the @-syntax removed.)

    Personally I think dropping support for @-notation was the right thing to do.

    [Raymond is currently on vacation; this message was pre-recorded.]

  • The Old New Thing

    the qUirKY jaPan HomEPage

    • 2 Comments

    The weird stuff about Japan you were afraid to ask about. The Seldom-Asked Questions are interesting, but what I find the most fascinating is the pictures of various Japanese subcultures.

    [Raymond is currently on vacation; this message was pre-recorded.]

  • The Old New Thing

    Why an object cannot be its own enumerator

    • 3 Comments
    I've seen people using the following cheat when forced to implement an enumerator:
    class MyClass :
      public IDataObject, public IEnumFORMATETC, ...
    {
      ...
      HRESULT EnumFormatEtc(DWORD dwDirection,
                     IEnumFORMATETC** ppenumOut)
      {
        _dwDirection = dwDirection;
        Reset();
        *ppenumOut = this;
        AddRef();
        return S_OK;
      }
    };
    

    Why create a separate enumerator object when you can just be your own enumerator? It's so much easier.

    And it's wrong.

    Consider what happens if two people try to enumerate your formats at the same time: The two enumerators are really the same enumerator, so operations on one will interfere with the other. For example, consider this odd code fragment (error checking deleted for expository purposes) which looks to see if the data object exposes the same data under multiple aspects:

    IDataObject *pdto = <MyClass instance>;
    
    // Obtain two enumerators since we will run
    // each one independently.
    
    IEnumFORMATETC* penum1;
    IEnumFORMATETC* penum2;
    pdto->EnumFormatEtc(DATADIR_GET, &penum1);
    pdto->EnumFormatEtc(DATADIR_GET, &penum2);
    
    FORMATETC fe1, fe2;
    while (penum1->Next(1, &fe1, NULL) == S_OK) {
      penum2->Reset(); // start a new pass
      while (penum2->Next(1, &fe2, NULL) == S_OK) {
        if (fe1.cfFormat == fe2.cfFormat &&
            cf1.dwAspect != cf2.dwAspect) {
            // found it!
        }
      }
    }
    penum1->Release();
    penum2->Release();
    

    When the code does a penum2->Reset(), this also inadvertently resets the first enumerator. The loop runs through penum2 (which therefore also runs through penum1), and when it's done, the enumerator is left at the end of the list.

    Then we loop back and call penum1->Next(), which immediately returns failure since the inner loop ran it to completion.

    Result: The loop fails to find anything because the second enumerator corrupted the first.
  • The Old New Thing

    A privacy policy that doesn't actively offend me

    • 8 Comments

    I've ranted before about privacy policies and how they don't actually protect your privacy. (All they're required to do is disclose the policy; there is no requirement that the policy must be any good.)

    Today I read MetLife's privacy policy and found to my surprise that it does not actively offend me. It's written in plain English, it's well-organized, and it actually explains and limits the scope of each exception.

    I have noticed how the word "terrorism" has turned into a "magic word" of late. Anything distasteful you want to do, just say you're doing it to combat "terrorism" and people will give you the green light.

  • The Old New Thing

    The only logical conclusion is that he was cloned

    • 6 Comments

    Something is wrong with the world when fark finds something "real" news organizations miss. (When I first learned about fark, I confused it with FARC, a different organization entirely. That's right, a terrorist organization has its own official web site. Gotta love the Internet.)

    Anyway, fark has pointed out that the guy that Pakistani forces claim today to have surrounded along the border with Afghanistan, Ayman al-Zawahiri, was already reported to have been captured two years ago by The Grauniad. They never printed a correction (as far as I can tell) so I guess he cloned himself.

  • The Old New Thing

    Why does the Resource Compiler complain about strings longer than 255 characters?

    • 13 Comments
    As we learned in a previous entry, string resources group strings into bundles of 16, each Unicode string in the bundle prefixed by a 16-bit length. Why does the Resource Compiler complain about strings longer than 255 characters?

    This is another leftover from 16-bit Windows.

    Back in the Win16 days, string resources were also grouped into bundles of 16, but the strings were in ANSI, not Unicode, and the prefix was only an 8-bit value.

    And 255 is the largest length you can encode in an 8-bit value.

    If your 32-bit DLL contains strings longer than 255 characters, then 16-bit programs would be unable to read those strings.

    This is largely irrelevant nowadays, but the warning remained in the Resource Compiler for quite some time.

    It appears to be gone now. Good riddance.

  • The Old New Thing

    Catholic baseball fans want to eat meat on opening day

    • 14 Comments

    So it happens that Opening Day of the baseball season coincides with Good Friday, a day of "fasting and abstinence" according to Catholic tradition. (Then again, after Vatican II, the definition of "fasting and abstinence" weakened significantly. All that most people remember any more is "no meat".)

    Catholics in Boston have applied to the archdiocese for a special dispensation so they can have a hot dog at the game. The Church said "Nice try".

    But at least you can still order a beer.

  • The Old New Thing

    The car with no user-serviceable parts inside

    • 68 Comments

    For the first time, a team of women is challenged to develop a car, and the car they come up with requires an oil change only every 50,000 kilometers and doesn't even have a hood, so you can't poke around the engine.

    To me, a car has no user-serviceable parts inside. The only times I have opened the hood is when somebody else said, "Hey, let me take a look at the engine of your car." (I have a Toyota Prius.) On my previous car, the only time I opened the hood was to check the oil.

    Sometimes the open-source folks ask, "Would you buy a car whose hood can't be opened?" It looks like that a lot of people (including me) would respond, "Yes."

  • The Old New Thing

    Why is the line terminator CR+LF?

    • 40 Comments
    This protocol dates back to the days of teletypewriters. CR stands for "carriage return" - the CR control character returned the print head ("carriage") to column 0 without advancing the paper. LF stands for "linefeed" - the LF control character advanced the paper one line without moving the print head. So if you wanted to return the print head to column zero (ready to print the next line) and advance the paper (so it prints on fresh paper), you need both CR and LF.

    If you go to the various internet protocol documents, such as RFC 0821 (SMTP), RFC 1939 (POP), RFC 2060 (IMAP), or RFC 2616 (HTTP), you'll see that they all specify CR+LF as the line termination sequence. So the the real question is not "Why do CP/M, MS-DOS, and Win32 use CR+LF as the line terminator?" but rather "Why did other people choose to differ from these standards documents and use some other line terminator?"

    Unix adopted plain LF as the line termination sequence. If you look at the stty options, you'll see that the onlcr option specifies whether a LF should be changed into CR+LF. If you get this setting wrong, you get stairstep text, where

    each
        line
            begins
    
    where the previous line left off. So even unix, when left in raw mode, requires CR+LF to terminate lines. The implicit CR before LF is a unix invention, probably as an economy, since it saves one byte per line.

    The unix ancestry of the C language carried this convention into the C language standard, which requires only "\n" (which encodes LF) to terminate lines, putting the burden on the runtime libraries to convert raw file data into logical lines.

    The C language also introduced the term "newline" to express the concept of "generic line terminator". I'm told that the ASCII committee changed the name of character 0x0A to "newline" around 1996, so the confusion level has been raised even higher.

    Here's another discussion of the subject, from a unix perspective.

Page 418 of 447 (4,468 items) «416417418419420»