從64位應用程序加載/與vb6 COM DLL進行交互

我正在研究一個應用程序，它具有多個用VB6編寫的dll。 VB6代碼包括COM dll和ocx控件。其餘的代碼是C++和C＃。我已被分配任務使應用程序代碼庫與64位體系結構兼容。對於C/C++代碼，可以使用大量的幫助資料，因此這不是問題。但將所有這些vb6代碼重寫爲.net或其他語言以使其與64位兼容並不容易。我也不理解所有的基礎邏輯，所以只是假設重寫是沒有問題的。從64位應用程序加載/與vb6 COM DLL進行交互

另外，我們都知道，VB6的DLL在64位環境中無法正常工作。那麼我有什麼選擇。

1）隱蔽每個DLL的進入，這將在32位被加載一個EXE，它可以通過COM接口與我的64位應用程序的其餘部分交互。你有沒有預見到這種方法的任何問題？

2）我編輯註冊表並加載所有的DLL VB6出的過程中，使他們在DLLHOST加載。

3）製作一個單一的32位exe文件，引用該exe文件中的所有這些VB6 dll文件，並在32位地址空間中加載該exe文件，並且我的應用程序的64位部分與32位exe文件進行通信。

這使我想起了所有上述方法的主要問題是做什麼用OCX控件????

任何想法？如果沒有新的想法，而不是上面提到的哪一個將會被你所偏好，爲什麼？

來源

2009-05-21 Paragon

你有沒有想出如何使用COM做64之間的通信，以32？看起來似乎會有某種不匹配。 – 2009-05-21 17:42:12

Nopes，我還沒有開始任何實驗，但會在我遇到任何成功或失敗時立即更新。 – Paragon 2009-05-22 06:34:15

如果你有大量的現有VB6代碼，使用在進程內運行，我想第一個問題，如果遷移到64位真的是值得的。 64位對於服務器應用程序有很多優點，但對於桌面應用程序，32位通常是完全足夠的。由於WOW64預計至少可用10年，因此很少有人反對在64位Windows上運行32位應用程序。

問題是，儘管可能通過使用out-or-process服務器來調整應用程序，使其至少部分以64位模式運行，這可能會對性能產生重大影響在內存開銷）。賠率是，客戶因此絕對沒有選擇64位版本的應用程序的好處。

這就是說，我會說2）或3）將是自然的選擇。 2）當然更容易實現，但3）可以讓您更好地控制應創建多少個進程外服務器以及如何管理其生命週期。

來源

2009-05-21 14:32:47

我正在從SQL 2000 x86遷移到SQL 2008 x64。

這裏我們正面臨着類似的問題。我決定使用DCOM。

它將如何工作？

服務器32位將承載組件和64位設備將呼叫使用DCOM。

有性能損失。順便說一句，與重寫相比的努力......當然值得做。 :)

問候，馬科斯利馬

來源

2011-11-09 10:53:40

從64位應用程序加載/與vb6 COM DLL進行交互

回答

相關問題