Original Creation Date: November 28th, 1998
Last Revision Date: December 9th, 1998

Premise:  A secure multi-user multi-threaded object oriented OS based on the hardware abstract system.

Diagram Flow Explanation:  The diagram starts from the top, with the multiple users interacting with objects (applications). Each user can interact with a single or multiple shared objects. Each object can interact with public methods, properties, or events of other objects. All objects must pass hardware calls through a watcher/observer, and a security object.  Then, providing the security is ok, the process is passed to the hardware abstract objects which talk directly to the hardware.  The kernel handles object life and interaction in memory.

How it works: The system starts by loading the kernel, and putting the hardware abstract objects, security, and watcher objects in memory. A default user identification program (text or GUI) is then loaded and waits for a user log in. User's log into the system (automatically if single user mode), and the system loads a customized user profile.  Each user has a default system interaction object (text terminal, or GUI), which loads based on their user profile. Objects that have only events (code that works when it sees an event from the watcher object) can also be loaded at startup also. The UI can start the MAIN method of any other object (which has one), this is how applications are loaded.  Once loaded, objects/applications can access hardware abstract object methods to do its I/O.  Processing is done native to the processor, but the object must request memory and processing time/scheduling.  The security model determines when, and if an object can access a piece of hardware. Objects (including hardware abstracts) pass all information through the watcher object which can be used for diagnostic purposes, event driven scripting/programming, or even AI intervention/interaction modules. The system, when the user is done, can be shut down or saved into an image, and the image is saved to the user profile.  When the same user logs into the system, their system will be restored into the same state as when they left.  When multiple users are logged in, any objects being used, can be shared among users (methods only, not state, events or properties), to avoid wasting memory. In essence, object methods are loaded once, and object data is loaded for each process/user. The system will control memory management tasks such as object instantiation and cleanup when not used.  Each object contains it's own code (compressed hopefully), and binary executable (when executed once). This allows for cross platform portability.  The object would contain the architecture and abstracts it was compiled for, and if they do not match up, would re-compile to fit the machine. Users can also force a recompile on any object at any time.  Applications would be distributed in code form and not contain any binary code for security reasons.