通过

32 位和 64 位互操作性

  • 项目

辅助技术应用程序需要跨进程边界进行通信，以便从 Microsoft Active Accessibility 服务器和 Microsoft UI 自动化提供程序获取 UI 信息。 本主题介绍开发 Windows 辅助功能应用程序时需要记住的main进程间通信问题。

当应用程序使用 Windows 自动化 API 时，Microsoft Active Accessibility 和 UI 自动化 运行时组件会自动处理 (IPC) 执行进程间通信所涉及的所有问题和复杂性，包括一个进程为 32 位，另一个进程为 64 位时所涉及的互操作性问题。 Microsoft 认识到，在某些情况下，辅助技术应用程序可能需要使用某种形式的 IPC 而不是 Windows 自动化 API 来与 Microsoft Active Accessibility 服务器或UI 自动化提供程序进行通信。 在这些情况下，Microsoft 建议使用 DCOM 或 Windows 消息 (值小于 WM_USER) 的消息与其他进程通信。 与 Windows 自动化 API 一样，DCOM 和 Windows 消息会自动处理所有 IPC 问题，包括 32 位到 64 位互操作性。

如果 Windows 自动化 API、DCOM 和 Windows 消息不是选项，请在实现所选 IPC 方法时请记住以下问题：

  • 共享内存 - 使用共享内存时，请注意，32 位进程中的结构的大小和布局可能与 64 位进程中的相同结构不同。 对于包含指针或句柄的结构尤其如此。
  • 指针截断 - 尽管 32 位应用程序可以使用 LONGLONG 数据类型来存储 64 位值，但在某些情况下，不存在 Windows API 元素，使 32 位应用程序能够接收来自 64 位进程的 64 位值，或将 64 位值发送到 64 位进程。 例如， GetWindowLongPtr 和 SendMessage 函数截断所有指针值，使 32 位应用程序保留一个无用值。
  • 句柄 - 由于 kernel32 和 user32 句柄在 32 位和 64 位进程中都只有 32 位有效，因此可以在进程之间传输，而不会出现问题。 但是，Windows 定义为句柄的某些项实际上只是包装指针 (例如 HTREEITEM) 。 如果这些“句柄”从 64 位进程传递到 32 位进程，则会被截断。
  • WinEvent 挂钩函数 - 若要向 32 位服务器进程注册上下文内挂钩函数，挂钩函数必须驻留在 32 位 DLL 中。 同样，若要向 64 位服务器进程注册上下文内挂钩函数，挂钩函数必须驻留在 64 位 DLL 中。 如果辅助技术应用程序尝试将上下文中挂钩函数注册到具有不同位深度的服务器，事件仍会传递到挂钩函数，但它们将在上下文外传递。 有关详细信息，请参阅 WinEvents 和 上下文中和上下文外挂钩函数。

有关 32 位和 64 位互操作性的详细信息，请参阅 进程互操作性。

Windows 自动化 API 概述