No code is an island

Norman Diamond noted in a comment that on Windows 2003 Server, the Display Adapter Troubleshooting slider still lists "full acceleration" as the recommended setting even though the default for Server is "full minus one".

This is one of those "Oh, that's an easy change" bugs. The discussion probably went like this:

Some guy whose idea this was: "For stability reasons, we want to lower the default video acceleration for Server a notch. Dear Video Setup team, can you do that for us?"

Video Setup team: "Sure thing, that's no problem. The default setting is all done by us; it should not have any impact on anybody else. We'll just do it and be done with it."

Guy: "Sweet. Thanks."

And bingo, the default video acceleration dropped to one notch below full on Server, and everyone was happy.

Except that there's this text tucked away in the Display control panel that has the word "(recommended)" next to "full acceleration". That didn't get updated. Oops. (I wouldn't be surprised if there is also some help text that didn't get updated for this change.)

No code is an island.

So when you complain, "Aw come on, it's a one-line change. What's taking so long?" think about the little video acceleration slider.

Comments (13)
  1. N/A says:

    Don’t Repeat Yourself is one of the pragmatic programmer ( recomendations.

    Current tools for programming and documentation are the source of this problem. Whenever you repeat a piece of information, you must keep track of dependecies. We’re still using text files and ugly scripts for complex work.

  2. Tony Cox says:

    Documentation is a particular problem, though. Even with excellent tools for producing documentation, I think you’ll always have the case where there is more than one place to touch to make a change. I don’t think there’s a silver bullet here.

    The core problem is that writing code and writing good end-user documentation are different skills, and that one cannot reasonably expect all good developers to also be good at writing end-user documentation. Nor would you necessarily expect technical writers to be good developers. So you separate those functions.

    The best we can manage is to ensure we have good systems for tracking changes, but even those are prone to human error. It’s hard to imagine an automated system which would have caught this example of Raymond’s for instance. Somewhere along the line a human needs to be concientious enough to check what documentation, resource files, and other items are affected by their change. That all takes time (which I think was the original point), and cannot be a 100% reliable process.

  3. Mike Dimmick says:

    While we’re on this subject (I don’t think I’ve posted this before), any ideas why StretchBlt should apparently be slower when the Hardware Acceleration setting is set to Full than when it’s set to none?

    A poster on CodeProject originally asked this question a few weeks ago ( The best I could do was reproduce the issue on my work system, with an nVidia Riva TNT board. I wondered whether doing the StretchBlt into a compatible DC, then doing a BitBlt to the screen would be any better, but the timings were about the same.

  4. Raymond Chen says:

    Beats me. You’d be better off asking a GDI person.

  5. asdf says:

    Mike, do you by chance have an nVidia card? When I was working on a DX7 game way back then I noticed that if you used Blt with MIRRORLEFTRIGHT it would slow the game down to a crawl. And I think there was also another bug with non color keyed images (when mirrored) that would screw it up too in addition to making it slow to render. Disabling hardware acceleration made the game render correctly and at acceptable rates. We added an option at the last minute to create duplicate flipped sprites to work around this since nVidia hadn’t fixed it yet (and they still haven’t).

  6. asdf says:

    Wait you are using an nVidia card, maybe I should read instead of skim next time.

  7. Muro says:

    This might be a little off topic, but anyway:

    To fight the DLL hell (no code is an island), app.exe.local was introduced in Windows 2000. But, the MSDN says following:

    anyway, so what’s the sense? The app dir is searched first, so why tell it explicitly?

    I only figured the following, but that might be very wrong:

    Suppose I have my own CRT DLL. I load MFC, which in turn loads CRT. Since I use the pre-built MFC (from windowssystem32), it loads CRT (in that case from windowssystem32). This would result in my app using the windowssystem32 version of the CRT DLL instead of the other.

    Nut this, in my understanding, cotradicts the text in MSDN.

    Anyway, if You could clarify the purpose of the .local file, I would be grateful.

    LoadLibrary description says, the DLL is only searched for, if no path is specified. Is this the reason for .local? Is in such case the local file loaded?

    Thanks for your great blog

  8. Mike Dimmick says:

    .local also affects CoGetClassFactory (and, I believe, LoadLibrary with an explicit path); you can then use a local version of a COM server DLL, even if the registry points somewhere else (as long as the DLL names are the same).

    The briefly-available test version of Internet Explorer which popped up message boxes if the page used ActiveX controls loaded with data from the page used this technique. People spotted this technique and realised that they could in fact run older versions of IE side-by-side with newer versions.

  9. Raymond Chen says:

    .local is a Fusion thing. You’ll have better success asking one of the Fusion bloggers, like

  10. project says:

    Raymond, may I report another bug in Windows?

    The meaning of the SHFMT_OPT_FULL flag for SHFormatDrive is reverse in Windows 2000 and 2003. That is when SHFMT_OPT_FULL is specified, the dialog opens with the "Quick format" checkbox on.

  11. Raymond Chen says:

    SHFMT_OPT_FULL: I’ll follow up on this with the doc folks.

  12. Raymond, .local was not a fusion thing. It exists in Windows 2000 while fusion team delivers from Windows XP.

Comments are closed.

Skip to main content