The compiler is a program that takes in the C/C++ file(s) as an input and outputs an executable file, that can then be directly run on the host computer.

The Common Language Runtime (CLR) and Java Runtime Environment (JRE) 

Computer hardware is like any other machinery. You can switch it on, and electrons will start flowing through it. That's all that a computer can do. Like an ignorant being - computer needs to be told specifically what it should do. Computer programs are the tool to tell the computer what you want it to do.
Computers understand only one language - the machine code. Machine code is a sequence of binary (1 and 0) digits. A microprocessor manufacturer (the microprocessor is the heart of a computer) decides which sequence of bits means what.

Remember that Machine language is the only language that the Microprocessor (hence the Computer) understands. So ALL the applications/software will ultimately have to be translated into Machine language before they can run on a Computer.

Although our microprocessor is a simple one, and today's commercial microprocessors are all built on the same principle. Every microprocessor has its own op codes (like the move op code of our simple microprocessor) and its own addressing schemes. Apple Computer's are built around Motorola's microprocessors, while IBM and IBM compatible computers are all built around Intel processors.

What are compilers?

Every microprocessor has its own machine code. Our extremely simple microprocessor had its own machine code, Intel would have its own code and so would Motorola.

For human being it is almost impossible to remember the machine code and to develop even a small application using machine codes. That's where the higher level languages come in.

In C/C++, to add two numbers you would write the following code:

int i;
int j;
int k;
k = i + j;

 The garbage collector is similar to the garbage collector found in Java. Its function is to reclaim the memory when the object is no longer in use, this avoids memory leaks and dangling pointers.

What is the CLR?

What is Microsoft's Common Language Runtime (CLR)? It is the life line of .NET applications. Before I describe the CLR - let's explain what is meant by runtime. A runtime is an environment in which programs are executed. The CLR is therefore an environment in which we can run our .NET applications that have been compiled to IL. Java programmers are familiar with the JRE (Java Runtime Environment). Consider the CLR as an equivalent to the JRE.

The above diagram shows various components of the CLR. Let's discuss each in details. [12] has an in-depth analysis.

The Common Type System (CTS) is responsible for interpreting the data types into the common format - e.g. how many bytes is an integer.

The second component, the IL Compiler takes in the IL code and converts it to the host machine language. The execution support is similar to the language runtime (e.g. in VB the runtime was VBRunxxx.dll; however with VB.NET we do not need individual language runtimes anymore).

Security component in the CLR ensures that the assembly (the program being executed) has permissions to execute certain functions. The garbage collector is similar to the garbage collector found in Java. Its function is to reclaim the memory when the object is no longer in use, this avoids memory leaks and dangling pointers. The class loader component is similar to the class loader found in Java. Its sole purpose is to load the classes needed by the executing application.

Here's the complete picture.

The programmer must first write the source code and then compile it. Windows programmers have always compiled their programs directly into machine code - but with .NET things have changed. The language compiler would compile the program into an intermediate language "MSIL" or simply "IL" (much like Java Byte code). The IL is fed to the CLR then CLR would use the IL compiler to convert the IL to the host machine code.

.NET introduces the concept of "managed code" and "unmanaged code". The CLR assumes the responsibility of allocating and de-allocating the memory. Any code that tries to bypass the CLR and attempts to handle these functions itself is considered "unsafe"; and the compiler would not compile the code. If the user insists on bypassing the CLR memory management functionality then he must specifically write such code in using the "unsafe" and "fixed" key words (see C# programmers guide for details). Such a code is called "unmanaged" code, as opposed to "managed code" that relies on CLR to do the memory allocation and de-allocation.

The IL code thus produced has two major issues with it. First it does not take advantage of platform specific aspects that could enhance the program execution. (for example if a platform has some complicated graphics rendering algorithm implemented in hardware then a game would run much faster if it exploit this feature; however, since IL cannot be platform specific it can not take advantage of such opportunities). Second issue is that IL can not be run directly on a machine since it is an intermediate code and not machine code. To address these issues the CLR uses an IL compiler. The CLR uses JIT compilers to compile the IL code into native code. In Java the byte code is interpreted by a Virtual Machine (JVM). This interpretation caused Java applications to run extremely slow. The introduction of JIT in JVM improved the execution speed. In the CLR Microsoft has eliminated the virtual machine step. The IL code is compiled to native machine and is not interpreted at all. For such a compilation the CLR uses the following two JIT compilers:

1. Econo-JIT : This compiler has a very fast compilation time; but it produces un-optimized code - thus the program may start quickly but would run slow. This compiler is suitable for running scripts.
2. Standard-JIT: This compiler has a slow compilation time; but it produces highly optimized code. Most of the times the CLR would use this compiler to run your IL code.
3. Install Time Compilation: This technique allows CLR to compile your application into native code at the time of installation. So the installation may take a few minutes more - but the code would run at speeds close to a native C/C++ application.

Once your program has been compiled into host machine code, it can begin execution. During execution the CLR provides security and memory management services to your code (unless you have specifically used unmanaged code).

go to top

Conclusion

It is clear from the above discussion; that Microsoft has done what it does best. It has observed the JRE/JVM for four years; and then has come up with a more efficient and stable runtime environment that builds on top of the strengths of JRE/JVM and removes its shortcomings.

So what should you expect when you start using the CLR?. You should most definitely expect your programs to run faster than an equivalent Java program [11]; but your program would still run slower than an equivalent C/C++ program - or any other program that is compiled into machine language. That's a limitation that ALL interpreted languages have, and that's the price you pay for platform independence.

JVM is available for most of the platforms (hence your Java program is really platform independent); while CLR (at the time of writing of this article) is only available for Microsoft Windows platforms (hence a .NET program is not really platform independent, it only promises to be platform independent). Microsoft has not unveiled any future program to develop CLR for other platforms; though it is inevitable that third parties would come up with CLRs for non-Microsoft platforms.

Editor's Note: Since this article was written Microsoft has announced the Rotor project which provides a shared-source implementation of the CLR. There are also a few other projects around; one is the Mono project which is trying to bring the CLR to the Linux platform.

In the long run, both JVMs and CLRs would run in lock steps. Each would learn from the other, and the end result would be a healthy competition and a much better run time environment for the end-user.

NET CLR Injection: Modify IL Code during Run-timehttp://www.codeproject.com/Articles/463508/NET-CLR-Injection-Modify-IL-Code-during-Run-time

 

 .Net Framework Infrastructure

CTS (Common Type System)

CTS Data Type	VB .NET Keyword	C# Keyword	C++/CLI Keyword
System.Byte	Byte	byte	unsigned char
System.SByte	SByte	sbyte	unsigned char
System.Int16	Short	short	short
System.Int32	Integer	int	int or long
System.Int64	Long	long	__int64
System.UInt16	UShort	ushort	unsigned short
System.UInt32	UInteger	uint	unsigned int or unsigned long
System.UInt64	ULong	ulong	unsigned __int64
System.Single	Single	float	float
System.Double	Double	double	double
System.Object	Object	object	object^
System.Char	Char	char	wchar_t
System.String	String	string	String^
System.Decimal	Decimal	decimal	Decimal
System.Boolean	Boolean	bool	bool

 

BCL (Base Class Library) and FCL 

BCL is a core set of CLI class libraries that programs may utilize and it is available for all CLI languages. This library collection provides fundamental types and APIs which allows the programs to interact with the system runtime and OS functions in a common approach. There is a Microsoft-specific library which is calling the Framework Class Library (FCL) that adds some features to BCL. It includes support for rich Client UI, web UI, database access,distributed communication, and other libraries. The following table shows a list of standardize and non-standardized namespaces are as following:

Standardized namespaces:

• System 
• System.Collections
• System.Diagnostics
• System.Globalization
• System.IO
• System.Net
• System.Reflection
• System.Runtime
• System.Security
• System.Text
• System.Threading
• System.Xml
• System.Diagnostics.CodeAnalysis
• System.Diagnostics.Contracts
• System.Diagnostics.Eventing
• System.Diagnostics.PerformanceData
• System.Diagnostics.SymbolStore 

  Non-standardized namespaces: 

• System.CodeDom
• System.ComponentModel
• System.Configuration
• System.Data
• System.Deployment
• System.DirectoryServices
• System.Drawing
• System.EnterpriseServices
• System.Linq
• System.Linq.Expressions
• System.Management
• System.Media
• System.Messaging
• System.Resources
• System.ServiceProcess
• System.Timers
• System.Transactions
• System.Web
• System.Windows.Forms