Dispelling the Myth of the .NET Virtual Machine

I l @ ve RuBoard

One of the most important facts about the .NET framework (and probably the most misquoted) is that it does not employ virtual machine technology like Java. The software running on .NET is wholly compiled and runs at the machine level just like the compiled code from a C program. The popular misconception comes from the fact that .NET uses an intermediate language that has been often described as "P-Code." In reality, .NET employs a technique of multistage compilation: an initial compile to a portable intermediate format and, at runtime, a just-in-time (JIT) compile to the final executable form.

This system, while relatively complex, gives an enormous advantage to the programming community. It means that all languages have a common level that they share in their intermediate form. Therefore, a mixture of modules, written in C#, Visual Basic, Eiffel, FORTRAN, COBOL, or any language that will be supported in the future, can be used to create a single application. The reason for this lies in the fact that a module, once compiled to intermediate language (IL), is packaged along with a full description of itself. Its interfaces, properties, methods , and classes are available as metadata to other modules or to integrated rapid application development environments like Visual Studio .NET.

When the .NET runtime is used to execute a program that has been converted to IL, it uses a JITer to compile the IL to full, native machine code that runs on the microprocessor of the machine. The JITers are very fast and efficient, even to the point of not compiling unused portions of the intermediate code. Obviously, this compilation process takes time, so when load times are important or portability is not needed, the system provides a pre-JIT compiler that converts the IL-based code to a permanent, native format.

The diagram in Figure 1.1.1 shows the strata of the .NET framework as seen by the programmer. The portions in gray are the additions that have been made by .NET.

Figure 1.1.1. A compilers-eye view of .NET.

The .NET framework provides four native languages: C#, Visual Basic, C++ with managed extensions, and JScript. Several other languages are in the pipeline from other companies. For example, Fujitsu has a version of COBOL.

There are basic sets of compilers that take .NET-supported languages and produce the intermediate language modules. Below that are the IL-to- machine-code JITers. There is a standard JITer that is used primarily by systems with plenty of memory and power. This compiles a standard form of IL to an optimized form on the host machine. Then there's the econoJIT compiler that is very fast but does little optimization and relies on a subset of pre-optimized IL. Finally, there is preJIT that creates a native code executable that can be distributed in its ready-compiled form. This method is used only when there is no chance of the program being distributed to another hardware platform.

Finally, sitting partially upon the hardware and partly upon the existing operating system of the machine is the .NET Common Language Runtime (CLR). This functional block provides all the services that components use to interact with the computer or the native OS of the machine. It's interesting to note that the machine hosting the CLR is not identified as a PC, and the operating system does not have to be DOS or Windows. Microsoft has a definite strategy for deploying the .NET framework on many platforms, from the smallest appliances, handhelds, phones, and PDAs right through to Unix and Linux systems. Although it is not immediately available on anything other than an I386 Windows 2000 system, this portability will eventually afford developers a write-once, run- anywhere programming environment.

I l @ ve RuBoard