A quick look at the CLR and managed code.

The Core Execution Engine, generally referred to as CLR (Common Language Runtime) is at the heart of the .NET framework and helps handling all execution of managed code we write. Just In Time (JIT) compilation and Garbage Collection are are some the really core runtime services that the CLR provides.

The .NET Framework is a managed execution platform. It contains the Execution Engie (EE), also called VM (Virtual Machine), which is in charge of code execution and runtime services. It also contains class libraries like collection (stacks, queues, lists, …) which contain code we don’t have to write ourselves.

The NET framework is also an implementation of the Common Language Infrastructure (CLI). The CLI contains the Common Type System (CTS) which defines everything you can do as a programmer on the .NET framework. The CTS itself contains the Common Language Specification (CLS) which defines a minimum mandatory set of types. It defines the set of features that will always exist no matter which implementation of the CTS you use.

From code to machine code

From code to machine code

The .NET Framework is a retail platform of the CLI which targets Windows. A sub-implementation of has the codename Rotor. It can be used in academic environments and by programers trying to understand the inner work of the CLI. Another version of the CLI is the Microsoft .NET Compact Framework which targets PDAs and smartphones. We also have a version targeting Silverlight and dynamic environment like Python and Ruby, which is called the Core CLR, or Dynamic Language Runtime (DLR).

Another non-Microsoft implementation of the CLI is called Mono and targets Linux, Solaris, Mac OS/X. It was started by Ximian then continued by Novell. Today, its development is handled by Xamarin.

Programming languages don’t have to limit themselves to what the CLS makes possible. For example, C++ support multiple inheritance which allows a specific class to inherit from more than one (1) class. This feature is something which doesn’t exist in the CLS specification itself.

The CLR is implemented as a set of in-process DLLS that are loaded into processes that run managed code. This means that different applications can run different versions of the CLR in their own process execution. They can all co-exist on a machine without interferring one with each other. Things like the heap or the thread pool exist in the context of each application execution. This prevents cross-process inteferecence.

When people say Managed execution, they refer to specific types that are described using a managed language like C#. The source code is available as classes, structs, enums, interfaces and delegates. They go through the compiler and get out as Intermediate Language (IL) code. The compiler emits an assembly as a DLL or an EXE.

In the context of a process address space, here’s roughly what happens when you double-click and EXE file in Windows:
1- Windows will start by setting up a new process space and a thread of execution.
2- The EXE contains metadata that will identify if it’s running on a server or a desktop version of Windows.
3- The CLR will load the assembly.
4- The entry point method (main) is accessed.

Each .NET program consists of a set of classes/types. It uses a static entrypoint which is required to make it work. This point is called ‘Main’ by default. C# as a language doesn’t have support for global functions. That means methods can’t exist on their own. They have to be part of an enclosing type.





/* Style Definitions */
{mso-style-name:”Table Normal”;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-bidi-font-family:”Times New Roman”;

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s