.NET splits the operating systems platform into two layers:

Execution layer            Programming layer

Although in its first incarnation .NET is targeted at the Wintel platform, its design allows for it to run on other platforms. For example, the Ximian Mono project is currently developing  for Linux an open-source version of a C# compiler; a runtime for the Common Language Infrastructure(CLI); a subset of the .NET classes and other independent .NET add-ons

But isn’t this in effect what Java already does ?  Only in part. Java is a language for many platforms whereas .NET offers many programming languages for a supported platform. This has great significance for Microsoft's future position in the software marketplace.

Traditionally, programs developed for one platform could only be ported to another if the subsystems were substantially re-written. Windows has previously relied on the Win32 API subsystem which cannot be easily ported (there isn’t, for example, a Linux version)

Earlier versions of VB ‘packaged’ many API calls and simplified the development of Windows applications and interfaces – in this sense VB is an abstraction layer. Similarly C++ was simplified by the use of the Microsoft Foundation Classes (MFC). VB has become the world’s most popular programming language and is now available as VB.NET. Together with C# it is available in Visual Studio.NET.

Under .NET we don’t need to know anything about the subsystems our objects rely on – we leave that to the Framework. However, Microsoft has not yet ported everything from the old Win32 model to the new .NET model, so for the time being, for example, Direct X developers continue to use the old model in developing games and multi-media applications.

There are several thousands of objects available in the class library though a typical developer may only use a handful of them. These objects are accessed in the same way irrespective of the language(s) being used.

The final issue is to remove dependence on a particular processor. Traditional Windows applications are compiled to run on an x86 chip, but .NET sets out to break this dependence. It achieves this by compiling applications into the Microsoft Intermediate Language (MSIL). The MSIL code has to be further compiled into the native code of a particular processor. This raises the interesting issue for the future of who will be responsible for developing a MSIL-native code compiler for a new processor !!

The Common Language Runtime is the final element of the .NET system .....

Loading and executing code (from MSIL to native processor)

Application Isolation (preventing badly-behaved programs from crashing the machine)

Memory management (using the ‘Garbage Collector’ for efficient use of memory)

Security (.NET code requires ‘evidence’ (policies) before it will run)

	Exception handling (providing control for ‘exceptional happenings’)
	Interoperation (allowing .NET developers to call Win32 routines when necessary)

One of the most important aspects of .NET is inter-language operation – all languages must be treated equally, and objects created in one language must be understood by others. This is achieved by the Common Type System (CTS). With CTS, all .NET languages use data types in the same way and no conversion is required.

Additionally, Microsoft has created the Common Language Specification(CLS) which facilitates the adaptation of languages to make them .NET compatible.

* A reminder of the basic features of Object Orientation:

Class = the definition of the object

Polymorphism = an object can be treated as if it were a different kind of object where common-sense prevails. A sports-car object inherits from a car object – it can do everything a car does and can be treated in the same way. This does not hold true the other way around.

Learning Resources Page