05 153x ch01_3 8/31/01 1:55 PM Page 31
IL Intermediate Language CHAPTER 1.3
IN THIS CHAPTER
• Language Inter-Op 33 • Hello IL 34 • Functions 35 • Classes 38 • ILDASM 40 • Metadata 42 • Reflection API 43 05 153x ch01_3 8/31/01 1:55 PM Page 32
The .NET Framework 32 PART I
In the current day and age of software development, developers use high-level languages such as C++, Visual Basic, or Java to implement applications and components. I personally don’t know any working binary developers and few assembly language programmers. So why is IL, Intermediate Language, so important to .NET? To answer this question requires a brief tour of compiler theory 101. The basic task of a compiler is to transform readable source code into native executable code for a given platform. The compilation process includes several phases, which include but are not limited to lexical scanning, parsing, abstract syntax tree creation, intermediate code creation, code emission, assembler, and linking. Figure 1.3.1 shows a basic diagram of this process.
Source code abstract syntax tree assembling
Lexical scanning intermediate code linking
parsing code emission executable code
FIGURE 1.3.1 The basic compilation process.
The intermediate code creation poses an interesting question: What if it’s possible to translate a given set of languages into some standard intermediate code? This is where IL fits into the scheme of things. The ability to translate high-level language constructs into a standardized format, such as IL, allows for a single underlying compiler or just-in-time (JIT) compiler. This is the approach taken by .NET. With the introduction of Visual Studio .NET, Microsoft is providing Managed C++, C#, Visual Basic, and ASP.NET, each of which produce IL from their respective source code. There are also several third-party language vendors providing .NET versions of their respective lan- guages. Figure 1.3.2 shows the basic .NET compilation process. It is important to note that IL is not interpreted. Rather, the .NET platform makes use of vari- ous types of just-in-time compilers to produce native code from the IL code. Native code runs directly on the hardware and does not require a virtual machine, as is the case with Java and early versions of Visual Basic. By compiling IL to native code, the runtime performance is increased compared to interpreted languages that run on top of a virtual machine. We will be covering the various types of just-in-time compilers later on. (From here on out I will refer to the just-in-time compiler(s) as the jitter). 05 153x ch01_3 8/31/01 1:55 PM Page 33
IL Intermediate Language 33 CHAPTER 1.3
Managed C++ C# VB.NET Language X… 1.3 IL I L NTERMEDIATE ANGUAGE
IL
JIT Compiler
Native Code
FIGURE 1.3.2 .NET compilation.
IL is a full, stack-based language that you can use to implement .NET components. Although it is definitely not suggested for the sake of productivity, you can use IL to do things that you can’t do with C#. For example, in IL, you can create global functions and call them from within IL. Language Inter-Op Like the quest for the Holy Grail, the ability to seamlessly inter-op between languages has been on the forefront. On the various Windows platforms, the standard for cross language development has been the Component Object Model (COM). An entire industry was born whose sole purpose was developing COM components and ActiveX controls. Because COM is a binary standard, any language capable of consuming COM components is able to use them regardless with which language the COM component was created. Although COM allowed for reusable components, it was far from perfect. Certain languages, such as scripting languages, could only make use of the default interface provided by the COM object. Also, it was not possible to inherit from a COM component to extend its basic function- ality. To extend a binary object, developers were forced to wrap the COM component, not a very OO approach. With the advent of .NET and IL, such barriers no longer exist. Because every language tar- geted at the .NET platform understands IL and the metadata of a .NET component, a new level of interoperability is born. The metadata allows inspection of a .NET component to discover the classes, methods, fields, and interfaces that it contains. The topic of metadata will be cov- ered later in this section. 05 153x ch01_3 8/31/01 1:55 PM Page 34
The .NET Framework 34 PART I
Hello IL Using IL to develop .NET applications and components is probably not something you’ll be doing a lot. However, to truly dig into the .NET framework, a basic understanding of the IL structure is important. The .NET SDK does not ship with the underlying source code. This does not mean you can’t dig into the implementation of the various components. However, it does require some knowledge of IL. The traditional, almost required, first step in learning a new language is to display the infa- mous “Hello World” message on the console. Accomplishing this task with only IL is not as painful as it might sound. IL is not a truly low-level, assembly-like language. As with most modern languages, there is a fair amount of abstraction built into the language. Listing 1.3.1 shows the now famous “Hello World” program written in MSIL.
LISTING 1.3.1 Hello World
1: //File :Hello.cil 2: //Author :Richard L. Weeks 3: // 4: // 5: 6: //define some basic assembly information 7: .assembly hello 8: { 9: .ver 1:0:0:0 10: } 11: 12: 13: //create an entry point for the exe 14: .method public static void main( ) il managed 15: { 16: 17: .entrypoint 18: .maxstack 1 19: 20: 21: //load string to display 22: ldstr “Hello World IL style\n” 23: 24: //display to console 25: call void [mscorlib]System.Console::WriteLine( class System.String ) 26: 27: ret 28: } 29: 05 153x ch01_3 8/31/01 1:55 PM Page 35
IL Intermediate Language 35 CHAPTER 1.3
To compile Listing 1.3.1, issue the following command line: 1.3
ilasm hello.cil IL I L NTERMEDIATE ANGUAGE The IL assembler will produce a .NET hello.exe.
This IL code displays the message “Hello World IL style” by using the static Write method of the System.Console object. The Console class is part of the .NET framework and, as its use implies, its purpose is to write to the standard output. Notice that there is no need to create a class. IL is not an object-oriented language, but it does provide the constructs necessary to describe objects and use them. IL was designed to accom- modate a variety of language constructs and programming paradigms. Such diversity and open- ness in its design will allow for many different languages to be targeted at the .NET runtime. There are a number of directives that have special meanings within IL. These directives are shown in Table 1.3.1.
TABLE 1.3.1 IL Directives used in “Hello World” Directive Meaning
.assembly Name of the resulting assembly to produce .entrypoint Start of execution for an .exe assembly .maxstack Number of stack slots to reserve for the current method or function
Notice that the .entrypoint directive defines the start of execution for any .exe assembly. Although our function has the name main, it could have any name we want. Unlike C, C++, and other high-level languages, IL does not define a function to serve as the beginning of execution. Rather, IL makes use of the .entrypoint directive to serve this purpose.
Another directive of interest is the .assembly directive. IL uses this directive to name the output of the assembly. The .assembly directive also contains the version number of the assembly. Functions The Hello World IL example encompasses only one method. If only all software development requirements were that simple! Because IL is a stack based language, function parameters are pushed onto the stack and the function is called. The called function is responsible for remov- ing any parameters from the stack and for pushing any return value back onto the stack for the caller of the function. 05 153x ch01_3 8/31/01 1:55 PM Page 36
The .NET Framework 36 PART I
The process of pushing and popping values to and from the call stack can be visualized as shown in Figure 1.3.3.
Add function Program Code call stack call stack pop 15 push 10 15 10 push 15 10 call Add 10pop
25pop local result
25push result 25push
ret
FIGURE 1.3.3 The call stack.
Although Figure 1.3.3. depicts a very simplified view of the actual process, enough informa- tion is provide to gain an understanding of the overall steps involved. Translating Figure 1.3.3 into IL produces the source in Listing 1.3.2.
LISTING 1.3.2 IL Function Calls
1: //File :function.cil 2: 3: .assembly function_call 4: { 5: .ver 1:0:0:0 6: } 7: 8: 9: //Add method 10: .method public static int32 ‘add’( int32 a, int32 b ) il managed 11: { 12: 13: .maxstack 2 14: .locals (int32 V_0, int32 V_1) 15: 16: //pop the parameters from the call stack 17: ldarg.0 18: ldarg.1 19: 20: add 21: 22: //push the result back on the call stack 05 153x ch01_3 8/31/01 1:55 PM Page 37
IL Intermediate Language 37 CHAPTER 1.3
LISTING 1.3.2 Continued 1.3 23: stloc.0 IL I L NTERMEDIATE
24: ldloc.0 ANGUAGE 25: 26: ret 27: } 28: 29: .method public static void main( ) il managed 30: { 31: .entrypoint 32: .maxstack 2 33: .locals ( int32 V_0 ) 34: 35: //push two parameters onto the call stack 36: ldc.i4.s 10 37: ldc.i4.s 5 38: 39: call int32 ‘add’(int32,int32) 40: 41: stloc.0 //pop the result in the local variable V_0 42: 43: //Display the result 44: ldstr “10 + 5 = {0}” 45: ldloc V_0 46: box [mscorlib]System.Int32 47: call void [mscorlib]System.Console::WriteLine(class System.String, ➥ class System.Object ) 48: 49: ret 50: } 51:
The function.cil code in Listing 1.3.2 introduces a new directive: .locals. This directive is used to reserve space for local variables used within the current function. The add method defined on line 10 declares space for two local variables. The parameters that were passed to the add method are loaded into the reserved space using the ldarg statement. After the add instruction has been issued, the next step is to store the result and then to push the result back onto the call stack.
The main method only allocates space for a single local variable. This local variable will be used to hold the result returned from the user-defined add method. The process of pushing the values 10 and 5 onto the stack, calling the add method, and popping the result correspond to the depiction in Figure 1.3.3. 05 153x ch01_3 8/31/01 1:55 PM Page 38
The .NET Framework 38 PART I
You’ve no doubt noticed the box instruction on line 46. Boxing is something new to .NET. Boxing allows for value-types, such as primitives, to be treated as objects. Classes As previously stated, IL is not an OO language in itself. For IL to support multiple source lan- guages and constructs, IL supports the notion of creating classes and creating instances of classes. Looking at the IL for declaring and creating classes will give you a better understand- ing of the Common Language Specification (CLS). Listing 1.3.3 shows the IL code for creat- ing and using a class.
LISTING 1.3.3 Creating a Class in IL
1: .assembly class_test as “class_test” 2: { 3: .ver 1:0:0:0 4: } 5: 6: 7: .module class_test.exe 8: 9: 10: //Create a class Dog with two public fields 11: 12: .class public auto ansi Dog extends [mscorlib]System.Object { 13: 14: //public data fields 15: .field public class System.String m_Name 16: .field public int32 m_Age 17: 18: 19: //Create a method to display the fields 20: .method public hidebysig instance void Print() il managed 21: { 22: .maxstack 8 23: ldstr “Name : {0}\nAge :{1}” 24: ldarg.0 25: ldfld class System.String Dog::m_Name 26: ldarg.0 27: ldfld int32 Dog::m_Age 28: box [mscorlib]System.Int32 29: call void [mscorlib]System.Console::WriteLine( ➥class System.String, 30: class System.Object, 31: class System.Object) 05 153x ch01_3 8/31/01 1:55 PM Page 39
IL Intermediate Language 39 CHAPTER 1.3
LISTING 1.3.3 Continued 1.3
32: ret IL I L
33: } NTERMEDIATE ANGUAGE 34: 35: //The Constructor 36: .method public hidebysig specialname rtspecialname instance void .ctor() ➥ il managed 37: { 38: .maxstack 8 39: ldarg.0 40: call instance void [mscorlib]System.Object::.ctor() 41: ret 42: } 43: 44: } 45: 46: .method public static void Main() il managed 47: { 48: .entrypoint 49: 50: .maxstack 2 51: 52: .locals (class Dog V_0) 53: 54: newobj instance void Dog::.ctor() 55: stloc.0 56: ldloc.0 57: ldstr “Daisy” 58: stfld class System.String Dog::m_Name 59: ldloc.0 60: ldc.i4.3 61: stfld int32 Dog::m_Age 62: ldloc.0 63: call instance void Dog::Print() 64: ret 65: } 66:
Creating a class in IL is a fairly straightforward process. The Dog class declared in Listing 1.3.3 derives from the System.Object class, which is the base class of all .NET classes. In .NET, data members are known as fields and as such are marked with the .field keyword. To define a class method, all that is required is to define the method within the scope of the class to which the method belongs. The Print method is declared on line 20 of Listing 1.3.3. Notice the instance method modifier that is applied to the Print method. For the Print method to be invoked, an instance of the Dog class is required. 05 153x ch01_3 8/31/01 1:55 PM Page 40
The .NET Framework 40 PART I
The same is true for the constructor of the Dog class. IL provides two modifiers that must be applied to instance constructors. The rtspecialname modifier is used by the runtime, whereas the specialname is provided for various .NET tools, such as Visual Studio .NET. ILDASM The .NET ships with several tools, ranging from compilers to form designers. However, the most important tool is ILDASM, Intermediate Language Disassembler. ILDASM allows for peeking into various .NET assemblies. Regardless of the language used to implement the assembly, ILDASM is capable of displaying the resulting IL. The main window of ILDASM creates a treeview detailing the contents of a .NET assembly. The treeview is grouped by namespace with each namespace containing one or more nested namespaces, structs, classes, interfaces, or enumerations (see Figure 1.3.4).
FIGURE 1.3.4 ILDASM with mscorlib.dll loaded.
Locate the .NET assembly mscorlib.dll and use ILDASM to view the contents. Depending on the install of the .NET SDK, the .NET assemblies should be located in
IL Intermediate Language 41 CHAPTER 1.3
1.3 IL I L NTERMEDIATE ANGUAGE
FIGURE 1.3.5 ILDASM symbol table.
At the heart of the .NET framework is the mscorlib.dll assembly. This assembly contains most of the standard classes and interfaces that comprise .NET. Certainly there are other assemblies for database access, networking, security and such, but at the root of it all is mscorlib.dll. Using the symbol table in Figure 1.3.5, you can visually determine entity types found within mscorlib.dll. Locate System.Object and double-click the node to expand it (see Figure 1.3.6).
FIGURE 1.3.6 System.Object in ILDASM.
The System.Object class is the base class of all .NET classes. The System.Object base class provides shared functionality used throughout .NET. Locate the ToString method and double- click it to view the underlying IL code that comprises it (see Figure 1.3.7). 05 153x ch01_3 8/31/01 1:55 PM Page 42
The .NET Framework 42 PART I
FIGURE 1.3.7 IL code for System.Object.ToString().
MFC developers were accustomed to having the Visual C++ source code to the MFC frame- work readily available for their inspection. This is not the case with the .NET framework. Currently, the only way to get a peek under the covers is to use a tool such as ILDASM to view the IL implementation. Although IL is not as easy to read as, say, C# or VB.NET, it will allow for an understanding of the internal workings of the .NET classes none the less. ILDASM provides the ability to produce a text file with the complete IL source for a given .NET assembly. Launching ILDASM from the command line and using the /OUT=
Every component in .NET contains metadata. Metadata describes the runtime types, classes, interfaces, structs, and all entities within a .NET component. Metadata also provides implementation and layout information that the .NET runtime makes use of to JIT compile IL code. Metadata is available to all tools through two different sets of APIs. There exists a set of low- level, unmanaged APIs and a set of managed APIs that can be used to gather information about a .NET component. There also exists a set of APIs for emitting Metadata. This emit API is used by compilers during compilation of a given source language into IL for the .NET runtime. A full description of the Metadata APIs and infrastructure would require another book in itself, 05 153x ch01_3 8/31/01 1:55 PM Page 43
IL Intermediate Language 43 CHAPTER 1.3
but this text will present a small sample of how to use the Reflection API to inspect a .NET 1.3
component. IL I L NTERMEDIATE Reflection API ANGUAGE Reflection represents an extremely powerful mechanism for working with .NET components. Through the use of reflection, .NET components can be dynamically loaded and their contents discovered at runtime. Metadata is the heart of this functionality and, as such, Metadata can be thought of as a TypeLib on steroids.
The .NET CLR provides for strong runtime type information and provides a System.Type class. After a .NET component is loaded, it is then possible to obtain the type or types con- tained within the given assembly. To demonstrate the power of Metadata and the Reflection API, create a text file named employee.cs and copy Listing 1.3.4 into it. To compile the list- ing, issue the following command:
csc /t:library employee.cs
This will build the employee.dll assembly.
LISTING 1.3.4 The Employee Class
1: //File :employee.cs 2: //Author :Richard L. Weeks 3: //Purpose :Create a .NET component and use the reflection 4: // API to view the component 5: 6: using System; 7: 8: namespace stingray { 9: 10: 11: //Create a basic class 12: public class Employee { 13: 14: //private data members 15: private string m_FirstName; 16: private string m_LastName; 17: private string m_Title; //Job Title 18: 19: //Public Properties 20: public string FirstName { 21: get { return m_FirstName; } 22: set { m_FirstName = value; } 23: } 05 153x ch01_3 8/31/01 1:55 PM Page 44
The .NET Framework 44 PART I
LISTING 1.3.4 Continued
24: 25: public string LastName { 26: get { return m_LastName; } 27: set { m_LastName = value; } 28: } 29: 30: public string Title { 31: get { return m_Title; } 32: set { m_Title = value; } 33: } 34: 35: //Public Methods 36: public void ShowData( ) { 37: object[] args = { m_LastName, m_FirstName, m_Title }; 38: 39: Console.WriteLine(“********************\n”); 40: Console.WriteLine(“Employee : {0}, {1}\nTitle :{2}\n”, ➥ args); 41: Console.WriteLine(“********************\n”); 42: } 43: 44: //Private methods 45: private void Update( ) { 46: //TODO: Update Employee information 47: } 48: } 49: } 50:
The Employee class resides in the stingray namespace and contains three private data mem- bers, corresponding public properties, and two methods. Using the Reflection API, it is possi- ble to dynamically load the employee.dll at runtime. After the assembly has been loaded, all types contained within the assembly can be queried and their Metadata accessed. Listing 1.3.5 makes use of the Reflection API to peek into a .NET component.
LISTING 1.3.5 Metaview Source Listing
1: //File :metaview.cs 2: //Author :Richard L. Weeks 3: //Purpose :Use the Managed Reflection API 4: // to inspect a .NET component 5: 6: 05 153x ch01_3 8/31/01 1:55 PM Page 45
IL Intermediate Language 45 CHAPTER 1.3
LISTING 1.3.5 Continued 1.3
7: using System; IL I L NTERMEDIATE
8: using System.Reflection; ANGUAGE 9: 10: 11: 12: public class ClsView { 13: 14: 15: public static void Main( String[] args ) { 16: 17: try { 18: 19: //Load the assembly 20: Assembly asm = Assembly.LoadFrom( args[0] ); 21: 22: //Get the Types contained within the Assembly 23: System.Type[] Types = asm.GetTypes( ); 24: 25: //Display basic information about each type 26: foreach( Type T in Types ) { 27: Console.WriteLine(“Type {0}”, T.FullName); 28: DisplayFields( T ); 29: DisplayProperties( T ); 30: DisplayMethods( T ); 31: Console.WriteLine(“”); 32: } 33: 34: } catch( Exception ex ) { 35: Console.WriteLine( ex ); 36: } 37: 38: } 39: 40: 41: public static void DisplayFields( Type T ) { 42: Console.WriteLine(“*****[ DisplayFields ]*****”); 43: FieldInfo[] Fields = T.GetFields( ➥System.Reflection.BindingFlags.Instance | 44: ➥System.Reflection.BindingFlags.Public | 45: ➥System.Reflection.BindingFlags.NonPublic ); 46: 47: foreach( FieldInfo F in Fields ) 48: Console.WriteLine( “FieldName = {0}”, F.Name ); 05 153x ch01_3 8/31/01 1:55 PM Page 46
The .NET Framework 46 PART I
LISTING 1.3.5 Continued
49: } 50: 51: public static void DisplayProperties( Type T ) { 52: Console.WriteLine(“*****[ Display Properties ]*****”); 53: System.Reflection.PropertyInfo[] Properties = T.GetProperties( ➥ System.Reflection.BindingFlags.Instance | ➥System.Reflection.BindingFlags.Public | ➥System.Reflection.BindingFlags.NonPublic ); 54: 55: foreach( PropertyInfo pi in Properties ) 56: Console.WriteLine( pi.Name ); 57: } 58: 59: public static void DisplayMethods( Type T ) { 60: Console.WriteLine(“*****[ Display Methods ]*****”); 61: System.Reflection.MethodInfo[] Methods = T.GetMethods( ➥ System.Reflection.BindingFlags.Instance | ➥System.Reflection.BindingFlags.Public | ➥System.Reflection.BindingFlags.NonPublic ); 62: 63: foreach( MethodInfo mi in Methods ) 64: Console.WriteLine( mi.Name ); 65: } 66: }
Listing 1.3.5 makes use of the most basic Reflection APIs to detail information about each field, property, and method with the loaded employee assembly. Although the C# language has not been covered yet, most of the code should speak for itself. I encourage you to implement a robust version of Metaview, complete with a Windows Forms GUI. Such a project will no doubt increase your knowledge of .NET and the rich set of features it provides. Summary We’ve covered a lot of ground in this chapter. Topics included IL, ILDASM, metadata, and Reflection. The .NET framework certainly gives a hint as to the future of software develop- ment. No longer is language a barrier; the .NET platform provides languages targeted to the superior interoperability that, until now, has not been easy to use or extend. Gone are the days of using IDL and DEF files to describe the interfaces exposed by objects. Rather, all objects, interfaces, and members are fully described with metadata. Those develop- ers who are familiar with Java will appreciate the decision to include Reflection in .NET because it provides a powerful paradigm to extend the life of applications and use new compo- nents dynamically.