No code is an island

Date:February 19, 2004 / year-entry #68
Orig Link:
Comments:    13
Summary: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...

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.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index