构建计算机、Windows 7和传统ADO

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