In an unmanaged Windows environment, applications are isolated from one another by process boundaries. As shown in Figure 2-1, each Win32 program is given its own process and a 4 GB virtual address space to go along with it. Additional libraries or components share this address space with their client. The operating system handles all the work associated with mapping the virtual address space to an actual address in memory. The advantage of this isolation is that if a program crashes, it won't take the entire system down—just the current process.
Under .NET, the CLR manages the memory; Windows doesn't give it to you directly. One reason for this is garbage collection. The CLR needs to know where memory is located to free it or determine if it is in use at all, which is why no pointers are allowed in managed code. This level of indirection, in regard to memory, allows the CLR to provide application isolation with more granularity. In .NET, an entity called an application domain determines isolation.
Sidebar 2. Managed Versus Unmanaged Code
The term managed code refers to code compiled under the .NET Framework. The framework automatically manages the lifetime of an object, hence the term. Unmanaged code is simply all other code running outside of the bounds of .NET.
As shown in Figure 2-2, several application ...