Build Machines, Windows 7, and Classic ADO

Posted by Jonathan Allen on Oct 19, 2011

Sections

Development

Topics

Build systems ,

Programming ,

Legacy Code ,

Windows 7 ,

COM ,

ADO ,

Visual Basic for Applications

Share |

RELATED Research

Imagine you are doing maintenance on an application from the late 90’s that uses the classic ADO libraries. The recompiled code works fine on any Windows 7 SP1 machine, but mysteriously crashes on the Windows XP machines that have been running the program for nearly a decade. This is the problem facing lots of maintenance developers.

When this problem first arose Microsoft assumed that it would only affect a handful of developers. Surely there can’t be that many people using the most recent version of Windows to compile applications using a 15 year old data access technology. Evan Basalik continues,

What happened is that we realized that some of our ADO APIs used platform dependent data types. By this I mean that the 32-bit version of the API used LONG, but the 64-bit version of the same API used LONGLONG. This caused problems when 64-bit applications tried to consume these platform dependent data types and the caller’s data type did not match that of the callee’s. http://support.microsoft.com/kb/983246 discusses a scenario where a VBA macro runs into this exact problem. Unfortunately, we drastically underestimated the number of customers who were recompiling ADO applications on Windows 7 SP1. Even worse, when I say drastically, I really mean DRASTICALLY.

As soon as we realized the magnitude of the problem, we started scrambling to come up with a better solution. At this point, though, our significantly less than ideal first attempt had compounded the problem because it had the potential to spread the changed GUIDs to downlevel OSes. At this point, we made the painful decision to pull http://support.microsoft.com/kb/983246. Yes – we recognized that it would leave some scenarios like VBA without a workable solution, but we deemed that a better option than continuing to spread the modified GUIDs. Although not ideal, our standing recommendations were to use either the backward compatible libraries from http://support.microsoft.com/kb/2517589 or to compile on Windows 7 RTM. While not covering every scenario, it covered the bulk of them and was the best option we could provide without massive re-architecting.

Now, I am happy to announce that we are coming out with a much better solution. We are going to do the following:

1. #Ship the 6.0 type library from Windows 7 RTM via the new type library file msado60.tlb. This will ship for multiple platforms.
2. Ship a new 6.1 type library (which contains both new and deprecated interfaces) and embed it inside the msado15.dll
3. Revert back all 2.x type libraries to what they looked like in Windows 7 RTM.

The new long term solution is essentially ready, but won’t be released until next year to allow for extensive testing. Once this happens, the 6.1 type library can be used for 64-bit VBA applications and for programs that don’t have to run on older operating systems. Everyone else will continue using the 2.x and 6.0 type libraries.