假设你在维护上个世纪九十年代的应用程序，它使用了传统的 ADO 库。重新编译的代码会在所有安装了 Windows 7 SP1 的计算机上正常运行，但是却会在安装有 Windows XP 的计算机上神奇地崩溃，而该程序已经在上面运行了快十年。这是很多做维护工作的开发者所面临的问题。
当这个问题最初发生的时候，微软认为它只会对很少开发者产生影响。的确，不会有很多这样的开发者，他们使用最新版本 Windows，却要编译的应用程序却使用的是 15 年前就出现的旧数据访问技术。 Evan Basalik 继续说到：
我们意识到 ADO 的一些 API 使用了与平台相关的数据类型。我这么说指的是，32 位版本的 API 使用 LONG，而同样 API 的 64 位版本使用的是 LONGLONG。这就导致，当 64 位的应用程序试图使用这些与平台相关的数据类型时，调用程序的数据类型又无法与被调用方法匹配，从而就会产生问题。 http://support.microsoft.com/kb/983246 讨论了一种情况，其中 VBA 宏会产生上述的问题。不幸的是，我们大大低估了在 Windows 7 SP1 中重新编译 ADO 应用程序的客户数量。更坏的是，我说的是“大大低估”，实际上的意思是“极度低估”了。
当我们意识到这个问题的严重性时，就开始努力解决，希望能够得出更好的解决方案。然而此时，我们的首次尝试显然与理想状况相去甚远，这使得问题进一步恶化，因为可能会把改变后的 GUID 应用到底层的操作系统中。这时，我们不得不做出痛苦的决定，开始推动 http://support.microsoft.com/kb/983246 中的做法。是的，我已经意识到会有一些情况，像 VBA 无法得出有效的解决方案，但是我们认为，和继续应用变更后的 GUID 相比，那还是比较好的选择。尽管那并不理想，但我们的建议是，或者使用从 http://support.microsoft.com/kb/2517589 可以获得的向下兼容程序库，或者在 Windows 7 RTM 中对其进行编译。尽管这无法覆盖所有情况，但可以覆盖了大部分情况，并且是在不进行大规模重新设计架构的情况下我们所能够提供的最佳方案了。
现在，我很高兴地宣布，我们已经得出了更好的解决方案。我们会做以下工作：
- 通过新的类型库文件 msado60.tlb 为 Windows 7 RTM 发布 6.0 类型库。这是针对多个平台发布的。
- 发布新的 6.1 类型库（其中既包含新的接口，也包含了不建议使用的接口），并把它嵌入到 msado15.dll 中。
- 把所有 2.x 版本的类型库回退到 Windows 7 RTM 中的版本。
新的长期解决方案实际上已经准备就绪了，但是我们会在明年才会发布，因为需要对其进行更广泛的测试。一旦发布，开发者就可以使用 6.1 类型库来编写 64 位的 VBA 应用程序，也可以使用它来编写不需要运行在旧操作系统中的程序。而其他人都会继续使用 2.x 和 6.0 的类型库。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论