Joining Components to the OS
The PAL contains important lessons for students of high-level abstractions such as the CLI. Structure and behavior represented as CLI types must eventually become code that runs within the boundaries imposed by the APIs of some operating system. This code must accommodate the processor instruction set and device drivers of the system unequivocally; there is no give-and-take. Because of this, the options presented by an operating system API profoundly affect all abstractions built above them, including virtualized execution.
One could imagine the opposite also being true: the CLI’s integration model could be so valuable that it could affect the capabilities and abstractions of underlying operating systems. Boundaries that enhance the safety of collaboration, such as those that accompany the concepts of component, of application domain, of typesafe code, of automatic memory management, and of generalized chained protection frames, characterize the CLI integration model. One of the main purposes of operating systems is to enable the integration of code from many sources with concepts such as device drivers, applications, and system libraries—so the design of OS boundary abstractions is also very important.
There is currently overlap between the mechanisms invented to support CLI components and those that support operating systems, such as the use of threads and structured exceptions, but this overlap is surprisingly small. The successful joining of component-based ...