Managers have a basic set of properties common to all types. But each type has also a specific set. The "methods" can also have parts common to many types and methods specific to a type.

For example objects need constructors. And the part used to create the common properties can be in the kernel of Trakian.

The requirement to be autonomous results in specific methods to be in the code section of this type of Manager. If this methodology is respected, all instances of a type of Manager shall use the same set of methods (=CODE).

Managers can never know at compile time where they shall be at runtime! This is an important restriction resulting from the requirement to be loadable and diseardable.

A side effect is that a modern compiler... can not be used!!! Else to the programmer to use technics to avoid the compiler to do what he not wants. For example in C++ the solution is to define classes for each type and use inline functions. Managers communicate by messages. The kernel has many calls to execute tasks for most of the basic functions (METHODS) and the memory Manager also.

To create a new instance of a Manger a call to the memory Manager shall reserve the space needed and a call to the kernel shall create the instance. This is largely sufficient in many cases. BUT, most Managers shall receive messages. Messages are managed by a procedure. This procedure is similar to, for example, a Window procedure. Such a procedure is called with parameters, FOUR parameters. The first is a long (FAR) pointer defining "WHO" is calling. This parameter corresponding to the "THIS" pointer a C++ compiler inserts automatically. Bur ANSI - C doesn't, so this must be passed in the message.

The second parameter is a short defining the message. The third is a short sufficient to complete many messages.

The last parameter is a long. Thus capable to pass a long value or a pointer to a "structur".