一年前买的CLR via C#还没看完，趁现在还有心，赶紧看起来，这块影响还是非常大的。
第一章 CLR的执行模型
第二遍看这一章了，收获一般，书中很多东西只是抽象的介绍，一提到具体内容就“见某章”，翻过去又觉得一下要看的太多，总的来看，CLR提供了一系列执行机制，刨除历史因素，托管模块在CLR下运行主要利用了几个机制：
IL和元数据(metadata)
一般来说CLR运行的程序以Assembly的形式存在，而Assembly中最重要的组成部分就是IL和MetaData。
JITCompiler机制
IL代码在第一次运行时才会被即时地编译为机器语言，编译器被称为JIT编译器，技术也就是JIT技术，正是由于这种机制深刻地了解了IL代码的执行环境，最终编译出来的代码反而能够取得更高的效率（存疑，未验证）。
.NET Framwork类库
目前还不是很理解为什么会把类库放在这一块，我的理解是，类库这种第三方代码集成方式，并不是一个理所当然的存在，不同语言提供了不同的程序包引用方式，而CLR提供的这种方式虽然没有细讲，但是可以认为，只需要把DLL交给CLR，由于该DLL即其他周边的文件通常被视为是一个完整的Assembly，且可以自描述，所以完全不需要担心CLR内部如何组织，在.NET平台上，程序员只需要关心命名空间、类型兼容这些问题就行了。
通用类型系统CTS
公共语言规范是互操作技术，或者说COM的一个延申，COM的实践在事实上失败以后，微软试图再一次在CLR上提供语言的整合，但是这种整合看起来非常优秀，实际上实现起来也许更加糟糕了，或者说，没有公司会下力气去基于CLR重新编译其他语言的代码？以至于文档缺失，缺乏广泛的使用者。
这个技术在刘佳亮的CurlWrapper工程中应用了，正是这个工程，激发了我对互操作这一块的兴趣，他还写了篇文章吐槽(C++/CLI——想说爱你不容易)[https://zhuanlan.zhihu.com/p/33450706]，然而两年过去了，情况似乎并没啥改善……
互操作性
也许互操作性有一部分是基于上面的通用类型系统CTS的，后面的互操作性介绍写了三种典型的互操作方式：托管代码调用DLL中的非托管函数(DLL由非托管语言实现)，托管代码使用现有的COM组件（COM组件的实现应该是没啥限制的），非托管代码可以使用托管类型（服务器）。
这部分存在很大问题，需要仔细研究一下。