辅助技术应用程序需要跨进程边界进行通信，以便从Microsoft活动辅助功能服务器和Microsoft UI 自动化提供程序获取 UI 信息。 本主题介绍开发 Windows 辅助功能应用程序时需要记住的主要进程间通信问题。
当应用程序使用 Windows 自动化 API 时，Microsoft Active Accessibility 和 UI 自动化运行时组件会自动处理执行进程间通信（IPC）所涉及的所有问题和复杂性，包括一个进程为 32 位时涉及的互作性问题，另一个是 64 位。 Microsoft认识到，有时辅助技术应用程序可能需要使用某种形式的 IPC 而不是 Windows 自动化 API 来与Microsoft活动辅助功能服务器或 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 和 In-Context 和上下文外挂钩函数。
有关 32 位和 64 位互作性的详细信息，请参阅 进程互作性。
相关主题