Search This Blog

Friday, January 2, 2009

Introduction to Common Language Runtime for BEGINNERS

Introduction to Common Language Runtime for BEGINNERS 
(Also includes differences between managed and unmanaged code)
CLR or Common Language Runtime is a very important part of whole .net Framework and its utter importance is not seen by many as it works behind the scenes.


  • In earlier days of programming there was no concept of managed code,there was only unmanaged code which means that all the things should be handled by the operating system.
  • The programming languages compiled the programs written in them to the native code specific to the architecture or the CPU.
  • There are many disadvantages of such an approach which we will see shortly.
  • So first of all what is CLR....Actually speaking it can be considered as a small processing unit of its own which when given a Intermediate Language code can produce a native code to be run on that CPU.
  • CLR consists of various parts in which each is a topic of research and discussion and requires an in depth analysis.
  • So the process in which our programs get executed is first of all we have a code in a language it can be VB,C# or C++ now we compile this code using the respective compiler for that language.
  • After this first compilation we receive a IL or Intermediate Language code, now this IL code act as input to the CLR and its Just In Time Compiler chooses the right Model to be executed for compilation for that CPU type.
  • So now the JIT decides according to the CPU type and architecture which mode of compilation it should follow.
  • Now after this decision JIT actually compiles and produces the native code which can be run on that CPU.
  • CLR can be considered as a SandBox environment from which no code can execute outside its given bounds that is the code execution is confined and this is a major advance over the earlier model of program execution.
  • So now you can say that .net can only execute the managed code and there is no need for unmanaged code but this is not true. There are some special cases where  unmanaged code is the best thing till today e.g are device drivers and real time applications where performance is a bottleneck although there are algorithms which will be implemented in future CLR for support of Real Time applications.
  • But .net framework also provides few ways to write unmanaged code which will not use facilities of CLR and execute in an old fashioned way.
  • Both C++ and C# has ways to execute this unmanaged code.
  • When the code is first compiled to an IL we get a .exe or .dll file this is what we call an assembly.
  • Once you ask this assembly to be executed it is loaded into the ApplicationDomain or AppDomain of the CLR.
  • AppDomain of CLR is the region in which a process is running and each assembly can get executed without creating a new process side by side with other assemblies without hampering or affecting their execution.
  • Creating separate processes for execution was a performance intensive task which earlier programming languages used to do.But with CLR this performance lapse is reduced.
  • The other benefit is that this code is compiled only once by the JIT and after that it can be run utilizing full power of the CPU.
  • So the million dollar question is when ultimately the native code is getting generated which is also being generated by other language compilers what's the difference between this native code and the one generated by CLR.
  • So the difference is that CLR places some information within this native code which tells this native code to follow the execution model and remain in bounds confined by the CLR.
  • Earlier unmanaged applications never thought of maximizing the overall throughput,they always used to maximize individual applications throughput but managed code always tries to maximize the overall throughput rather then considering a single process.

No comments: