** Chapter 1 ** ** ： ** **
**
1. 组件技术主要强调的是独立开发和部署程序之间的协定（ contract ，就是说好怎么做就要怎么做）。 COM 是 M$ 首次尝试将这些约定规范化。 COM 出现之前，约定仅仅表现为简单的函数入口，于是 COM 从以前的世界跨出了一大步，是个重大的进步，它将动态加载代码和类型系统以相当一致的方式有机地结合在一起。
2. COM 是编程模型，也是支持的平台技术，但是它缺乏一个稳固的平台技术，因此， COM 技术面临终结。
3. 对于约定描述， M$ 定义和 支持的 COM 支持格式不是一个，而是两个：接口定义语言（ Interface Definition Language ， IDL ）和类型库（ type library ， TLB ）文件。但是无法确定这两种格式谁是“权威”或“标准”，这是主要问题一。
4. 还有， COM 缺乏扩展性。 MIT 小组上世纪 90 年代初就开始研究了一种新的编程模型、它基于现在被称为“ AOP （面向方面编程）”的编程思想。后来的 EJB 就是这个演变而来的。遗憾的是， MTS 小组没有依赖于任何一个 COM 约定格式。随着 VB 的推出， MTS 小组的研究成果宣告死亡。
5. COM 组件约定是基于类型描述的。这个约定是物理的（ physical ），基于二进制的，因此对组件间的调用方式要求非常严格。最后组件的约定最终只是在内存中形成堆栈结构的协议，根本没有描述语义的内容。这样的话，版本控制也是非常大的问题了。 精确要求太高能产生高效的代码，但是也就出现了难以接受的不可靠性。
6. 为了处理 COM 约定及其定义所引发的问题， COM 小组和 MTS 小组决定开发一个新的组件平台，其命名： COM3 à COR(Component Object Runtime) à URT(Universal Runtime) à CLR(Common Language Runtime) 。
7. COM 和 CLR 的 唯一 共同点：组件间的约定是基于类型的。
8. CLR 中组件之间的约定：使用“元数据（ metadata ）”。元数据是机器可读的（ machine-readable ），而且形成规范。而且可以使用“定制属性（ Custom Attribute ）”可以轻易扩展元数据（其实在《 Applied M$ .NET Framework Programming 》——后称《 Applied 》——一书中， Richter 建议把这个理解为一串被写入的被序列化的二进制数据，需要得到时再反序列化出来）。
9. CLR 约定本身是被描述成为类型的逻辑结构。 CLR 不会察看内存中的表现形式，事实上内存中的内容直到运行时才被首次加载，然后再计算成员的实际地址 / 偏移量等。（我的理解是：这种约定是被“读出来”的，不是被“判断出来”的，就好比直接 C&P 文本而不是拿着“纸板书”再 OCR 出来， OCR 要求文本的精度很高 。其实这个理解也蛮牵强的 ** L ** ）。由于这样的“载入延迟”，这样的解析必须到实际部署时才能判断， CLR 为了解决这一点，让组件几乎不包含机器码，使用公共中间语言（ Common Intermediate Language ）来做到这一点（也被称为 IL ， MSIL ）。
10. 由于把本地代码的生成推迟到了实际运行阶段，因此对于 IA-32/Pentium 架构到 IA-64/Itanium 架构发展， CLR 显得意义非凡（其余诸如可以得到“针对机器（指令集）”的优化等可以再《 Applied 》一书中得到解释）。