Before going through the sections of the PAL that support the subsystems already discussed in this book, two areas need to be explored that are important plumbing details but not directly seen by PAL consumers: shared memory and the handle manager . Remember that although the PAL is represented by an API, the API has code behind it that manages operating system resources on behalf of the programmer. In the case of the Unix PAL, the visibility of Windows resources is very different than the visibility of resources within the Unix process hierarchy. To implement the looser Windows semantics, shared memory is used by the Unix PAL to make data available to any Unix process that is using the services of the CLI execution engine. A set of one or more processes that share a shared memory segment in the Unix PAL are referred to collectively as a PAL process group .
The term “process group” can be confusing, since a process group does not always need to consist of multiple Unix processes. In fact, it is normal for a single Rotor PAL process to live within a single Unix process. Even when this is the case, we will refer to this singleton process as a process group in an effort to differentiate PAL processes, Unix processes, and shared process groups .
Many of the Win32 resources within a PAL process group are represented to programmers using opaque handles. Handles are used as parameters to the calls that manipulate them, such as