避免信息隐藏

有时，程序会有意或无意中向 RPC 封送处理引擎隐藏信息。 以下是一些示例：

• 以无差别字节块的形式发送数据结构
• 通过使用方法的副作用来利用性能，以跨网络传输其他数据
• 尝试通过将句柄作为 DWORD 或 ULONG 传递来伪装它

这些技术几乎可以保证在将应用程序移植到 64 位 Windows 之前引入兼容性问题。

使用上下文句柄向代表客户端保留的服务器上下文提供不透明句柄，而不是在标准远程过程调用中将服务器上下文作为 DWORD 发送。 当服务器为客户端创建上下文句柄时，上下文由 RPC 运行时定义的 GUID 标识。 不会在网络上使用指针，并且操作在 32 位或 64 位边界上是完全透明的。 有关使用上下文句柄的详细信息，请参阅 上下文句柄。

DCOM 接口无法使用上下文句柄，因为 COM 提供自己的上下文管理。 可以将接口指针传递到 COM 对象，而不是创建上下文句柄。 然后，可以直接通过接口指针调用方法，或将指针置于其他调用中。 若要释放服务器对象，客户端通过接口指针调用接口的 Release 方法。

同样，有时你可能无法更改要移植的代码的原始设计。 如果无法避免将指针作为 DWORD 通过网络发送，则必须在 DWORD 值和指针之间实现某种形式的服务器端映射。 执行此操作的一种方法是将客户端应用程序中的指针更改为指针精度类型，例如 ULONG_PTR 或 DWORD_PTR。 然后使用 MIDL [call_as] 属性将指针作为 DWORD 值放在网络上。 客户端包装器只需传递参数。 服务器端包装器处理两种类型之间的映射。 同样，可以使用 [transmit_as] 属性或 [represent_as] 属性将数据转换为向后兼容的线路表示格式。

如果向后线兼容性不是问题，或者句柄不用于远程调用，并且你确信永远不会发生 32 位到 64 位进程的远程调用，则可以将参数重新定义为 ULONG64。 如有必要，可以修改 32 位应用程序以向用户传递 DWORD 。 或者，可以使用 32 位 Windows 上的 DWORD 和 64 位 Windows 上的 ULONG64 ，从每个平台的单独 IDL 文件生成单独的存根。