問題定位：源**是在32位的win8上編譯的，在32位的xp 和win 7下執行呼叫迅雷沒問題，但有使用者表示在64位的機器上無法正常呼叫迅雷。
經查，在64位的機器上的確無法呼叫迅雷，日誌檔案顯示，要呼叫的com元件沒有註冊。但測試的win2008上的迅雷是正常的，排除迅雷的問題。
stackoverflow**上的乙個問題提醒了我，64的平台可能跟32位的com介面不匹配！（
後又查資料得知，vs預設的編譯平台是anycpu，意思是編譯出來的程式包含兩套執行邏輯。例如，我機子是32位的，如果以anycpu的方式編譯，編譯出的程式如果執行在32位的windows上則是以32位的方式執行，但如果你是64位的機器，那麼就會以64位的方式執行。（
這樣的邏輯似乎沒有什麼問題，但問題是在我的程式中預設呼叫的是32位的迅雷com元件，也就是說，在64位的機器上，我是以64位的方式呼叫32位的com元件，這就是問題的根源。
了解了問題的根源，解決方案就很簡單的了，將vs的目標編譯平台改為x86，也就是說即使在64位的機器上仍然以32位的方式執行。
問題解決。
ps：雖然問題解決了，但是我在嘗試在32位的機器上並不能不能新增64位的com元件引用，這是不是說無法在32位的機器上呼叫64位com元件，生成64位的應用程式了呢？
sizeof在32位和64位機器上的執行結果
今早在網上偶然看到一篇文章 32位程式移植到64位平台前的準備工作 文中介紹了32位平台的程式向64位平台進行移植需要注意的一些事項和操作建議。自己對於64位平台上各種資料型別分別占用多少位元組，存在一些疑問，所以用c c 中的sizeof分別在這兩種平台上進行了測試。執行結果如下 分別用藍色和紅色...
在64位Redhat上安裝Centos的yum源
至於為什麼不用redhat自帶的，因為redhat的yum源是需要註冊才能用的，一般自帶的yum有各種各樣的問題，所以我們先把它卸了唄，裝個好用的。1 rpm aq grep yum xargs rpm e nodeps 先刪除掉原來的yum 2 rpm ivh yum metadata parse...
在64位的linux上執行32位的程式
1.症狀 2 ldd bin檔案 的輸出為 not a dynamic executable 3 file bin檔案 的輸出顯示程式是32位 2.解決 debian上只要安裝 ia32 libs這個包 apt get install ia32 libs 就可以了。sudo apt get inst...