笔记
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》一书中得到解释）。