CLR探索系列:深入追踪托管exe加载执行过程

在上一篇“CLR探索系列之应用程序域世界”的上篇中，探讨了一些关于应用程序域在托管代码执行过程中的特性和运行机制，以及一些相关的概念。

在接下来的中篇里，就从如何实现的角度，换一个角度来探讨程序集和应用程序域是如何加载，执行。以及一些有趣的问题。

首先，有一个有趣的“鸡和蛋”的问题。我们知道，一个应用程序集里面的代码在执行的时候，首先被load，然后经过验证，接着对IL代码JIT成为本地代码才能执行。一个应用程序集只有被先加载了才能被执行，但是加载程序集的程序集，是被什么程序集加载的呢？或者，第一个程序集，是如何被加载到CLR的世界中呢？   

首先，来查看一下Clix工具作为一个sscli提供的loader的main函数都做了些什么：
int __cdecl main(int argc, char **argv)

{

    DWORD nExitCode = 1; // error

    WCHAR* pwzCmdLine;

 

    if ( !PAL_RegisterLibrary(L"rotor_palrt")

            || !PAL_RegisterLibrary(L"sscoree") ) {

        DisplayMessageFromSystem(::GetLastError());

        return 1;

}

可以看到，在clix的Main函数里面，就做了两件事情：注册Rotor的palrt模块，同时，注册sscoree模块。
在执行托管代码的库文件结构中，有三个层次：
第一层：Managed libraries
第二层：Execute Engine(CLR)
第三层：PAL
第一层里面，主要包含的是BCL；还有一些别的托管系统的库文件。例如mscorlib.dll，System.xml.dll或者是别的托管组件之类。
第二层里面，有我们非常熟悉的sscoree.dll，也就是rotor里面的托管程序的执行引擎。
在第三层PAL层里面，主要有两个文件：rotor_pal.dll，rotor_palrt.dll；在rotor的源代码解压后，clr，pal，palrt这三个文件夹是并列排列的。这也反应了这三个部分之间的关系。pal是某个特定的操作系统对PAL层的实现，而palrt是忽略操作系统的区别对PAL层的一般实现。

在 if ( !PAL_RegisterLibrary(L"rotor_palrt")|| !PAL_RegisterLibrary(L"sscoree") )这一行中，首先是加载了托管库文件结构里面最下面PAL层的针对编译好了的，一个特定的操作系统的实现。接着，又是调用加载了基于这个PAL_RT层上面的CLI的托管执行引擎：sscoree。而对于托管代码执行需要的库文件的第三层，也就是最上面一层，BCL之类的库文件的加载，则是在创建这个托管引用程序的内存结构的几个特定类型的应用程序域中加载进去的。

这样，对于托管代码执行的时候的需要的一些库文件(按照库文件的结构，从下往上)是如何加载到内存中去，以及PAL层和CLR的加载执行顺序，我们就有了一个比较清晰的认识了。

      then，在注册好了PAL层和CLR之后，我们再来看看作为sscli里面提供的一个loader，是如何实现load一个exe(或许是托管的)到执行的托管进程中去的。打开Clix.app的Launch函数：

//the Launch founction of Clix.Shows how launch of first Assembly.

//launch the EE of CLI

DWORD Launch(WCHAR* pFileName, WCHAR* pCmdLine)

{

       //file name

    WCHAR exeFileName[MAX_PATH + 1];

    DWORD dwAttrs;