IDC资讯中心
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》一书中得到解释）。
