
.NET DEVELOPER
Introduction to the .NET runtime
Kevin Burton 05.07.2002
Rating: -3.25- (out of 5)




.NET Developer Tip
Introduction to the .NET runtime
Kevin Burton
One of the changes in .NET is the use of the runtime module, which is used by executables to accomplish tasks. This tip, excerpted from InformIT, discusses this entity. The tip comes from a chapter of .NET Common Language Runtime Unleashed, by Kevin Burton, published by Sams.
Before .NET, an executable (usually a file with an .exe suffix), was the application. In other words, the application was contained within one file. To make the overall system run more efficiently, the application would elect to use code that was shared (usually a file with a .dll suffix). If the program elected to use shared code, you could either use an import library (a file that points function references to the DLL that is associated with the import library), or you could load the DLL explicitly at runtime (using LoadLibrary, LoadLibraryEx, and GetProcAddress). With .NET, the unit of execution and deployment is the assembly. Execution usually begins with an assembly that has an .exe suffix. The application can use shared code by importing the assembly that contains the shared code with an explicit reference. (You can add the reference via the "Add References" node in Visual Studio .NET or include it via a command-line switch /r). The application can also explicitly load an assembly with Assembly.Load or Assembly.LoadFrom.
Before going further, you need to learn definitions of some of the terms:
After the code is "loaded," execution of the code can begin. This is where the old (pre-.NET) and the new (.NET) start to diverge significantly. In the case of unmanaged code, the compiler and linker have already turned the source into native instructions, so those instructions can begin to execute immediately. Of course, this means that you will have to compile a separate version of the code for every different native environment. In some cases, because
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
');
// -->

it is undesirable to ship and maintain a separate version for every possible native environment, only a compatible version is compiled and shipped. This leads to a lowest common denominator approach as companies want to ship software that can be run on as wide a range of environments as possible. Currently, few companies ship programs that target environments that have an accelerated graphics engine. Not only would the manufacturer need to ship a different program for each graphics accelerator card, but a different program also would need to be developed for those cases where a graphics accelerator was lacking. Other examples of hardware environments in which specific optimizations could be taken advantage of would be disk cache, memory cache, high-speed networks, multiple CPUs, specialized hardware for processing images, accelerated math functions, and so forth. In numerous other examples, compiling a program ahead of time either results in a highly optimized yet very specific program, or an unoptimized and general program.
One of the first steps that the CLR takes in running a program is checking the method that is about to be run to see whether it has been turned into native code. If the method has not been turned into native code, then the code in the method is Just-In-Time compiled (JITd). Delaying the compilation of a method yields two immediate benefits. First, it is possible for a company to ship one version of the software and have the CLR on the CPU where the program is installed take care of the specific optimizations that are appropriate for the hardware environment. Second, it is possible for the JIT compiler to take advantage of specific optimizations that allow the program to run more quickly than a general-purpose, unmanaged version of the program. Systems built with a 64-bit processor will have a "compatibility" mode that allows 32-bit programs to run unmodified on the 64-bit CPU. This compatibility mode will not result in the most efficient or fastest possible throughput, however. If an application is compiled into IL, it can take advantage of the 64-bit processing as long as a JIT engine can target the new 64-bit processor.
The process of loading a method and compiling it if necessary is repeated until either all of the methods in the application have been compiled or the application terminates. The rest of this chapter explores the environment in which the CLR encloses each class method.
To read this entire tip, click over to InformIT. You have to register there, but the registration is free.
For More Information
 |

|
|
 |
|
 |