DSOFramer 之一：在 64 位系統注冊 DSOFramer

DSOFramer是微軟提供的一款用於在線編輯、調用Word、Excel等Office程序的ActiveX組件。很多第三方的Office組件都是基於DSOFramer組件開發的。今天我們不講如何使用DSOFramer組件，網上關於DSOFramer組件使用方法的文章已經很多了，而是講一下在使用DSOFramer組件開發時的一些坑。

DSOFramer組件的全名是dsoframer.ocx。所有關於DSOFramer組件使用方法的文章都會告訴你，使用DSOFramer組件，第一步必須在Windows操作系統中注冊該組件。注冊方法很簡單：

1. 將dsoframer.ocx復制到%windir%\system32目錄。
2. 在命令行運行regsvr32命令注冊dsoframer.ocx。

注冊成功后，Windows操作系統會提示“DllRegisterServer 在 dsoframer.ocx 成功”。

.

到目前為止，貌似一切順利。不過如果你像我一樣使用64位Windows操作系統，你已經不知不覺掉到坑里去了。為什么呢？我們繼續往下看。

假設，我們已經編寫好調用DSOFramer的程序，當我們運行程序時會發生什么事情？“鐺”！是的，沒錯，系統彈出“應用程序無法處理的異常”。

為什么會出現這個錯誤呢？我們不是已經在system32目錄注冊dsoframer.cox了嗎？為什么會提示“沒有注冊類”呢？

是的，問題就在這里。如果我們使用的是32位Windows操作系統，那么，OK，程序在運行時不會有任何問題。但是很不幸，我使用的是64位Windows操作系統。使用64位Windows操作系統的朋友可能會發現在%windir%目錄下除了常見的system、System32目錄以外，還有一個SysWOW64目錄。在32位Windows操作系統中，System32目錄用於存放32位DLL，而在64位Windows操作系統中，據稱為了保持向下兼容性，System32目錄用於存放64位DLL，而新增加的SysWOW64用於存放兼容的32位DLL（雖然感覺上System32和SysWOW64兩個目錄的作用應該完全相反）。

之所以會出現前面的異常，是因為DSOFramer是32位組件。因此，在32位Windows操作系統中，應該將其復制到System32目錄中注冊；而在64位Windows操作系統中，應該將其復制到SysWOW64目錄中注冊，而不是復制到System32目錄中。

如果在64位Windows操作系統中，我們將dsoframer.ocx復制到SysWOW32目錄，然后使用regsvr32注冊組件。那么，運行程序時就不會再出現“沒有注冊類”的異常了。

另外，需要注意的是，在Visual Studio的編譯選項中，目標CPU選項的默認設置是Any CPU。很多情況下，我們不會改變這個默認設置，而是由.net framework JIT在運行時根據系統環境自由決定如何裝載程序。但是，由於DSOFramer是32位組件的原因，在編寫調用DSOFramer組件的應用程序時，應該將編譯選項中的目標CPU設置為x86。這樣才能保證程序在運行時能夠在正確的位置找到注冊的DSOFramer組件。

因此，在使用DSOFramer組件時，最佳實踐是：

1. 在32位Windows操作系統中，將dsoframer.ocx組件復制到%windir%\System32目錄，並使用regsvr32命令注冊。
2. 在64位Windows操作系統中，將dsoframer.ocx組件復制到%windir%\SysWOW64目錄，並使用regsvr32命令注冊。
3. 在Visual Studio中，將調用DSOFramer組件項目的編譯選項中的目標CPU設置為x86。

最后，SysWOW64中“WOW64”的含義是“Windows on 64-bit Windows”。所以，你就會明白，為什么在64位Windows操作系統中把dsoframer.ocx組件復制到SysWOW64目錄了，因為它是運行在“64位Windows上的（32位）Windows”的32位DLL組件。