.NET IL Assembler

Frontmatter

Chapter 1. Simple Sample

Abstract

This chapter offers a general overview of ILAsm, the MSIL assembly language. (MSIL stands for Microsoft intermediate language, which will soon be discussed in this chapter.) The chapter reviews a relatively simple program written in ILAsm, and then I suggest some modifications that illustrate how you can express the concepts and elements of Microsoft .NET programming in this language.

Serge Lidin

Chapter 2. Enhancing the Code

Abstract

In this chapter, you’ll continue tweaking the simple sample; maybe you can make it better. There are two aspects of “better” I will discuss in this chapter: first, reducing code size and, second, protecting the code from unpleasant surprises. Let’s start with the code size.

Serge Lidin

Chapter 3. Making the Coding Easier

Abstract

I don’t know about you, but for me this endless typing and retyping of the same code again and again is fun way below the average. Let’s see how ILAsm 2.0 or later can make this work less tedious. There are three useful additions to the assembler syntax that can be exploited: aliasing, compilation control directives, and special keywords for the current class and its parent.

Serge Lidin

Chapter 4. The Structure of a Managed Executable File

Abstract

Chapter 1 introduced the managed executable file, known as a managed module and executed in the environment of the common language runtime. In this chapter, I’ll show you the general structure of such a file. The file format of a managed module is an extension of the standard Microsoft Windows Portable Executable and Common Object File Format (PE/COFF). Thus, formally, any managed module is a proper PE/COFF file, with additional features that identify it as a managed executable file.

Serge Lidin

Chapter 5. Metadata Tables Organization

Abstract

This chapter provides an overview of metadata and how it is structured. It also describes metadata validation. Later chapters will analyze individual metadata items based on the foundation presented here. I understand your possible impatience (“When will this guy quit stalling and get to the real stuff?”) but nevertheless I urge you not to skip this chapter. Far from stalling, I’m simply approaching the subject systematically. It might look the same, but the motivation is quite different, and that’s what matters.

Serge Lidin

Chapter 6. Modules and Assemblies

Abstract

This chapter discusses the organization, deployment, and execution of assemblies and modules. It also provides a detailed examination of the metadata segment responsible for assembly and module identity and interaction: the manifest. As you might recall from Chapter 1, an assembly can include several modules. Any module of a multimodule assembly can—and does, as a rule—carry its own manifest, but only one module per assembly carries the manifest that contains the assembly’s identity. This module is referred to as the prime module. Thus, each assembly, whether multimodule or single-module, contains only one prime module.

Serge Lidin

Chapter 7. Namespaces and Classes

Abstract

As earlier chapters have discussed, the common language runtime computational model is inherently object-oriented. The concept of class—or, to use more precise runtime terminology, the concept of a type—is the central principle around which the entire computational model is organized. The type of an item—a variable, a constant, a parameter, and so on—defines both data representation and the behavioral features of the item. Hence, one type can be substituted for another only if both these aspects are equivalent for both types. For instance, a derived type can be interpreted as the type from which it is derived.

Serge Lidin

Chapter 8. Primitive Types and Signatures

Abstract

Having looked at how types are defined in the common language runtime and ILAsm, let’s proceed to the question of how these types and their derivatives are assigned to program items—fields, variables, methods, and so on. The constructs defining the types of program items are known as the signatures of these items. Signatures are built from encoded references to various classes and value types; I’ll discuss signatures in detail in this chapter.

Serge Lidin

Chapter 9. Fields and Data Constants

Abstract

Fields are one of two kinds of typed and named data locations, the second kind being method local variables, which are discussed in Chapter 10. Fields correspond to the data members and global variables of the C++ world. Apart from their own characteristics, fields can have additional information associated with them that defines the way the fields are laid out by the loader, how they are allocated, how they are marshaled to unmanaged code, and whether they have default values. This chapter examines all aspects of member and global fields, and the metadata used to describe these aspects.

Serge Lidin

Chapter 10. Methods

Abstract

Methods are the third and last leg of the tripod supporting the entire concept of managed programming, the first two being types and fields. When it comes down to execution, types, fields, and methods are the central players, with the rest of the metadata simply providing additional information about this triad.

Serge Lidin

Chapter 11. Generic Types

Abstract

Generic types, introduced in version 2.0 of the CLR, differ from “normal” (nongeneric) types in one major aspect: “normal” types, even the abstract ones, are fully defined, while generic types represent pure abstractions—templates for the generation (or instantiation) of “normal” types. Generic types are pure abstractions because they describe types constructed not from other types but from abstract type parameters, or type variables. Thus, a generic type has one or more type parameters and hence belongs to parameterized types. You are already familiar with one generic type implemented in versions 1.0 and 1.1 of the CLR—a vector (single-dimensional, zero lower-bound array). A vector doesn’t exist per se—it’s always a vector “of something,” such as a vector of 32-bit integers, a vector of strings, or a vector of objects, and so on. The vector was (and still is) an intrinsic generic type in the sense it is implemented by the CLR but has no representation as a separate class.

Serge Lidin

Chapter 12. Generic Methods

Abstract

Generic methods are methods that carry type parameters in addition to their “normal” method parameters. These type parameters are subject to all the rules governing the type parameters of generic types, discussed in Chapter 11. This simplifies the discussion of generic methods significantly; therefore, this chapter will be brief.

Serge Lidin

Chapter 13. IL Instructions

Abstract

When a method is executed, three categories of memory local to the method plus one category of external memory are involved. All these categories represent typed data slots, not simply an address interval as is the case in the unmanaged world. The external memory manipulated from the method is the community of the fields the method accesses (except the fields of value types belonging to the local categories). The local memory categories include an argument table, a local variable table, and an evaluation stack. Figure 13-1 describes data transitions between these categories. As you can see, all IL instructions resulting in data transfer have the evaluation stack as a source or a destination, or both.

Serge Lidin

Chapter 14. Managed Exception Handling

Abstract

Usually the exception handling model of a programming language is considered the domain of that particular language’s runtime. Under the hood, each language has its own way of detecting exceptions and locating an appropriate exception handler. Some languages perform exception handling completely within the language runtime, whereas others rely on the structured exception handling (SEH) mechanism provided by the operating system—which in your case is Win32 or Win64.

Serge Lidin

Chapter 15. Events and Properties

Abstract

Events and properties are special metadata components that are intended to make life easier for the high-level language compilers. The most intriguing feature of events and properties is that the JIT compiler and the execution engine are completely unaware of them. Can you recall any IL instruction that deals with an event or a property? That’s because none exist.

Serge Lidin

Chapter 16. Custom Attributes

Abstract

Every system worth its salt needs extensibility. The languages that describe an extensible system and their compilers need extensibility as well; otherwise, they are describing not the system but rather its glorious past.

Serge Lidin

Chapter 17. Security Attributes

Abstract

As a platform for massively distributed operations, the Microsoft .NET Framework must have an adequate security mechanism. We all know that distributed platforms, especially those exposed to the Internet, are the favorite targets of all sorts of pranks and mischief, which can sometimes be very destructive.

Serge Lidin

Chapter 18. Managed and Unmanaged Code Interoperation

Abstract

There can be no question about the need to provide seamless interoperation between managed and unmanaged code, and I’m not going to waste time discussing this obvious point.

Serge Lidin

Chapter 19. Multilanguage Projects

Abstract

The Microsoft .NET paradigm is multilanguage by its very nature. You can derive your class from another class that has been declared in an assembly produced by someone else, and you don’t need to worry about how the language you are using relates to the language used to write the other assembly. You can create a multimodule assembly, each module of which is written in a different language.

Serge Lidin

Chapter 20. ILAsm Grammar Reference

Abstract

ID - C style alphanumeric identifier (e.g., Hello_There2)

Serge Lidin

Chapter 21. Metadata Tables Reference

Abstract

■■■

Serge Lidin

Chapter 22. IL Instruction Set Reference

Abstract

■■■

Serge Lidin

Chapter 23. IL Assembler and Disassembler Command-Line Options

Abstract

This appendix describes the command-line options of the IL assembler (ilasm.exe) and the IL disassembler (ildasm.exe).

Serge Lidin

Chapter 24. Offline Verification Tool Reference

Abstract

An offline verification tool for managed PE files, PEVerify.exe is distributed with the Microsoft .NET Framework SDK. The tool includes two components: the metadata validator (MDValidator) and the IL verifier (ILVerifier).

Serge Lidin

Backmatter