The Common Language Specification (CLS) aids the development of mixed language programming. It defines a subset of Common Type System which all class library providers and language designers targeting CLR must adhere to.
CLS is a subset of CTS. If a component written in one language (say C#) is to be used from another language (say VB.NET), then the component writer must adhere to types and structures defined by CLS.
CIL - Common Intermediate Language
All compilers complying with CLI must generate an intermediate language representation called Common Intermediate Language (CIL). The CLI uses this intermediate language to either generate native code or use Just In Time (JIT) compilation to execute the intermediate code on the fly.
The Microsoft documents refer this standard's implementation as MSIL (Microsoft Intermediate Language).
JIT - Just in Time Compiler
The JIT or Just in Time Compiler is the part of the runtime execution environment, which is used to convert the intermediate language contained in the executable file, called assemblies, into native executable code.
The security policy settings are referred at this stage to decide if code being compiled needs to be type safe. If not an exception is thrown and JIT process is aborted.
VES - Virtual Execution System
Virtual Execution System (VES), is more or less equivalent to the JVM (Java Virtual Machine).
VES loads, links and runs the programs written for Common Language Infrastructure contained in Portable Executable (PE) files.
Virtual Execution System (VES) fulfills it's loader function by using information contained in the metadata and uses late binding (or linking) to integrate modules compiled separately, which may even be written in different languages.
VES also provides services during execution of the codes, that include automatic memory management, profiling and debugging support, security sandboxes, and interoperability with unmanaged code, such as COM components.
Managed codes are Intermediate Language (IL) code along with metadata contained in Portable Executable (PE) files, these may be .EXE or .DLL. This needs just in Time (JIT) compiler to convert it into native executable code. There is also a provision of pre compiled executable which is called unmanaged code. The advantage of unmanaged code is that is does not need to JIT compilation but has the disadvantage of unportablity across different Operating System (OS) platforms.
Microsoft's Implementation of CLI is CLRThe Microsoft's implementation and adaptation of the above standard has resulted in difference in terminology, for example Common Intermediate Language (CIL) is called Microsoft Intermediate Language (MSIL) and Common Language Infrastructure (CLI) is referred to as Common Language Runtime (CLR).
These changes in naming convention, I believe, is to create a branding distinction while implementing the standards. This was probably intended to avoid the clash that occurred with the Java the language standard, Java the island, Java the coffee brand and Java the Sun's trademark! But, in the long run, it will only lengthen the already long list of confusing acronyms and jargons in the programmer's dictionary.
We use CLI and CLR interchangeably, however, it will be more correct to say that CLR is the Microsoft's implementation of CLI.
Apart from scripted languages like JavaScript and VBScript, the .NET framework presently supports three compiled languages, namely: VB.NET, VC++ and C# (pronounced C Sharp) These language compilers target this runtime. The type verifiable compiler's output is called
managed code.
Unsafe codes can also be generated by compilers, which is called
unmanaged code. Garbage collection is only handled for managed codes.
The managed code has access to Common Language Runtime (CLR) features such as multi- language integration, exception handling across language boundaries, security and versioning and a simplified deployment .
An interesting facility being experimented by microsoft is the cross language inheritance. For example, a C# class can inherit from a VB object! Each of these features will be discussed in detail later.
The CLR provides services to the managed code. The language compilers emit metadata, that describes the types, members, and references in the code. Metadata is stored along with the code: every loadable common language runtime image contains metadata.
The metadata helps the CLR to locate and load classes, lay out instances in memory, resolve method invocations, generate native code, enforce security, and set up run time context boundaries.
The CLR, much like Java Virtual Machine (JVM) provides automatic garbage collection facilities to the managed code, this garbage collection feature is called
managed data. But unlike Java VM, the CLR also has mechanism to syntactically switch off automatic garbage collection called
unmanaged data, where the programmer is responsible for garbage collection.
The CLR has been designed to facilitate cross language integration. Two kind of integration is possible: tightly coupled and loosely coupled, which is also called
remoting. The tightly coupled inter language method call is achieved within the CLR; this assumes that the two languages calling each other are both .NET framework compliant like VC++, VB.NET or C# or are at least COM compliant. Thus C# programs can talk to Java programs through ActiveX Java Bean bridge! This is assuming that both the C# and Java codes reside on a single computer.
Remoting or loosely coupled inter language interaction is suitable when the two interacting programs written in different languages are on different operating system (OS) platforms, like C# client residing on Windows CE talking to Solaris based server side Java code. This integration is achieved through an XML based protocol called Simple Object Access Protocol (SOAP) which was proposed by Microsoft and is adopted by W3C consortium (http://www.w3c.org). An open source SOAP gateway implementation of Java is available from Apache.org at http://xml.apache.org.
SOAP has transport layer independent, XML formatted content and currently HTTP and SMTP transport implementations are available from both Microsoft and Apache.org for .NET framework and Java platforms respectively .
All .NET framework components carry information about the components and resources they use, in a XML formatted document called metadata. The runtime, uses this information to dynamically link the components, ensuring version integrity and security controls; This makes the application theoretically more resilient against version changes. Only time will tell if this innovation is successfully implemented.
Another good feature introduced in this new framework is reduction of Windows system registry dependency. Registration information and state data are no longer stored in the system registry, but inside the metadata. This should make the server side component deployment much easier.
.NET framework's Common Language Runtime (CLR) claims to have the ability to compile once and run on any CPU and operating system that supports the runtime. We will see if this becomes a real possibility in near future.
Common Intermediate Language (CIL)
The .NET framework's implementation of Common Intermediate Language (CIL) is called Microsoft Intermediate Language (MSIL). Unless specified otherwise, we will use the terms Intermediate Language (IL), MSIL and CIL interchangeably.
Managed code is produced by one of the three compilers which translate the source code into Microsoft intermediate language (MSIL).
Common Intermediate Language (CIL) and therefore it's Microsoft rendering called Microsoft intermediate language (MSIL) is said to be a CPU independent set of instructions that can be efficiently converted to native code.
MSIL intermediate instruction set has instructions for loading, storing, initializing, object method calling , many conventional instructions for arithmetic and logical operations, control flow, direct memory access, and exception handling. All the three languages included in this framework have Java like \"try catch\" exception handling facility.
Just like Java, before the managed code is executed, the intermediate language is converted to CPU specific code by a just in time (JIT) compiler. The runtime supplies one or more JIT compilers for each computer architecture it supports. However, the code can be compiled into native form during installation itself.
When a Common Language Specification (CLS) compliant compiler produces Common Intermediate Language (CIL), it also produces metadata, describing the Common Language Types (CLT) specific types used in the code, including the definition of each type, the signatures of each type's members, the members that the code references, and other data that the runtime uses at execution time.
The MSIL and metadata are contained in a portable executable (PE) file which is an extension of the Microsoft Portable Executable (PE) and Unix world's Common Object File Format (COFF) used for executable content. They appear to the user as the familiar .EXE and .DLL files.
One of the fundamental differences between Java Virtual Machine (JVM) instruction sets and Common Intermediate Language (CIL) is that JVM is big endian ( most significant byte first) and CIL uses little endian ( least significant byte first) binary representation. This difference will not be apparent to most of the programmers. Only system level programmers would have to deal with it.
The file format, can accommodate either of Common Intermediate Language or native code as well as metadata, a signature pattern enables the operating system to recognize Common Language Runtime images.
The presence of metadata in the executable file enables the components to be self descriptive. This eliminates the need for additional type libraries or Interface Definition Language (IDL) used in DCOM and CORBA. The runtime locates and extracts the metadata from the file as necessary during execution.
Managed Execution
There are two kinds of codes that can exist inside the executable files now, the old machine dependent codes, like existing ActiveX controls, are called unmanaged
As mentioned earlier, there are currently three compiled languages C#, C++ and VB provided by Microsoft, which target the Common Language Runtime (CLR). This runtime is a multi-language execution environment, and supports a common base of data types and language features. however, the language compiler determines what subset of the runtime's functionality is available, and the design pattern of the code is influenced by the features exposed by the compiler.
The coding syntax is determined by the compiler, not by the runtime. If the component is required to be completely usable by components written in other languages, it must use only language features that are included in the Common Language Specification (CLS) in the component's exported types.
Application Domains
Application domains are light weight process. It can be visualized as an extension of Java's sandbox security and Thread model.
The Common Language Runtime provides a secure, lightweight unit of processing called an application domain. Application domains also enforce security policy.
By light weight it means that multiple application domains run in a single Win32 process, yet they provide a kind of fault isolation, that is fault in one application domain does not corrupt other application domains. This aids in enhancing execution security against viruses as well as helps in debugging faulty codes.
The Common Language Runtime relies on type safety and verifiability features of Common Type System (CTS) to provide fault isolation between application domains. Since type verification can be conducted statically before execution, it is cost efficient and needs less security support from microprocessor hardware.
Each application can have multiple application domains associated with it. And each application domain has a configuration file, containing security permissions. This configuration information is used by the Common Language Runtime to provide sandbox security similar to that of Java sandbox model.
Although multiple application domains can run within a process, no direct calls are allowed between methods of objects in different application domains. Instead, a proxy mechanism is used for code space isolation.
