The goal of this strategy is to increase the level of abstraction available for programming such an operating system. The programs can then be based on abstractions of the object model, even if these are not yet completely implemented.
The objects that implement the operating system services and those objects that use these features are implemented in the same object model. The interfaces are therefore compatible. Given sufficient rights it is possible that every application object interacts with any OS service object. Obviously, the application has to have some sort of reference to the operating system objects. Similar mechanisms for an object-oriented interaction between the operating system and applications can be found in Choices (Univ. of Illinois).
Since the operating system is not a monolithic block with a fixed interface, an application can build operating system mechanisms on top of existing abstractions. This is done by implementing objects that implement operating system functionality for other objects by communicating with operating system objects. This creates relationships at the implementation level, beyond the normal client/server relationship of caller and callee. This corresponds to the object/meta- object relationship in Apertos.
Already we have designs for different parts of the system, like the object storage, the scheduling architecture or support for progressive computation. Other parts are still at work - e. g. handling of multimedia datastreams in an object oriented system.
Virtual address spaces are called object spaces. Objects can be mapped into several object spaces. Objects from the operating systems can be placed in the application object space, and application objects can be mapped into an operating system object space providing supervisor state. Method calls across object borders are more expensive than local method calls. However, since the association of objects to object spaces is very flexible, the costs can be reduced to a minimum by an appropriate placement of the objects [Kle93].
The user can define and instantiate own schedulers as needed and replace system-predefined schedulers inside his application to achieve an optimal environment for it. [KlR94].
Scheduling is by now a rather well-understood area, and concepts exist that provide the necessary scheduling capabilities required for multimedia processing. In particular the PM hierarchical scheduling concepts are worth being mentioned here.
The most interesting aspects of processing multimedia data streams within DOOS are the transportation and synchronization issues:
PM introduces the chunk/reification mechanism: multimedia data is copied only once into a memory region, the chunk. A stream of multimedia data (e.g. video frames) results in a stream of multimedia chunks which are then mapped into object spaces where multimedia objects are created from the chunks through reification. Thus, the multimedia data stream turns into a multimedia object stream.