Sometimes you get so worked up about the compatibility consequences of a change that you miss the obvious

During the course of investigating a bug that resulted in the system crashing with a bluescreen, the question arose, "What are the compatibility consequences of making this change? Are there any legitimate scenarios where somebody would be relying on being able to do XYZ and counting on the old behavior?"

I had to step in and state the obvious:

"There is clearly no valid scenario for the old behavior, because if you try to do XYZ, you crash with a bluescreen."

Some people were amused by the clear logic of this statement. But it's also the case that sometimes people get so excited that they miss the obvious.

Comments (14)
  1. Karellen says:

    Are there any workflows that depend on crashing with a bluescreen?

    It may be horrifying, but there always might be…

    1. Antonio Rodríguez says:

      I knew that you were linking exactly to that XKCD comic even before looking at the link’s target :-P .

    2. Ivan K says:

      Hah. And from that same comic… “There are probably children out there holding down spacebar to stay warm in winter. YOUR UPDATE MURDERS CHILDREN.”

  2. Bradley says:

    Great, now you broke my app that allows users to trigger blue screens on demand!

    1. Matteo Italia says:

      They are doing it to put you out of business and promote their own Ctrl+Scroll lock+Scroll lock thing, just as they did with IE!

  3. Medinoc says:

    But did the old behavior crash in old Windows versions?

  4. Vilx- says:

    There’s a mandatory XKCD comic about this topic:

    1. Brian_EE says:

      If it was posted a *whole hour* before your comment, can you still say you were ninja’d?

  5. Antonio Rodríguez says:

    Maybe doing just XY is a valid operation on it own, and the fix for XYZ’s bluescreen changes the result of XY. That would be a compatibility concern.

    1. If XYZ can be used in a sneaky way that avoids the crash, or it crashes only rarely, then you have a potential compatibility issue because people might be using it in the sneaky way (or are getting lucky). But in this case, XYZ always crashes, so the question is easier to answer.

  6. MarcK4096 says:

    I’m glad to see sanity won out in this won. I wish it would win out more often such as in fixing the behavior that if you try to paste an invalid filename into an Explorer rename, the clipboard contents get changed with the invalid characters removed.

    1. ErikF says:

      Raymond talked about that six years ago:

      It seems that this is a bug (or feature, take your pick) that has earned its tenure! Honestly, I don’t see this behaviour biting people very often: How many times do you paste filenames in a rename operation?

      1. MarcK4096 says:

        I do it a lot. I disagree with the idea that old bugs should not be fixed because of the potential existence of unknown applications relying on them. Microsoft broke a lot of stuff with Windows Vista and newer. It’s time to let this one go (and others like it). Not fixing old bugs might have made sense when Microsoft didn’t do much with customer feedback. Now they have the insider program. If they fix the bug and it breaks something major, they can create a compatibility shim or know for sure that the bug must stay, before impacting the release builds.

  7. Wow, you guys reenacted a 20 year old anecdote. It went like this:
    Same bug leading to the code “crash computer” was discovered in Linux, Mac, Windows.
    Linux team: let’s remove this code.
    Mac team: we cannot remove “crash computer” code for compatibility reasons, but let’s make sure it is never called.
    Windows: we have to call “crash computer” code for compatibility reasons, let’s add “uncrash computer” after it.

Comments are closed.

Skip to main content