本帖最后由 liucqa 于 2012-11-18 01:01 编辑
http://www.infoq.com/cn/news/2011/10/ADO-Win7?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_news_clk
一直没搞明白ADO6.0是干嘛的，看了这个知道一点了
构建计算机、Windows 7和传统ADO 作者 Jonathan Allen 译者 侯伯薇 发布于 2011年10月28日 假设你在维护上个世纪九十年代的应用程序，它使用了传统的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的类型库。
| 
沪公网安备 31011702000001号 沪ICP备11019229号-2
发表于 2012-11-18 00:46
