討論區快速選單
知識庫快速選單
討論區最近新進100則主題 最紅的App開發語言:Kotlin
[ 回上頁 ] [ 討論區發言規則 ]
請問 64bit 程式使用 32bit COM 元件
更改我的閱讀文章字型大小
作者 : kuolung(kuolung)
[ 貼文 150 | 人氣 1414 | 評價 130 | 評價/貼文 0.87 | 送出評價 39 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2017/3/3 上午 10:47:01
請問我的程式是64bit 的,但是第三方提供的 com 元件是32bit
我用一般的做法,在 64bit 中找不到 該 com 元件
在 CoCreateInstance 就得到 hREGDB_E_CLASSNOTREG class not registered,

改為 32bit 就看到該元件了,
就可正常得到 S_OK

請問我如何在 64bit 的程式環境中使用 32bit 的 com 元件

作者 : kuolung(kuolung)
[ 貼文 150 | 人氣 1414 | 評價 130 | 評價/貼文 0.87 | 送出評價 39 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2018/7/25 上午 09:35:33
沒有人回答,
我自己用 google 大神找到了這一篇文章,

https://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/

這個方式,是可以在 64bit 中建立 32bit 的 com 元件,但是還是無法正常使用,
但是我懷疑是 com 元件供應商的問題,

所以暫時無法再測下去,
作者 : ice_emissary(燃燒的大地) 貼文超過200則
[ 貼文 357 | 人氣 0 | 評價 1730 | 評價/貼文 4.85 | 送出評價 16 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人kuolung註記此篇回應為很有道理 2018/7/25 下午 01:08:36
除非 COM 元件是做成 EXE 形式,否則 DLL 型態的 COM 元件本來就不能混用。
就算有些奇技淫巧讓你的程式可以呼叫不同 CPU 型態的 COM DLL,也極不推薦使用,因為後續可能也會有非常多的問題。

原因很簡單,DLL 型態的 COM 本身仍是個 DLL,DLL 載入後,它的一切資料、指令等都會併入呼叫者的行程空間,視同使用者程式的一部份。
那麼,不同的 CPU 指令、不同的暫存器規格、不同的函式呼叫堆疊通通在一起混用的話,程式能不亂掉當掉才是奇蹟!

EXE 型態的 COM 因其是個 EXE,其行程和使用者行程完全獨立,其溝通交涉是透過 RPC 完成,讓作業系統處理中間的環節。
因此不同 CPU 結構的使用者程式和 COM 才能合作無礙。

正常的解決方法通常有三:
1. 像該 COM 發行商取得符合你所需的 CPU 架構版本 COM 元件。白話文來說,在你的案例上,你要找 x86-64 (或也許 IA-64?)格式的 COM 元件來用。
2. 把 COM 元件改寫成 EXE 形式。
3. 把你的程式改成與該 COM 元件一樣的 CPU 架構重編譯。也就是把你的程式編譯成 x86 程式。
作者 : ice_emissary(燃燒的大地) 貼文超過200則
[ 貼文 357 | 人氣 0 | 評價 1730 | 評價/貼文 4.85 | 送出評價 16 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人kuolung註記此篇回應為很有道理 2018/7/26 上午 09:14:04
那個網站教你的方式看起來複雜,但其實原理就是我教你的解法中的第三種。

簡單說明網站裡教你的方法:
1. 重寫一個 x86 程式(B 程式),這個程式不做別的事,就負責載入你指定的 x86 COM,執行裡面的功能並傳回結果。
2. 你原本的 x64 程式(A 程式)使用任何一種 IPC 方法(檔案、網路、記憶體映射、系統消息等等)與 B 程式溝通,命令他執行某功能並傳回結果。
3. A 程式額外的這些行為會讓 A 程式有些複雜,所以他還建議你把 A 程式裡面負責與 B 程式通訊、呼叫的部份包裝成一個 x64 DLL (W DLL)。

最後,你的 A 程式載入 W DLL 並呼叫其功能。
W DLL 的介面可以做的和該 COM 元件相同,以致你好像就在使用 x64 版的 COM。但其實它是繞了一大圈,透過 IPC 呼叫另一個 x86 程式,然後由他轉叫真正的 x86 COM 元件。
作者 : kuolung(kuolung)
[ 貼文 150 | 人氣 1414 | 評價 130 | 評價/貼文 0.87 | 送出評價 39 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2018/7/26 下午 01:50:24
我原來就是用這個方式來做,但是選用了個比較不方便的方式溝通,就是 winsock , 好處是可以跨電腦,壞處是要自己寫個 winsock server 還要訂 protocol 弄的有一點複雜,

還是大大有什麼建議,比用 winsock 好的溝通介面 ,速度又比較快

所以就改用第一個方式,把 COM 包成一個 EXE ,再用 COM 介面使用他們

這樣做目前有一個問題,算是人門的問題,我如何用 VS2017 DEBUG 程式,被 DEBUG的程式要用 adminitrator 的權限執行才行
查了之前的一些討論,都說只要 vs 2017 本身用 admin 啟動,被 debug 也會以 admin 權限執行,

但是,我目前的環境測試卻不行,

我是用 win10 64bit 企業版,vs 2017 enterprise 版
作者 : kuolung(kuolung)
[ 貼文 150 | 人氣 1414 | 評價 130 | 評價/貼文 0.87 | 送出評價 39 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2018/7/26 下午 02:14:40
會有這個 debug 的問題是因為,

我已將 com 包成一個獨立的 exe 檔,且可以執行,

但是如果我從客戶端程式去啟動它,就可以得到這個 com的介面並對他操作,

我先執行com exe ,再執行客戶端就連不到 com 元件,

但是我用 administrator 權限去執行 com exe , 再執行客戶端就可以連 com 元件,

所以我假定是用 administrator 執行 debug 就可以對 com exe 除錯,

但是,我用 administrator 執行 vs 2017 再用 debug mode 去執行 com exe
再執行客戶端程式,還是連不到 com exe

大大有何建議


作者 : ice_emissary(燃燒的大地) 貼文超過200則
[ 貼文 357 | 人氣 0 | 評價 1730 | 評價/貼文 4.85 | 送出評價 16 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2018/7/26 下午 02:25:05
> 我原來就是用這個方式來做,但是選用了個比較不方便的方式溝通,就是 winsock ,
> 好處是可以跨電腦,壞處是要自己寫個 winsock server 還要訂 protocol 弄的有一點複雜,
>
> 還是大大有什麼建議,比用 winsock 好的溝通介面 ,速度又比較快

比 winsock 更好的溝通介面?嗯,那就改用 unix socket 吧!

開玩笑的!
不過我層經用過各種 IPC 交流方式,比如說檔案、網路介面、共用記憶體區塊等等,
雖各有優缺,但不蠻您說,依據使用經驗,socket 是各種問題最少、最快速、最可靠的 IPC 方式了!

雖然像你說的,用 socket 溝通要自己處理 packet、protocol 等等,有些麻煩;
但若要做到能保證溝通的正確性、穩定性、和可靠性等等的話,試了一圈之後你會發現,
socket 可能還是所有 IPC 方法中最容易做的!

另外還有一種東西叫「具名管道」(named pipe),用起來和 TCP socket 幾乎一樣,不過只能在本機上使用,
但也因如此他效能更好,對系統的負載也更低,你也可以考慮使用。

> 所以就改用第一個方式,把 COM 包成一個 EXE ,再用 COM 介面使用他們

你這個提議很不錯,就寫個 x86 程式把它包成 COM 規格的 EXE 來用,
可以省掉 x64 程式的 wrapper DLL 和 IPC 工作,把它丟給系統去處理!

> 我如何用 VS2017 DEBUG 程式,被 DEBUG的程式要用 adminitrator 的權限執行才行
> 查了之前的一些討論,都說只要 vs 2017 本身用 admin 啟動,被 debug 也會以 admin 權限執行,
>
> 但是,我目前的環境測試卻不行,

這個我就幫不了你了!
我 VS 最高只用到 2008、Windows 最高我也只用到 7,再上去也沒興趣去弄!
這個問題屬於 VS 的操作範疇,也許某些熟悉最新版 VS 的人可以回答你吧!
作者 : kuolung(kuolung)
[ 貼文 150 | 人氣 1414 | 評價 130 | 評價/貼文 0.87 | 送出評價 39 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2018/7/27 下午 02:16:37
這個 debug 的問題,解決了,
首先,就算 vs 2017 用 admin 權限執行,被 debug 的程式還是會以一般權限執行

要在 專案的組態屬性->連結器 ->資訊清單檔->UAC執行層級 -> 改為"requireAdministrator"
這樣,被 debug 的程式才會是 admin 權限

因為這個 被 debug 的 com exe 是 admin 權限,

這時 測試的 客戶端也要用 admin 權限才能正常的呼叫 com exe 中 com 元件執行介面程式,

這樣就可以 debug com exe 了

當然,當 debug 完成後,所有的程式,都可以不用 admin 權限執行


 板主 : 青衫 , Raymond
 > Visual C++ - 討論區
 - 最近熱門問答精華集
 - 全部歷史問答精華集
 - Visual C++ - 知識庫
  ■ 全站最新Post列表
  ■ 我的文章收藏
  ■ 我最愛的作者
  ■ 全站文章收藏排行榜
  ■ 全站最愛作者排行榜
  ■  月熱門主題
  ■  季熱門主題
  ■  熱門主題Top 20
  ■  本區Post排行榜
  ■  本區評價排行榜
  ■  全站專家名人榜
  ■  全站Post排行榜
  ■  全站評價排行榜
  ■  全站人氣排行榜
 請輸入關鍵字 
  開始搜尋
 
Top 10
評價排行
Visual C++
1 青衫 11070 
2 Raymond 10090 
3 Clier 7630 
4 小約翰 2500 
5 Cog 2030 
6 coco 1870 
7 aming 1410 
8 牧童哥 1400 
9 r2109 1380 
10 Akira 1350 
Visual C++
  專家等級 評價  
  一代宗師 10000  
  曠世奇才 5000  
  頂尖高手 3000  
  卓越專家 1500  
  優秀好手 750  
Microsoft Internet Explorer 6.0. Screen 1024x768 pixel. High Color (16 bit).
2000-2018 程式設計俱樂部 http://www.programmer-club.com.tw/
0.15625