Last August I wrote about maintaining backward compatibility to versions of Windows from 15 years ago while supporting new features of Windows Vista. Several of you had trouble believing I would continue to go to all that trouble. I have finally given up, although not voluntarily. As it happens, I had to merge some code from a program into an ActiveX control. The program is compiled with Visual Studio 2005 (VS05 Last August I wrote about maintaining backward compatibility to versions of Windows from 15 years ago while supporting new features of Windows Vista. Several of you had trouble believing I would continue to go to all that trouble.I have finally given up, although not voluntarily.As it happens, I had to merge some code from a program into an ActiveX control. The program is compiled with Visual Studio 2005 (VS05), maintained by another developer, and runs on Windows 2000, XP, 2003 and Vista. We haven’t yet tested it on Windows Server 2008. The ActiveX control was compiled with Visual Studio .NET 2003 (VS03) and ran on Windows 95 and up. When I tried adding the new code and compiling in VS03, it was clear that I’d have my work cut out trying to remove all the calls to new library functions to get it to compile without errors. Then I’d have to face updating my branched code every time the developer did a maintenance release. There was too much code for me to go the conditional compilation route and get this working in a reasonable amount of time.I tried upgrading the project to Visual Studio 2008 (VS08). The new code compiled without warnings, but my old code had bunches of errors and warnings. Fortunately, the errors were all from duplicate definitions, and it was easy enough to remove the inline definitions that were now coming from the default SDK. The warnings were mostly to get me to update to “safe” string functions: that can wait until I have time, since this code has been heavily tested over many years.I got the new code working and tied into the proper ActiveX interfaces, and started testing it on my array of Windows computers and virtual PC images. When I got to the Windows 98 SE Virtual PC, I discovered that the control wouldn’t load. I explored the DLL with “depends” and discovered that the new code uses five kernel functions that weren’t introduced until Windows 2000. Using my standard techniques, I wrote a dynaload class for those five functions and modified the code to use them.The control still wouldn’t load in Windows 98.To make a long story (think days of failed experiments) short, we discovered that VS08 no longer targets Windows 9x. Apparently VS05 doesn’t, either. There are a couple of kernel functions called by the C++ libraries that require later versions of Windows. In order to get this control built in VS08 to work on Windows 9x, I’d have to make custom modifications to the C++ libraries and link to them. I’d also have to reapply my changes every time Microsoft updated the libraries. That was the last straw for me. I reverted to the version of the control without the last group of dynaloads, and I now plan to leave Windows 9x behind. There’s no real business reason to keep supporting it, and now there would substantial costs in attempting to do so.I might wish that Microsoft had continued to target Windows 9x in VS05 and VS08, but I can’t really blame them. They, too, need to leave the past behind in order to move forward. Software Development