1. N/A says:

   February 19, 2004 at 11:33 am

   Don’t Repeat Yourself is one of the pragmatic programmer (http://www.pragmaticprogrammer.com/) 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:

   February 19, 2004 at 11:45 am

   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:

   February 19, 2004 at 12:25 pm

   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 (http://www.codeproject.com/script/comments/forums.asp?msg=731338&forumid=1647#xx731338xx). 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:

   February 19, 2004 at 12:31 pm

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

5. asdf says:

   February 19, 2004 at 2:52 pm

   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:

   February 19, 2004 at 3:02 pm

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

7. Muro says:

   February 20, 2004 at 1:48 am

   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:
   
   http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic_link_library_redirection.asp
   
   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:

   February 20, 2004 at 2:44 am

   .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:

   February 20, 2004 at 7:31 am

   .local is a Fusion thing. You’ll have better success asking one of the Fusion bloggers, like http://weblogs.asp.net/alanshi/

10. project says:

    February 20, 2004 at 11:56 am

    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:

    February 20, 2004 at 12:42 pm

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

12. Junfeng Zhang says:

    February 20, 2004 at 5:27 pm

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

13. Office Development, Security, Randomness... says:

    April 24, 2004 at 7:38 pm

Comments are closed.