Responding to the challenge

Microsoft .Net is the company’s response to these challenges. I began by stating that Dot Net is a brand. It is, but the part of .Net which I am going to focus on is a specific piece of technology. This is the .Net Framework. It is a replacement for the Windows API, a new platform hosted on Windows but with cross-platform potential. I’m going to give you a tour of its main components, together with some comment on how Microsoft hopes it will meet the competitive pressures I have outlined.

The .Net Framework

The Common Language Runtime

The Common Language Runtime or CLR is the operating environment for .Net applications. It manages:

Memory

The common language runtime includes a garbage collector. When you New an object, the runtime allocates memory from the managed heap. When the garbage collector runs, memory is reclaimed by freeing objects no longer used by the application.

Thread Execution

The runtime handle thread management.

Code safety verification

The runtime implements fine-grained application security.

Common Type System

The common type system ensures interopability between managed code.

Platform Invoke

Platform Invoke (PInvoke) enables access to the native operating system.

Just-in-time compilation

The just-in-time compiler converts Microsoft Intermediate Language to native executable code at runtime. You can also pre-compile to native code.

The CLR runs on Windows 98, Me, NT 4.0, 2000 and XP. In beta is a version that runs on Windows CE, for devices like the Pocket PC. So cross-platform is currently an overstatement. However, Microsoft has also released a non-commercial implementation, with source code, that runs on BSD and Mac OS X. Further, the open source company Ximian is working on Mono, an implementation of the CLR on Linux. The bottom line is that the CLR is inherently portable. Whether the non-Windows versions take off, and the extent to which Microsoft either enables or obstructs it, is open to speculation, but technically it is possible.

Is it the Java Virtual Machine under another name?

This is an interesting question. We should not forget that Microsoft licensed Java from Sun and there was a period when it looked like Microsoft would be a good Java citizen. It was Sun as much as Microsoft that spoilt the party; the two companies were unable to work together. We must suppose that none of Sun’s code is in the CLR, but it seems likely that Microsoft drew on its own implementation of the Java Virtual Machine for Windows in the CLR. The CLR incidentally has another ancestor, a just-in-time compiler for Windows CE called the Common Executable Format (CEF). But undoubtedly the JVM has been a big influence on the CLR.

Still, the real question is whether the CLR is a waste of time, because the JVM is the same thing. The answer is not quite. One wag put it like this:

- The Java Virtual Machine is an object-oriented execution environment for any language so long as it’s Java

- The .NET Platform is an object-oriented execution environment for any language so long as it isn’t Java

Stephen Gilmore, Edinburgh, 2002 (http://www.dcs.ed.ac.uk/home/stg/MRG/kickoff)

From a high-level perspective that’s exactly right. Unlike the JVM, the CLR is designed to be language-neutral. Some critics argue that this is not really so, since other languages have to conform to the Common Type System and other CLR restrictions, and end up as little more than C# clones. I don’t think this is fair. There are organisations which have written compilers for specific languages for both the CLR and the JVM, such as Eiffel Software. These people say that compiling their non-Java languages to MSIL is a lot easier than compiling to Java byte code.

At a low-level there are many differences. One is that the JVM can either interpret or just-in-time compile the byte code. The CLR always compiles to native code. Another is that the CLR supports unmanaged code, known as “unsafe”, where the programmer assumes the responsibility for managing memory and can do pointer arithmetic and so forth. In Java this is not possible, except indirectly through JNI (Java Native Interface). It’s also worth noting that PInvoke, or native code invocation, is vastly easier in .Net than JNI in Java. Unlike .Net, the JNI requires the compilation of a separate, wrapper DLL to use a native library. There’s a good reason for PInvoke’s ease of use. Microsoft makes heavy use of PInvoke in the .Net Framework class library. Of course this kind of code doesn’t port easily, which is another reason why cross-platform .Net is some way off.

Next