構建計算機、Windows 7和傳統ADO
假設你在維護上個世紀九十年代的應用程序，它使用了傳統的 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的類型庫。
查看英文原文：Build Machines, Windows 7, and Classic ADO