One of the banes of my existence is maintaining backward compatibility to versions of Windows from 15 years ago while supporting new features of Windows Vista. It's quite a juggling act. I use three tactics. The first is pre-emptive: every time I write new code that includes Windows APIs, I double-check the requirements of the APIs on MSDN. Often I'll find that I want to use an API that doesn't work on Wind I use three tactics. The first is pre-emptive: every time I write new code that includes Windows APIs, I double-check the requirements of the APIs on MSDN. Often I’ll find that I want to use an API that doesn’t work on Windows 9X systems, or that only works in Windows Vista and above.The second tactic is adaptive: I dynamically load the DLLs and entry points that aren’t compatible with all the systems my software supports. This is a real pain in the neck, but I have some class libraries that make it less painful than writing all the Windows API calls and C++ type casts that would otherwise be needed.The third tactic is one of testing. I have five computers in my office that cover a range of Windows versions, and one of them has Virtual PCs that cover most of the other Windows versions, plus a bunch of Linux versions. When I create a new build, I test on all the Windows versions I have covered. When there’s a problem loading the software on one or more systems, I run the Microsoft dependency walker tool depends.exe against the software on those systems. Usually, that’s enough to help me locate the problem or problems, although sometimes I have to go back to MSDN and read the API descriptions again, carefully. Sometimes there are obscure notes about #include files or libraries that need to be used for compatibility with older systems; using these workarounds generally fixes the problems. It’s still a pain in the neck, however.Q: How did God create the world in seven days?A: He didn’t have an installed base. Software Development