Managed and Unmanaged Code

I l @ ve RuBoard

Before proceeding further, let's review part of the.NET architecture, along with some terminology. As you'll recall from Chapter 2, code built for .NET executes in an application domain, which runs under the auspices of the common language runtime. This code uses the facilities of the .NET platform to provide features such as type safety, code verification, memory allocation and deallocation, and other runtime management. Such code is therefore said to be managed . On the other hand, COM components , DLLs, and other heritage objects are not designed to operate in such a cozy, safe environment. They can freely stamp all over memory allocated to the application in which they are running, leak memory like a sieve, do freaky things such as invalid type casting, and generally make a mess. This kind of code is said to be unmanaged .

To further contrast these two modes, consider the following:

• The common language runtime executes machine code, not Microsoft Intermediate Language (MSIL). The JIT compiler converts MSIL into machine code before the common language runtime runs it. The common language runtime is itself a set of unmanaged DLLs (mscoree.dll, mscorwks.dll, mscorsvr.dll, and others) that provide memory management, protection, and garbage collection (referred to as the managed heap ). It relies on tools such as compile-time verification (which can be turned off!) to ensure that the code does not do anything bad.

• Unmanaged code executes in the same process as managed code. The common language runtime can load an unmanaged DLL and invoke its methods . An unmanaged DLL cannot be verified , like MSIL can. As a result, unmanaged methods can do anything to the process, as described above. Furthermore, although unmanaged code uses its own unmanaged heap and stack space, it can access the managed heap of the common language runtime through methods exposed by the .NET Framework Class Library. It is thus vitally important that any unmanaged code that you execute from the common language runtime be trustworthy and correct! Security constraints relating to unmanaged code are described later in this chapter.

At this juncture, a couple of points are worth noting. First, even though managed and unmanaged code function as part of the same process, they are said to execute in different spaces, mainly because managed code is executed by common language runtime DLLs and unmanaged code isn't. The managed and unmanaged spaces have their own heaps, and managed and unmanaged code sometimes use different data formats. Second, calling unmanaged code from the managed environment requires a transition from the managed to the unmanaged space. This procedure involves the marshaling of data, passing information to convey how method parameters and return types should be interpreted in the two different spaces, and indicating how the unmanaged code should be located and invoked. The situation is conceptually similar to performing cross-apartment method calls in COM, and some of the techniques used are also similar.

I l @ ve RuBoard