Flier Lu <flier_lu@sina.com.cn>
  
注意：本系列文章在水木清华BBS(smth.org)之.Net版首发，
     转载请保留以上信息，发表请与作者联系
  
  与传统的Win32可执行程序中的本机代码(Native Code)不同，
微软推出的.Net架构中，可执行程序的代码是以类似Java Byte Code的
IL (Intermediate Language)伪代码形式存在的。在.Net可执行程序载入后，
IL代码由CLR (Common Language Runtime)从可执行文件中取出，
交由JIT (Just-In-Time)编译器，根据相应的元数据(Metadata)，
实时编译成本机代码后执行。
  因此，一个CLR可执行程序的启动过程可以分为三个步骤。
  首先，Windows的可执行程序载入器(OS Loader)载入
PE (Portable Executable)结构的可执行文件映像(PE Image)，
将执行权传递给CLR的支持库中的Unmanaged Code。
  其次，启动或使用现有的CLR引擎，建立新的应用域(Application Domain)，
将配件(Assembly)载入到此应用域中。
  最后，将执行权从Unmanaged Code传递给Managed Code，执行配件的代码。
  下面我将详细说明以上步骤。
  
  自从Win95发布以来，可执行程序的PE结构就没有发生大的改动。
此次.Net平台发布，也只是利用了PE结构中现有的预留空间，
以保持PE结构的稳定，最大程度保持向后兼容。
（详情请参看笔者《MS.Net平台下CLR 扩展PE结构分析》一文）
  CLR程序在编译后，将可执行程序入口直接以一个间接跳转指令
指向mscoree.lib中的_CorExeMain函数（DLL将入口指向_CorDllMain函数）。
因此CLR可执行程序在被OS Loader载入后，将由_CorExeMain函数处理CLR引擎
启动事宜。此函数将启动或使用一个现有的CLR Host来加载IL代码。
  常见的CLR Host有ASP.Net、IE、Shell、数据库引擎等等，
他们的作用是启动一个CLR实例，管理在此CLR实例中运行的CLR程序。
  
  我们接着来看一看一个CLR Host是如何实际运作的。
  CLR作为一个引擎，在同一台计算机上是可以存在多个版本的，
不同版本之间可以通过配置良好共存。在
%windir%\Microsoft.NET\Framework
（%windir%表示Windows系统目录所在位置）目录下，
我们可以看到以版本号为目录名的多个CLR版本，
如%windir%\Microsoft.NET\Framework\v1.0.3705等等，
也可以在注册表的
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\v1.0
键下查看详细的版本兼容性.Name是Build号,Value是兼容的Build号.
而每一个CLR版本又分为Server和Workstation两类运行库,
我们等会讲创建CLR时会详细谈到.
  CLR Host在启动CLR之前,必须通过一个startup shim的库进行操作,
实际上就是mscoree.dll,他提供了版本无关的操作函数,以及启动CLR所需
的支持,如CorBindToRuntimeEx函数.
  CLR Host通过shim的支持库,将CLR引擎载入到进程中.具体函数如下
STDAPI CorBindToRuntimeEx(LPCWSTR pwszVersion,
  LPCWSTR pwszBuildFlavor, DWORD startupFlags,
  REFCLSID rclsid, REFIID riid, LPVOID FAR *ppv);
  参数pwszVersion指定要载入的CLR版本号,注意必须在前面带一个小写的"v",
如"v1.0.3705",可以通过查阅前面提到的注册表键,获取当前系统安装的不同CLR
版本情况,或指定固定的CLR版本.也可以传递NULL给这个参数,系统将自动选择最新
版本的CLR载入.
  参数pwszBuildFlavor则指定载入的CLR类型,"srv"和"wks".
前者适用于多处理器的计算机,能够利用多CPU提高并行性能.对单CPU
系统而言,无论指定哪种类型都会载入"wks",传递NULL也是如此.
  参数startupFlags是一个组合参数.由多个标志位组成.
  STARTUP_CONCURRENT_GC标志指定是否使用并发的GC(Garbage Collection)
机制,使用并发GC能够提高系统的用户界面相应效率,适合窗口界面使用较多的程序.
但并发GC会因为无谓的线程上下文(Thread Context)切换损失效率.
  以下三个参数用于指定配件载入优化策略.我们等会详细讨论.
  STARTUP_LOADER_OPTIMIZATION_SINGLE_DOMAIN = 0x1 << 1,
  STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN  = 0x2 << 1,
  STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN_HOST = 0x3 << 1,
  接着的三个参数用于获取ICorRuntimeHost接口.
  实际调用实例如下.
CComPtr<ICorRuntimeHost> spHost;
CHECK(CorBindToRuntimeEx(NULL, L"wks",
  STARTUP_LOADER_OPTIMIZATION_SINGLE_DOMAIN | STARTUP_CONCURRENT_GC,
  CLSID_CorRuntimeHost, IID_ICorRuntimeHost, (void **)&spHost));
  这行代码载入最高版本CLR的wks类型运行库,为单应用域进行优化并使用并发GC机制.
  前面提到了配件载入优化策略,要理解这个概念,我们必须先了解应用域的概念.
传统Win程序中,资源的分配管理单位是进程,操作系统以进程边界将应用程序实例隔离开
,
单个进程的崩溃不会对其他进程产生直接影响,进程也不能直接使用其他进程的资源.
进程很好,但使用进程的代价太大,为此Win32引入了线程的概念.同一进程中的线程能够
共享资源,线程管理和切换的代价也远远小于进程.但因为在同一进程中,线程的崩溃会直
接
影响到其他线程的运行,也无法约束线程间数据的直接访问等等.
  为此,CLR中引入了Application Domain应用域的概念.应用域是介于进程和线程
之间的一种逻辑上的概念.他既有线程轻巧,管理切换快捷的优点,也有进程在稳定性方面
的优点,单个应用域的崩溃不会直接影响到同一进程中的其他应用域,应用域也无法直接
访问同一进程中的其他应用域的资源,这方面和进程完全相同.
  而CLR的管理就是完全面向应用域一级.CLR不能卸载(Unload)某个类型或配件,
必须以应用域为单位启动/停止代码,获取/释放资源.
  CLR在执行一个