About the Author

Aisha Ikram is a senior software engineer and has been working mainly in VC++ 6, MFC, ATL, COM. She now a days working on .NET framework and C#. She is also a member of various developer's website like code project, code guru, mind cracker and C# corner. You can write the author at ais_ikr@yahoo.com for your feedback concerns and problems.

Introduction

This article describes an overview of the .NET Framework and it's contituients Common Language Runtime and Framework class library. The article contains following sections:

• .NET Framework Constituents
• Common Language Runtime - CLR
  • Managed Code
    • Parts of amanaged module
    • Metadata
    • Metadata and type libraries and IDLs
    • Uses of metadata
    • Managed modules to Assembly
  • Loading the Common Language Runtime
  • Just-in-time Compiler and Code Execution
  • Code Verification for Safety
• .NET Compact Framework

Different programming languages offer different capabilities like C/C++ gives you control over low-level system, memory block management, thread creation etc. VB allows u to build UI applications easily and make sit easy to control COM objects and databases easily.

The .NET Framework development platform allows the developer to build following kind of applications:

1. XML web services
2. Web Forms
3. Win32 GUI applications
4. Win32 CUI (console UI) applications
5. Services (controlled by Service Control Manager)
6. Utilities
7. Stand-alone components

.NET Framework Constituents

The .NET framework consists of two parts:

1. Common Language Runtime (CLR)
2. Framework Class Library (FCL)

which provide:

1. Consistent programming model
2. Simplified programming model
3. Multiple versioning support
4. Simplified deployment
5. Wide platform reach
6. Programming language integration
7. Simplified code reuse
8. Automatic memory and garbage collection
9. Type-safe varification
10. Rich debugging
11. Consistent failure reporting
12. Security
13. Interoperatability

Note: Initially Microsoft will make the CLR and FCL available in the various versions of windows including Windows 98 and second edition, Windows Me, Windows NT 4,  Windows 2000, and both 32 bit and 64 bit version of Windows XP and Windows .NET server family.

Common Language Runtime - CLR

The Common Language Runtime Language (CLR) is what the name depicts,  a runtime usable by different programming languages and it's features are available to all programming languages that targets it. 

It's the .NET runtime that is usable by different and varied programming languages. The feature of CLR are available to any and all programming languages that target (support) it. And if the runtime uses exceptions to report errors, all the PLs (Programming Languages) which target CLR has to support exceptions and if the runtime allows you to create threads, then PLs should also let you create threads.

CLR never knows in what PL you have written your code. it means you can write your code in any PL of your choice but of course which supports CLR. Micorsoft has changed many of its compilers to target CLR, for example, C++ with managed extentions , C#, Visual Basic, JScript, J# (A Java laguage compiler) and an intermediate language assembler (IL). Other companies are also producing their code to target this new runtime, like APL, COBOL, PASCAL, Perl, Smalltalk and Fortan etc.

Compilers in the past produced code to target specific CPU architecture like x86, Alpha and PowerPC. CLR-compliant compilers produce IL code instead which can run on any machine but of course it must have CLR installed.

For further details of nuts and bolts of CLR and looking into the practical aspects of of Common Language Runtime, how it manages the resources with a sample "hello world" program, refer to my article "Common Language Runtime (CLR)"

Managed Code

The compilers of programming languages analyze and check the syntax of the code and result into an output "managed code". A managed module is a standard windows portable executable PE file that requires the CLR to execute.

Parts of a Managed Module

PE Header	The PE file header indicates the type of the file, GUI, CUI, or DLL and also contains the time stamp indicating when the file was build.
CLR Header	Contains information which is interpreted by CLR, which makes it a manged module. The header contains the version of CLR, flags and metadata entry point method Main, size of metadata, resources etc.
Metadata	This part consists of metadata tables that describe the types and members defined and referenced in the module.
Intermediate language (IL) code	Code that compiler produces after compiling source code. This IL is compiled later into the native CPU code by CLR.

Metadata

Metadata is a set of two types of tables:

1. Tables describing the types and members defined in source code.
2. Tables describing the types and members referenced or imported by the code.

Metadata, Type Libraries and IDLs

• Metadata is a superset of technologies such as type libraries (tlb) and interface definitions language (IDL) files but metatdata is far more complete.
• Unlike Type libraries and IDLs, metadata is always associated in fact embedded in the same EXE/DLL as the code, so that two can't not be separated. Type libs and idl files are created separately when the compiler compiles the source code and creates an output exe/dll, but metadata is binded with the IL code into a managed module.

Uses of Metadata

1. Imported and Referenced Types are packaged
   • Managed modules that are imported or referenced in your source code removes the need of header and library file as all the information of the referenced types/members is contained in the metadata plus the IL which contains their code. Compiler directly reads the metadata from the managed modules.
2. Intellisense feature
   • Visual studio .NET uses metadata to help you writing code because of its Intellisense feature which parses the metadata to tell you about the methods and their parameters.
3. Code verification process
   • CLR uses metadata for the code verification process in which it checks for the "safe" operations.
4. Serialization
   • Metadat allows to serialize the object's state in memory blocks which can be passed to remote machines where they are deserilized and object is re-created.
5. Garbage collection
   • Metadata also helps garbage collecter to check the type of the objects and the referenced objects and then track the lifetime of objects.

Managed modules to Assembly

Assembly file is the output file that your compiler/linker generates. The CLR works with assemblies. Each assembly that you build is either an EXE or a DLL containing the resuable components to be used by other executables. An assembly is a grouping of one or more managed modules and resource files.

An assembly is the smallest unit of reuse, security and versioning. Depending upon the choice you make with your tool or compiler the output is a single-file or multifile assembly.

Following figure will help you understand what aseemblies are about. Manifest is another set of tables that describe the files in the assembly, publicily exported types implemented by the files in the assembly and the resources or data files that are associated with asssembly.

An assembly's modules include information about version and referenced assemblies, which makes an assemly self-describing. So CLR knows all about this self-contained this assembly to execute it. No registry or active directory is required. Assemblies are easier to deploy than the unmanaged code (code that was produced without the support of .NET platform).

Loading the Common Language Runtime

CLR is responsible for executing the code contained within assemblies so the .NET framework must be installed on the host machine. For this reason microsoft has shipped its redistribution package plus a .NET compact framework is introduced which is a light version of .NET framework.

Tip: You can check for the MSCorEE.dll file in the %windir%\system32 directory to tell if the .NET framework is installed or not. As several versions of the framework can be installed on a single machine. (you can read versioning section in "Common Language Runtime (CLR)?") The registry subkeys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy can tell you about the versions of .NET installed.

Step 1: When the managed EXE/DLL file is invoked (CreateProcess/LoadLibrary), Windows loads the file and reads it's import section (.idata) to see that MSCorEE.dll (Microsoft Component Object Runtime Execution Engine) should be loaded.

Step 2:  When you build an exe/dll assembly, a 6-byte x86 stub function is written in .text section of PE file which causes the CLR to load and initialize. In case of an Exe assembly this stub function is _CorExeMain, while for DLL assembly, it's CorDllMain. _CorExeMain and _CoreDllMain are the functions exported by the MSCorEE.dll.

JMP _CorExeMain  (or JMP _CorDllMain)

Step 3: The loader gets the funtion address from the MSCorEE.dll and starts executing this function, that is, it jumps into the _CorExeMain/CorDllMain method which loads and initializes the CLR (if not already loaded or initialized)

Step 4:  After the CLR initialization, _CorExeMain reads CLR header of assembly and searches for the entry point funtion of your application (typically Main).

Step 5: The IL code for the entry point method is compiled into the native CPU instructions and the CLR starts executing this code. At this point, you can say your application is running.

Note: 6-byte x86 functions are specifically for x86 machines running Windows 98, Me, NT 4 or Windows 2000 as these OS were shipped before CLR. Windows XP and .NET server family support both x86 and IA64 CPU architectures. so x86 stub functions are required to run the managed assemblies on all these systems.

Important: When a managed assembly is invoked, OS loader checks for the directory entry 14 in the PE file header, which is IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR (defined in WinNT.h). If this entry exists it indicates that file contains managed code. (see step 10 of Step by Step Demo of CLR Thing in Common Language Runtime If found, loader does not read idata section and directly loads MSCorEE.dll. If OS is XP or .NET Server Family, it ignores the x86 stub function and directly jump into the _CorXXXMain function.

In order to have a look at IL code of your assembly, Microsoft has provided you with tools like ILAsm.exe and ILDasm.exe. For details and demo of these and other command line tools, see Step by Step Demo of CLR Thing in Common Language Runtime

Just-in-time Compiler and Code Execution

CPUs can not execute IL instructions directly, so IL must be converted into native CPU instructions. CLR's JIT (Just-in-time) compiler has undertaken this job of conversion. Lets see how this conversion is taken place.

1. Consider we have invoked a managed exe containing a Main method like this:

   static void Main()
   

   {
     Console.WriteLine("First time call to WriteLine");
     Console.WriteLine("Second time call to WriteLine");
   }

    

2. Data Structure: Before entering into this Main, CLR collects all the types referenced by Main, and allocates an internal data structure. This data structure is a table containing an entry for each method of that type with the address of that method. In our example, Console is the only type referenced by Main.
3. Initializing Address Field: First time, while initializating this structure, the address field for all the methods is set to a default function in CLR.
4. Just-in-Time Compilation :When the Main calls it's first WriteLine, this deafult function is called, which compiles the IL code into CPU native code. This code is compiled "just-in-time" by this default function, hence this function is refered to as JITCompiler or JITer.
5. Native Code Memory Blocks: JITer reads the metadata and gets the IL code of the called function (WriteLine) and converts it into native code. This native code is stored in dynamically allocated memory blocks.
6. Overwriting Address Field: JITer picks the address of this memory block and go back to the type's datastructure (table with method entries) and overwrites the address field of called function (WriteLine).
7. Code Execution: JITer go to the code in that memory block, executes it and return back to Main.
8. Second Cycle :Main now calls WriteLine the second time. This time code for WriteLine is already been compiled so the call directly goes into the memory block and the whole cycle is skipped this time.
9. Cleaning Memory Blocks: The native code placed in dyamically allocated memory is discarded after the application termination.
10. Optimization :JIter also optimizes the code, for demo of how it does it, see Step by Step Demo of Loading CLR using .NET tools in  Common Language Runtime.

Note: If you think JIT compiler is not providing your application with the required performance, you can use NGen.exe tool. This tool compiles your assembly code in native code and saves it into a file. When assembly is loaded to execute, CLR automatically determines if a precompiled code exists, and then this is executed directly.

Code Verification for Safety

IL doesn't cater for managing register and is a stack-based, i.e; pushes all the operands into the stacks.  IL does not even checks operand types, like add operation for 32 bit and 64 bit operands but IL does not distinguish between the both, it just adds. But when these instructions are actually executed, seperate add operations are performed.

So IL abstracts the whole process and makes it simple. In order to check the code for safety, when IL is compiled into native code, a process of Verification is performed which examines this IL code and checks whatever it does is "safe". The most important saftey check is that it checks that code does not read some memory which is not previously written or in other words valid memory block access is ensured. Also it can checks for the correct types of method parameters.

Application Domain

Continued ......
Will soon be updated

.NET Compact Framework

.NET Compact Framework is a light version of .NET framework for:

• PDAs like Windows CE and Palm and appliances like small devices.
• ECMA ( European Computer Manufacturers Association) acccepted the C# language, portions of CLR, and potions of FCL as standard.