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 通过其 –Os 和 –Oi* 开关在其 C 生成的存根中支持这两种开关。 此外，MIDL 还可以生成 oleautomation 包使用的 TLB 库。 因此，引擎内部的一个视角是它由两个部分组成。
第一个例程是一组处理大小调整、封送等的例程，这些例程对应于结构或数组等典型数据类型对象。 这些例程针对性能进行了微调;例如，它们通常会尽可能尝试阻止复制数据。 此部分通常称为核心 NDR 引擎。
第二部分由解释器及其相关部分组成。 解释器使用核心 NDR 引擎中的例程，就像来自内部库一样，以便执行远程调用，并根据需要封送和取消封送所有参数。
核心 NDR 引擎以类似的方式使用，无论是从内联存根还是从解释器使用。 所有核心引擎例程都取决于存根消息结构传入的状态。 结构由内联存根或解释器适当设置。 多年来，核心引擎一直在不同的环境中使用：目前，解释器实际上是一组不同的解释器循环。 这些与旧和新版本（–Oi 与 –Oif） 解释器以及与数据序列化（选取）、RPC 异步支持和 DCOM 异步支持相关的循环（RPC 和 DCOM 具有不同的异步编程模型）。
除了新增新功能之外，NDR 引擎演变的一个重要方面是解释器方法的一般转变。 NDR 版本 1.1 开始是新的 MIDL 2.0 封送方法的一部分，内联存根是性能注意事项的首选。 随着 NDR 的最新版本，–Oif 已成为编译器最常用的模式，几乎可以排除内联存根。
RPC NDR 引擎格式字符串描述符在以下主题中进行了更详细的描述：