在一个程序中结合使用32位和64位驱动程序 [英] Combine 32- and 64bit drivers in one program

问题描述

我需要加载.dll文件中提供的不同硬件驱动程序。
问题似乎是一个设备的驱动程序是在64位dll中给出的，而另一设备（相对较旧）显然依赖于32位dll中给出的驱动程序。我想通过用C＃编写的程序来控制它们，该程序将通过python包装器运行。

I need to load different hardware drivers that are provided in .dll files. The problem appears to be that the drivers for one device are given in a 64bit dll, the other device (rather old) apparently relies on drivers given in a 32bit dll. I want to control them through a program written in C# which will be run through a python wrapper.

很明显，我不能直接从一个程序运行两个设备，但是我需要一种相互依赖的寻址方式-例如：设备1等待设备2完成一些操作工作。有什么办法可以解决这个问题，还是我需要在两个单独的程序中运行它们并通过python包装器相互依赖来管理操作？

Obviously I cant run both devices from one program directly but I need a way to address them depending on each other - for example: device 1 waiting for device 2 to finish some job. Is there any way to circumvent this issue or will I need to run them in two separate programs and manage actions depending on each other through the python wrapper?

注意事项

推荐答案

在64位Windows 64位进程上不能使用32位DLL，而32位进程不能使用64位DLL。 Microsoft已已记录：

On 64-bit Windows 64-bit processes can not use 32-bit DLLs and 32-bit processes can't use 64-bit DLLs. Microsoft has documented this:

在64位Windows上，64位进程无法加载32位动态链接库（DLL）。此外，一个32位进程不能加载64位DLL。

On 64-bit Windows, a 64-bit process cannot load a 32-bit dynamic-link library (DLL). Additionally, a 32-bit process cannot load a 64-bit DLL.

您将需要一个与32位DLL进行通信的32位进程和一个与64位DLL进行通信的64位进程位DLL。微软说：

You would need a 32-bit process that communicates with the 32-bit DLL and a 64-bit process to communicate with the 64-bit DLL. Microsoft says this:

但是，64位Windows支持64位和32位进程之间的远程过程调用（RPC）。在同一台计算机上和跨计算机）。

However, 64-bit Windows supports remote procedure calls (RPC) between 64-bit and 32-bit processes (both on the same computer and across computers).

然后，问题变成了如何让Python与这些进程通信的问题之一。需要某种形式的进程间通信（IPC）。微软几十年前创造了一种可以做到这一点的技术-使用Out of Process COM服务器（进程外）的COM接口。

The problem then becomes one of how to have Python communicate with these processes. Some form of Interprocess Communication (IPC) would be needed. Microsoft created a technology decades ago that can do just that - COM interfaces using Out of Process COM servers (out-of-proc).

总体思路是：

• 创建一个64位进程外COM服务器，该服务器包装（并公开）64位DLL的所需方法和数据。


• 创建一个32位进程外COM服务器，该服务器包装（并公开）32位DLL的所需方法和数据。


• 编写实例化COM对象并调用其接口的32位或64位客户端代码。通过 win32com

• Create a 64-bit out-of-proc COM server that wraps (and exposes) the needed methods and data of the 64-bit DLL.
• Create a 32-bit out-of-proc COM server that wraps (and exposes) the needed methods and data of the 32-bit DLL.
• Write either 32-bit or 64-bit client code that instantiates the COM objects and calls their interfaces. Python can be used as a COM client via win32com

COM提供了一个IPC机制，该机制允许64位客户端访问外部的64位-proc COM服务器，供64位客户端访问32位进程外服务器。您甚至还可以让32位客户端与32位和64位进程外COM服务器进行通信。

COM provides an IPC mechanism under the hood that allows a 64-bit client to access a 64-bit out-of-proc COM server and for a 64-bit client to access a 32-bit out-of-proc server. You can even have 32-bit clients communicate with 32-bit and 64-bit out-of-proc COM servers as well.

我还没有做过底层Windows使用更新的MS语言进行工作。当我不得不做您需要解决的问题时，可以轻松编写COM服务器和COM接口的两种主要技术是：

I haven't done low level Windows work using the newer MS languages. When I had to do what you needed in your question the two main technologies that made it easy to write COM servers and COM interfaces were:

• 使用 Microsoft基础类的MSVC / C ++ （MFC）


• MSVC / C ++使用活动模板库（ATL）。

• MSVC/C++ using Microsoft Foundation Classes (MFC)
• MSVC/C++ using Active Template Library (ATL).

我有一个首选项，因为它不需要MFC库且开销较小。

I had a preference for ATL since it didn't require the MFC library and had less overhead.

这篇关于在一个程序中结合使用32位和64位驱动程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！