Because we expect to support a wide variety of different policies for scheduling, paging, etc. the idea of a common, ubiquitous runtime is not applicable in the operating system. Thus there is a problem of how to create objects and interfaces at the start of day--for example we can't do the equivalent of C++ new since there is no notion of where the heap state is.
Interfaces which are inherently stateless present no problem: a
closure with a null state pointer can already be executed in any
domain. Thus further objects can be created by explicitly passing in closures
which implement the functions normally provided by a runtime system,
with greater control over the resource tradeoffs used (such as
designating a heap to allocate storage from). A typical
object constructor takes a set of interfaces as arguments (possibly with
some additional parameters) and returns all the interfaces exported by
the new object. The idiom has proved so useful that we are considering
giving it language-level syntax. Most modules are built with only one
externally
visible symbol, namely the closure for a constructing objects of the
class that the module implements (see figure 
). The
address of this
interface is registered with a Nemesis name service when the
module is loaded into the system.
Figure: A module implementing an object with two interfaces
Starting up an application domain requires some initial state to be setup, though in practice surprisingly little is required. Domains are started by a Nemesis service called the Domain Manager, which instantiates an initial set of interfaces. These include a memory protection domain to run the application in, a basic memory allocation heap and communication channels to a name server and the inter-domain communication binder.
These interfaces encapsulate all the mutable state required by an application when it starts up, and are passed as parameters to the domain entry point. This is a stateless closure within a module which then instantiates the rest of a domain's paraphernalia (scheduler, language run-time, application-specific state, etc.).