Introduction to Microsoft Intermediate Language

Although this description of the workings of ASP.NET and the .NET Framework might sound a lot like a description of the way a Java Virtual Machine (JVM) works, ASP.NET and JVM are different. A Java compiler creates byte code, and that byte code is passed through the JVM at runtime. This approach is slightly different than using an intermediate language to generate native code at runtime, but that slight difference has enormous implications with respect to performance.

Java's use of byte code is really nothing new. Long ago, other environments used this same structure and generally failed, partly because the hardware wasn't up to the task and partly just because the Internet didn't exist. What the .NET Framework offers that is genuinely different is code that isn't interpreted at runtime but rather becomes native code that is executed directly. One of Java's strengths (and also something that can drive developers crazy at times) is the tight security the Java/JVM model provides. The .NET Framework provides the same level of security, along with the ability to run native code, provided the user has the proper security clearance.

One significant advantage that the .NET Framework offers over Java and the JVM is the choice of programming language. If you target the JVM, you must use Java. Java is a perfectly fine programming language, but it's just one language. Developers comfortable with Visual Basic or C++ would have to spend time learning how to use the Java/JVM model. The .NET Framework allows developers to work in whatever language they're most comfortable with, from Visual Basic and C# to Eiffel and COBOL.

Let's take a look at the world's simplest Visual Basic .NET program: Public Module modmain Sub Main()

System.Console.WriteLine("Hello .NET World!") End Sub End Module

For a moment, ignore anything you don't recognize here from earlier versions of Visual Basic. The intent of this program should be clear—it simply writes the string "Hello .NET World!" to the console. The details of this program are unimportant for now; it's the output we're interested in. This program, when compiled on a machine with the .NET Framework installed, will compile when the following command line is executed:

vbc HelloDotNet.vb /out:HelloDotNet.exe Note Knowing how to use the command-line compiler isn't essential for an ASP.NET programmer, especially one who is planning to use Visual Studio .NET. At times, however, knowing how to compile from the command line can give you a better understanding of what is happening in Visual Studio .NET, as well as automate tasks.

The resulting executable file is about 3 KB, and when run, it does indeed print "Hello .NET World!" to the console, as advertised. The executable file consists of two parts: the first part is MSIL code that is used to generate the native code. The second part is metadata, which is information about the code and other elements that is required by the runtime. The .NET Framework includes a program named MSIL Disassembler (Ildasm.exe). Running the MSIL Disassembler and passing in the name of the executable file we just created results in the output shown in Figure 2-2.

B lädvari

t WM^IWfumM

ÄÖ ■ IÖI WOi DO 1

J Nv -ndl

■ ■■ M.r.—i!,. I^j

I I1

Figure 2-2 : The Ildasm.exe window when HelloDotNet.exe is examined

For our purposes, the significant part of the output is the last item in the tree: Main : void(). C/C++ veterans will recognize the reference to void. In this case, it confirms that this is a section of code that doesn't return any value. A function that returns void in C/C++ is the same as a Visual Basic Sub function. When you double-click on this item, a window containing the following code appears:

.method public static void Main() cil managed

.entrypoint

.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() ( 01 00 00 00 ) // Code size 11 (0xb) .maxstack 8

IL 0000: ldstr "Hello .NET World!"

IL_0005 IL 000a call ret void [mscorlib]System.Console::WriteLine(string)

} // end of method modmain::Main Even without the source code for this simple routine, and knowing nothing about MSIL, it's not too difficult to figure out what's going on. Line IL_0000 is loading the constant string "Hello .NET World!". The next line is calling another void function, System.Console::WriteLine. This function expects a string. Notice also the reference to mscorlib—for now, you can take it on faith that this is a major library in the .NET Framework. Pressing Ctrl+M displays a window containing the metadata for HelloDotNet.exe, shown in Listing 2-1.

Was this article helpful?

0 0

Post a comment