Portability is a key design goal for Rotor. To achieve portability , all of the code in the distribution is written against an API layer, called the Platform Adaptation Layer (PAL), which hides the differences between underlying operating systems and provides consistent operating semantics. Since Rotor started life as a large Win32 application, it should come as no surprise that the PAL mimics a subset of the Win32 API. Only the subset absolutely required by the SSCLI and its supporting tools is implemented, however, which means that there is does not need to be any support for graphics, most of COM, the Windows registry, Active Directory, or other features commonly used by Windows programmers.
This chapter, rather than act as a comprehensive catalog of the PAL’s nooks and crannies, will instead visit the areas most crucial to understanding the CLI mechanisms described in earlier chapters, since Rotor’s runtime infrastructure heavily depends on the operating systems constructs provided by the PAL. In Chapter 6, for example, the sections “Threads,” “Synchronizing Concurrent Access to Components,” and “Handling Component Exceptions
" referred repeatedly to the PAL’s threading and synchronization model, as well as its structured exception-handling facilities. Chapter 7, in its discussion of “Organizing and Allocating Dynamic Memory
," highlighted the reliance of Rotor’s heaps on virtual memory (and how different uses of virtual memory features ...