A Beginner's Guide to Microsoft's shared Source CLI (Rotor)

Taking things apart (radios, blenders, televisions, an Atari 2600, etc.) as a child in order to see how they were constructed and operated is probably what got me started in computer programming. As an adult my insatiable need to hack a particular technology apart is quenched by Microsoft's Shared Source CLI (Common Language Infrastructure); more commonly known as Rotor.

Brief Overview

The Common Language Infrastructure (CLI) is the ECMA standard that describes the core technologies contained in .NET. Rotor implements this standard. In addition, other projects (Mono and Portable .NET) implement the CLI standard to run on Linux. Microsoft's implementation runs on Windows XP, Mac OS X, and FreeBSD via a Portable Abstraction Layer (PAL). The PAL sits between the operating system and the CLI and maps several dozen function calls between the two.

Rotor allows people (researchers, programmers, teachers, etc.) to view, debug, and analyze .NET source code. Is Rotor's source code the same as the proprietary .NET commercial source code? No. However, both sets of code are from the same early source tree branch. One matured into the commercial version. The other evolved into Rotor. The base virtual hosting techniques of .NET still apply within Rotor: assembly loading, JIT compilation, garbage collecting, IL emitting, compilers (C#, JScript, and a sample LISP how to), security protocols, metadata usage, etc. All conform to the ECMA CLI standard. A full list of features and tools contained in the Rotor download can be found on MSDN (http://msdn.microsoft.com/net/sscli ).

Diving In

The current Rotor tarball is about 18 MB, contains over a million lines of code, and around 14,000 files. Most of the .NET framework class libraries are present except for ADO.NET, Windows Forms, Web Forms, and Web Services. Either you or the Rotor community will have to implement these. On a less painful note, remoting, networking, and XML functionality (and source) are included.

It's a good idea to have a decent computer before installing and building Rotor's code. I chose to perform a "checked" build type.

After a successful installation, it is important to run "env" correctly or you will end up using Visual Studio's C# complier instead of Rotor's. If you decided to perform the "checked" build, you simply type "env checked". The same parameter applies to "fastchecked" and "free" build types. After entering the appropriate environment your screen should look similar to the following:

Open a command prompt and navigate to Rotor's root directory (probably something like f:\sscli). Execute the appropriate "env" command plus build type parameter to establish the environment to run Rotor. Next, navigate to the directory where the HelloWorld.cs file was saved. Enter the following command to compile:

You use Rotor's "clix" program to run the HelloWorld.exe assembly.

Utilizing Visual Studio .NET 2003 is my preferred way to debug code and observe want is occurring underneath of Rotor. Others like to debug using "cordbg". I am familiar with Visual Studio, find it easier to use, and enjoy the fancy GUI. In order to debug Rotor using Visual Studio .NET type the following at the command prompt:

After Visual Studio initializes, press "F11" and save a default solution. Set breakpoints, step into, and step over the code as you would in any Visual Studio project. Moreover, create several large objects and step through the comutilnative.cpp file to watch garbage collection in action!