The CLR
The CLR At the heart of the .NET Framework is the Comman Languaage Runtime (CLR). The CLR is an execution environment that loads and executes code. Code that runs under the control of the CLR is called managed code. You can still create code that runs in the same way that Win32 executables and Dynamic Link Libraries (DLLs) run now, and this type of code is now called unmanaged code. Managed code will enjoy a number of benefits that aren't afforded to unmanaged code, including automatic memory management (garbage collection), type safety, security, a simple consistent programming model, simplified deployment, rich debugging support, consistent error handling, language independence, and even the possibility running on different platforms. All of these benefits are provided by the CLR. How do you create managed code? Simple, you create source code using one of several languages, including C# (Microsoft's new "light" version of C++ that is very similar to the Java programming language); Visual Basic.NET (VB.NET, which is a vastly improved version of VB); an enhanced version of C++ called C++ with Managed Extensions; or a number of third-party languages, including COBOL, Eiffel, Smalltalk, and Pascal. Then you compile your code using one of many CLR-compliant compilers that are designed to emit managed code. Instead of emitting native code for your platform, the compiler generates code in a platform-independent, assembly-like language called Microsoft Intermediate Language (MSIL). This code is inserted into a binary (either an executable or DLL), along with a stub program that loads the CLR, and then begins executing the MSIL code in the managed code binary. The CLR compiles the MSIL into native code as it goes. MSILA compiler that generates managed code has to do a few things differently than a standard, Win32 compiler. Figure 1-4 shows the difference between a managed code compiler and a Win32 compiler. Figure 1-4. The managed code compilation process. The Win32 compiler simply reads the source file and generates a Portable Executable (PE) file that contains x86 machine code. Note The WIN32 PE file format is just the name for the file format that executable (EXE and DLL) files use on WIN32 operating systems (Windows NT, Windows ME/9x, Windows 2000, and so forth). This file format is "portable" in the sense that it runs on a number of WIN32 operating systems. A managed code compiler also generates a PE file, but this file contains MSIL code and metadata. You can think of MSIL as a virtual assembly language. It defines a set of assembly language-like operations that are easily translated into the native instruction set of most modern CPUs. The CLR uses the Virtual Execution System (VES) to compile the MSIL code into native code on the fly as you run a managed code executable. This process of converting MSIL code into native code is called just-in-time (JIT) compilation. The VES does not compile the code all at once; it compiles it method by method as the code is used. As soon as the MSIL for a method is compiled into native code, the MSIL code for that method is replaced with the compiled native code so that the next time the method is called it will run at native code speed. I can't emphasize this enough. The CLR is not an interpreter. If you know the Java programming language already, it would be very easy to think that MSIL is equivalent to Java bytecodes and that the CLR is equivalent to the Java runtime. Although MSIL is actually conceptually similar to Java bytecodes, which also define a virtual assembly language, the CLR does not interpret MSIL code as the Java runtime does. MSIL code is always compiled into native code and then executed. Just remember that MSIL is never interpreted, and the CLR is not an interpreter. Note If you do not know what Java bytecodes and the Java runtime are, don't worry, I compare and contrast the Java programming language and the .NET Framework later in this chapter. If you're still thinking that this " on-the-fly " compilation will be too slow, consider a few points. (1) The CLR compiles codeone function at a timeas you run a managed code executable. Therefore, it only compiles the code that you actually use. When you run most applications, you only use a fraction of the code in the executable. For instance, right now I'm using Microsoft Word to write this book. I consider myself to be an advanced user of Word, but still, in any given session with Word, I only use a tiny portion of the capability of Word. The larger an executable is means the more likely that a user will only use a small portion of the code in that executable in any given session. (2) Don't compare the amount of time that it takes to compile a C++ or VB application with the amount of time it takes to compile MSIL code. A source code compiler has to do basic syntax checking and lexical analysis. The process of converting MSIL code to native code is much faster than converting source code directly to native code, which is what Win32 compilers do. There is a much closer mapping between MSIL and the native instruction set of most CPUs than there is between high-level programming languages like C# and those instruction sets. Still, I have noticed with the beta versions of the .NET Framework that there is a noticeable lag when you first start using a .NET application. After a good portion of the code in the application has been compiled, though, it runs at least as quickly as a Win32 application. MetadataThe metadata in a managed code executable is binary information that describes everything that you might want to know about the classes and other types that are implemented in an executable or DLL. This metadata is similar to, but far more complete than, the information in a COM-type library, and, unlike a type library, this metadata always resides in the executable or DLL that it describes. A managed code compiler must insert metadata into the binary files that it creates. Note The .NET Framework provides services that make it easy for a managed code compiler to emit this metadata. The metadata is used in a number of ways. Visual Studio.NET uses metadata to display Intellisense information to developers while they are creating a class. The metadata also enables compilers to do type-checking and method call signature checking to verify that you are calling a method with the correct number and types for the input parameters. Metadata is also used by compilers to lay out objects efficiently in memory and by system-level code to implement marshaling, that is, to allow code running in one process to use code that is executing in a different process. Cross-Language InteroperabilityThe CLR enables an unprecedented level of cross-language interoperability. Whether you are using VB.NET or Microsoft's new Java-like language called C# (pronounced C-Sharp), or any of a dozen other CLR-compliant programming languages, you can mix code written in different programming languages with ease. You can instantiate classes created in one language from code written in a different language. You can throw exceptions from a method in a class written in one language and catch them in a method that was written in some other language. You can evenhold on to your hatscreate a class in one language and then derive a subclass using a completely different language. The level of language interoperability afforded by the CLR is far beyond what was ever offered with COM. The key enabling technologies in the CLR that make that is possiblein addition to MSILare the Common Type System (CTS), the Common Language Specification (CLS), and the Virtual Object System (VOS). The CTS provides a common type representation for all CLR-compliant languages. The CLS defines the subset of the CTS that you must restrict yourself to and a set of rules that compiler and framework developers must follow to ensure that their software is usable by all CLR-compliant programming languages. The VOS defines an object model that is shared by all CLR-compliant programming languages I won't go into an in-depth summary of the CTS, the CLS, and the VOS in this chapter because it was intended to be an executive overview, but I discuss these important elements of the CLR in Chapter 3.
 |
| | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 119