Datasheet

Figure 1-2
In general, any process is able to access memory only by specifying an address in virtual memory —
processes do not have direct access to physical memory. Hence it is simply impossible for one process to
access the memory allocated to another process. This provides an excellent guarantee that any badly
behaved code will not be able to damage anything outside its own address space. (Note that on Windows
95/98, these safeguards are not quite as thorough as they are on Windows NT/2000/XP/2003, so the
theoretical possibility exists of applications crashing Windows by writing to inappropriate memory.)
Processes don’t just serve as a way to isolate instances of running code from each other. On Windows
NT/2000/XP/2003 systems, they also form the unit to which security privileges and permissions are
assigned. Each process has its own security token, which indicates to Windows precisely what opera-
tions that process is permitted to do.
Although processes are great for security reasons, their big disadvantage is in the area of performance.
Often, a number of processes will actually be working together, and therefore need to communicate with
each other. The obvious example of this is where a process calls up a COM component, which is an exe-
cutable, and therefore is required to run in its own process. The same thing happens in COM when sur-
rogates are used. Because processes cannot share any memory, a complex marshaling process has to be
used to copy data between the processes. This results in a very significant performance hit. If you need
components to work together and don’t want that performance hit, then you have to use DLL-based
components and have everything running in the same address space— with the associated risk that a
badly behaved component will bring everything else down.
Application domains are designed as a way of separating components without resulting in the performance
problems associated with passing data between processes. The idea is that any one process is divided into
a number of application domains. Each application domain roughly corresponds to a single application,
and each thread of execution will be running in a particular application domain (see Figure 1-3).
Physical memory
or disk space
PROCESS 1
4GB virtual
memory
Physical
Memory
Physical memory
or disk space
PROCESS 2
4GB virtual
memory
15
.NET Architecture
05_575341 ch01.qxd 10/4/05 7:03 PM Page 15