3.9 Introducing the CLR

---

Simply put, the CLR is a high-performance program execution engine. Any code that is designed or targeted to run within the CLR is called 'managed code' and as such benefits from a number of built-in services that make the developer's life a bit easier. During the development phase, the CLR automates a number of tasks and prevents the developer from worrying about such things as cross-language exception handling, dynamic binding, and reflection (Reflection is the process by which a program can read its own metadata). During the execution phase the CLR manages, among others, application memory, garbage collection, security enforcement, and thread management.

Microsoft provides a core set of languages that target the CLR, and developers can decide to use one of these or a third-party language/compiler such as COBOL or Eiffel. In fact, the designers of the CLR decided to target up to 20 languages outside of the Microsoft fold, making the CLR a pretty versatile multilanguage engine.

By using a specific language compiler, you are agreeing to use the prescribed syntax that comes with that language. In addition, your chosen compiler determines which runtime features are available. To allow component reuse across languages and compilers, any exported types must adhere to language features included in the CLS.

During compilation, the source code is translated into a CPU- independent set of instructions called the Microsoft Intermediate Language, or MSIL. This in turn can easily be converted into native code. Typically the MSIL will contain a range of instructions to load, store, and initialize objects and undertake logical or mathematical operations. Prior to execution, the MSIL needs to be converted to CPU-specific code, and this is done by the Just-In-Time, or JIT compiler in the CLR. Different JIT compilers are available for different CPU architectures, allowing the same MSIL to be deployed on any supported chip set.

Associated with any MSIL is a set of metadata, that describes a set of types used during execution time. These metadata allow the code to be selfdescribing, so type libraries and Interface Description Languages, or IDLs, are no longer necessary. The CLR will read through the metadata when needed during execution.

The MSIL and metadata package are contained in a portable execution, or PE, file, which is based on the Microsoft Common Object File Format COFF, standard.

As you would expect, the JIT compiler does more than simply compile all of the code in the PE file to native code in one go. In a typical application not all of the code gets called in every execution. A good example is Word for Windows-as I write this book I probably only use about 10 percent of the available functionality, so I won't need to embed too many Excel documents into this book!

The JIT compiler actually converts the MSIL as it needs to during execution, storing the native code separately so that it is available for subsequent use. When a type is loaded, the loader creates and attaches a stub to each of its methods. When the method is first called, the stub will pass control to the

JIT compiler, which, in turn, converts the MSIL into native code and changes the stub to direct execution from the location of the native code. Any further calls to this compiled method are directed to the native code.

What happens if you do want the whole application compiled? In this case there is another compilation mode called install-time code generation. This converts the MSIL the same as the JIT compiler, but converts much larger chunks at a time. In fact, the entire assembly would be converted to native code resulting in much faster load and start times during execution (see Figure 3.7).

Figure 3.7: Visual Studio and the CLR.

As you would expect, security is an important consideration for any application. Any code, during the MSIL to native-mode compilation, must pass through a verification process. The only exception to this would be if an administrator has built a security policy that allows code to bypass this verifi- cation process.

During verification, the MSIL and metadata is examined to see if they are type safe, ensuring that the code can only access memory areas it is permitted to. This also prevents objects from trampling each other or corrupting other memory areas, either deliberately through malicious intent or accidentally. Any security policies imposed by the administrator are also verified to ensure they are enforceable.

To pass as type safe, the following must be true:

• All identities are correct and what they claim to be.

• Any reference to a type is fully compatible with the type being referenced.

• Any operations invoked on an object are predefined and appropriate for that object.

Some languages, by design, do not produce code that is verifiably type safe. If a security policy is set up demanding type-safe code and the language does not pass verification, an error will be raised during execution.

---