RPC NDR 格式字符串
NDR 引擎：32 位解释器
本文档介绍 32 位 NDR 引擎的格式字符串描述符（有时称为 MOP）。 本部分介绍与从 –Oi 解释器层到 –Oif 解释器层的演变相关的更改，以及与管道和异步支持相关的新增内容。
本文档从引擎的角度介绍当前的 Microsoft 接口定义语言 (MIDL) 技术，以及当前的 NDR 引擎。
概述
NDR 引擎是远程过程调用 (RPC) 和 DCOM 组件的封送处理引擎。 它处理远程调用的所有与存根相关的问题。 作为一个进程，NDR 封送处理由 MIDL 生成的存根、MIDL JIT 类型生成器中的 C 代码驱动，或者由其他工具生成或手动编写的存根驱动。 反过来，NDR 引擎 (与特定传输通信的 DCOM 或 RPC) 驱动基础运行时。
设计的原始目标是根据 MIDL 编译器提供的信息为任意数据提供有效的封送处理工具。 本文档中所述的格式字符串（事实上是编译器为 NDR 引擎使用而生成的所有信息）一直被视为编译器和引擎之间的内部接口。 同样，可用于引擎处理运行时问题的接口也大多是内部 (RPC 运行时端存在一些异常，而引擎使用的某些 DCOM 接口是外部) 。
封送的两种典型方法始终内联和数据驱动， () 技术进行解释。 MIDL 通过 C 生成的存根中的 –Os 和 –Oi* 开关支持。 此外，MIDL 可以生成 oleautomation 包使用的 TLB 库。 因此，引擎内部的一个视角是它由两个部分组成。
第一个例程是一组处理大小调整、封送等的例程，对应于结构或数组等典型数据类型对象。 这些例程已针对性能进行了微调;例如，他们通常会尽可能尝试阻止复制数据。 此部分通常称为核心 NDR 引擎。
第二部分由解释器及其相关部分组成。 解释器使用来自核心 NDR 引擎的例程（就像来自内部库一样），以便执行远程调用，并根据需要封送和取消封送其所有参数。
核心 NDR 引擎的使用方式类似，无论是从内联存根还是从解释器中使用。 所有核心引擎例程都取决于存根消息结构传入的状态。 结构由内联存根或解释器正确设置。 多年来，核心引擎一直在不同的环境中使用：目前，解释器实际上是一组多个不同的解释器循环。 它们与新旧 (–Oi 与 –Oif) 解释器相关，以及与数据序列化 (pickling) 、RPC 异步支持和 DCOM 异步支持相关的循环， (RPC 和 DCOM 具有不同的异步编程模型) 。
除了新增功能之外，NDR 引擎演变的一个重要方面是解释器方法的一般转变。 NDR 版本 1.1 作为新的 MIDL 2.0 封送方法的一部分开始，出于性能考虑，首选内联存根。 随着 NDR 的最新版本， –Oif 已成为编译器使用最广泛的模式，几乎排除了内联存根。
以下主题更详细地介绍了 RPC NDR 引擎格式字符串描述符：