恰恰相反，有些反射的特性是经常会被使用到的。

反射总体上分成两大特性，一是自省，二是发射；

自省的能力极为重要，而且几乎会天天用到，很少见到过哪个.net应用中不使用attribute的，而attribute特性就是metadata通过在自省能力支撑下实现的；当然自省不单单是attribute特性的运用，只要是在运行时动态检视程序自身的特性都要由反射的自省能力来支持，比如Visual Studio的IDE（这个集成开发环境本身就是.net应用的好案例）对于.net组件的自动探测功能；同时，自省的能力也是基于虚拟机平台的语言，比如c#和java，区别于传统语言比如c和c++的重要特性之一，这提供了程序设计开发更为便利和安全的运行时环境；相对而言，在c++（当然是native而不是managed）的环境下，除了RTTI极为单薄的运行时自省，也就是QT这个库通过meta-object system部分模拟了自省的特性；

反射的另外一个重要特性就是发射，它让“程序可以写程序”了，简要的说就是在运行时动态生成MSIL并加载运行以及持久化动态生成的MSIL的能力；由这个特性的支持，让原先一些程序设计和开发领域相对困难和繁琐的工作，比如元编程meta programming，比如动态代理dynamic proxy，比如AOP中的基础设施weaver的实现，变得可能或相对易于实现；反射的特性，也是基于虚拟机平台CLR的支持，以metadata为基础来实现的，所以这也是虚拟机平台语言的特有优势，而在传统语言平台上，这是难以实现的；比如关于meta programming，c++就是通过模板特性实现的编译期meta programming，这与虚拟机平台上实现的运行时meta programming还是有比较大的差距（比如前者如何保证生成的代码的type-safe）；

以上这两个特性，自省和发射，都有个共同点，他们都是围绕着metadata机制，并在虚拟机平台运行时环境CLR支持下实现的，前者是运行时检视相关的metadata，后者是运行时动态生成相关的metadata和MSIL；从这点也就可以看出，要想深入理解这些特性，就需要研究metadata和MSIL的实现，以及虚拟机运行时环境的实现（在java平台上，就是bytecode和JVM）；

所以，反射，可能是虚拟机平台所提供的相对最为强劲，最为复杂，和平台运行时本身关系最密切，也是区别于传统语言和运行时最鲜明的特性。

In the fusion, or any other components or modules, how to retrieve the execution engine instance and how to generate such engine?

UtilExecutionEngine, implemented as COM object, support Queryinterface/AddRef/Release, and exposed via interface IExecutionEngine.

With SELF_NO_HOST defined,
BYTE g_ExecutionEngineInstance[sizeof(UtilExecutionEngine)];
g_ExecutionEngineInstance would be the singleton instance of current execution engine,

otherwise, without SELF_NO_HOST, the 'sscoree' dll would be loaded and try to get the exported function, which is named 'IEE' from such dll. Here, it is the well-known shim, in .net CLR, such module is named 'mscoree'. Further, if 'IEE' could not be found in such dll, system would try to locate another exported function, named 'LoadLibraryShim', and use such function to load the 'mscorwks' module, and try to locate the 'IEE' exportd functionin it.

It's very obvious that Rotor has implemented its own execution engine, but it also gives or make space for implementation of execution engine from 3rd party. Here, .net CLR is a good candidate definitely, Rotor might load the mscorwks.dll module for its usage.

PAL, PALAPI, for example, HeapAlloc, one famous WIN32 API, has been implemented as one PALAPI (defined in Heap.c), to make it possible that the CLI/Rotor be ported smoothly to other OS, such freebsd/mac os.

CRT routines are also reimplemented, such as memcpy, it has been implemented as GCSafeMemCpy

There're many macros in fuctions, such as SCAN_IGNORE_FAULT/STATIC_CONTRACT_NOTHROW/STATIC_CONTRACT_NOTRIGGER, they are for static analysis tool to scan, analyse and figour out the potential issues in code.

From view point of the execution model by CLI, the act of compiling (including JIT) high-level type descriptions would be separated from the act of turning these type descriptions into processor-specific code and memory structures.

And such executino model, in other word, the well-known 'managed execution', would defer the loading, verification and compilation of components until runtime really needs; At the same time, the type-loading is the key trigger that causes CLI's tool chain to be engaged at runtime. Deferred compilation(lead to JIT)/linking/loading would get better portability to different target platform and be ready for version change; The whole deferred process would driven by well-defined metadata and policy, and it would be very robust for building a virtual execution environment;

At the top of such CLI tool chain, fusion is reponsible for not only finding and binding related assemblies, which are via assembly reference defined in assembly, fusion also takes another important role, loader, and its part of functionality is implemented in PEAssembly, ClassLoader classes. For example, ClassLoader::LoadTypeHandleForTypeKey.

For types in virtual execution environment of CLI, rotor defines four kinds of elements for internal conducting,
ELEMENT_TYPE_CLASS for ordinary classes and generic instantiations(including value types);
ELEMENT_TYPE_ARRAY AND ELEMENT_TYPE_SZARRAY for array types
ELEMENT_TYPE_PRT and ELEMENT_TYPE_BYREF for pointer types
ELEMENT_TYPE_FNPTR for function pointer types

every type would be assigned unique ulong-typed token, and such token would be used to look up in m_TypeDefToMethodTableMap (Linear mapping from TypeDef token to MethodTable *)which is maintained by current module; If there it is, the pointer to method table of such type would be retrieved, or it would look up in the loader module, where the method table should exist in while it's JIT loaded, not launched from NGEN image;

And all the unresolved typed would be maintained in a hash table, PendingTypeLoadTable; Types and only those types that are needed, such as dependencies, including parent types, are loaded in runtime, such type is fully loaded and ready for further execution, and other unresolved types would be kept in the previous hash table.