【问题标题】:Using 64-bits driver from 32-bits application从 32 位应用程序使用 64 位驱动程序
【发布时间】:2009-04-09 03:08:08
【问题描述】:

我有一个必须以 32 位运行的 Windows 应用程序(由于我无法控制的其他限制)。但是,我的应用程序必须调用和访问可能是 32 位或 64 位的驱动程序,具体取决于安装它的系统。

我通过 DeviceIoControl() 调用访问驱动程序,交换包含文件中声明的数据结构。数据结构包含声明为“DWORD_PTR”的字段(我也不控制包含文件)。

我的问题是,在 64 位系统上,驱动程序期望结构包含 64 位整数(因为 DWORD_PTR 声明)。但是,我的 32 位程序将那些 DWORD_PTR 视为 32 位整数。然后,我的数据结构的程序版本与驱动程序对这些结构的理解之间存在数据不匹配。

DeviceIoControl() 以 ERROR_INSUFFICIENT_BUFFER 结束(传递给系统调用的数据区域太小)。我确认如果我将 64 位版本的结构传递给驱动程序,我不会收到此错误。

我有一些丑陋的选择。但我想知道是否有人有更好的建议?


解决方案:

  • 使用 REAL 64 位数据字段 (__int64) 声明共享结构的新副本
  • 动态检查操作系统架构 (32/64)
  • 对 DeviceIoControl() 调用使用 32 位或 64 位版本的结构。

缺点:

  • 我必须手动维护结构声明的显式 64 位副本。随着时间的推移,这可能会很痛苦。

我的其他解决方案是这个解决方案的变体,但它们总是涉及维护结构定义的一些副本(例如在用于 COM 服务器选项的 IDL 中)。

编辑:这是一个 Microsoft 驱动程序,它似乎不使用 IoIs32bitsProcess(irp)!

【问题讨论】:

    标签: windows winapi 64-bit driver


    【解决方案1】:

    您维护 32 位和 64 位版本的结构,并通过设备驱动程序 DEVICE_CONTROL 处理程序中的 IoIs32BitProcess(irp) 函数实现特殊处理,并在需要时将其转换为 64 位结构。这是常见的做法。

    这是good amount of documentation about it on MSDN.

    由于您稍后提到您无法控制驱动程序源代码,因此我建议您在 64 位上维护自己的 32 位变体,并发送正确的变体来检查操作系统架构。似乎没有为驱动程序正确完成结构声明。

    【讨论】:

    • 我不控制驱动程序。 IoIs32BitProcess() 是从驱动程序调用的,而不是我的应用程序。显然不是因为我收到错误代码 ERROR_INSUFFICIENT_BUFFER(传递给系统调用的数据区域太小。)
    • 哦,如果您无法控制驱动程序源代码,那么您基本上需要访问驱动程序提供的结构声明。如果他们不提供任何东西,您需要试验 32 位和 64 位结构。
    • 他们确实提供了结构声明。但是他们将字段声明为 DWORD_PTR。所以我基本上坚持我丑陋的解决方案。我工作,我测试过,但我希望有更干净的东西。
    • 显然他们没有以正确的方式提供结构。对于肮脏的实现,我想不出一个干净的解决方案:)
    • 您不妨考虑向开发驱动程序的一方提交错误。
    【解决方案2】:

    在包含带有结构 defs 的标头时,有没有办法操纵 #define 以使您始终使用 64 位定义?这对我来说似乎是最好的选择(如果可能的话)。

    如果不是,我会在我自己的代码中隐藏 64 位结构——这样只有一个结构 def 需要注意,而不是一堆 if32bit/if64bit 的东西散布在各处——这似乎更多容易出错。也许你可以这样做:

    _ASSERT(sizeof(myStruct) == sizeof(64bitStruct)) 
    

    在您的应用开始时,因此如果您获得更新的标头,您的应用的第一次运行会提醒您需要同步。

    【讨论】:

      猜你喜欢
      • 2011-09-03
      • 2012-02-02
      • 2010-10-10
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-01-19
      • 2010-12-18
      • 2012-05-20
      相关资源
      最近更新 更多