Like many systems, Nemesis separates the notions of linking and loading: linking is the process of resolving internal references within a chunk of object code, while loading is the business of relocating it and installing it in the address space of a Nemesis system. The model of linking and loading adopted in Nemesis needed to:
The resulting programming model is one of ``objects'' which export multiple interfaces, each of which is identified by an address. Every call across an interface (in effect, any call across a module boundary) must pass the interface address as a closure. Objects per se don't have types; their interfaces do. In this way the notions of type and class are separated: the type of an interface is the set of operations it supports, and the class of an object is its implementation, which depends on the module that implements it. One way to think about modules is as CLU clusters (), except that modules can have no ``own'' variables since they are shared read-only between all domains.
We have found programming in this way is actually quite natural in stylised C or C++, especially with Middl compiler tools to generate the boilerplate. There is also design work under way to produce a language which compiles naturally down to C, but which maps very closely onto our computational model and provides more type safety and compile-time protection than C++ or C.