• Each library sub task consists of a number of software parts and appended libraries. Each library behaves much like a C++ class. Specifically:
    • There are private, public, and utility software parts with well defined arguments and an optional return.
    • Public parts can only be invoked by the immediate library client.
    • Private parts can only be invoked by other parts in the library.
    • Utility software parts provides an invoking capability between the appended library.
    • No Software Part can invoke a software part in client of the library.
    • All data defined within the library is private to the software parts in the library.
  • Multiple user stacks provide comprehensive error detection capabilities relative to the use of software parts libraries. Specifically:
    • Any number of named user stacks can be defined.
    • One named stack can be assigned to each part.
    • The stack operations required for simple precedence are defined for each named user stack.
    • The resultant combination of stacks can manage all aspects of the use of a library and its appended libraries.
  • The “Post Office” Instruction set provides a means of communicating data from one source definition sub-task to a subsequent one.
    • This instruction set permits critical data to be defined exclusively in one source sub-task prior to its use in subsequent source sub-tasks.
    • It can be used to replace the #define statements used in C and C++ language.
    • It can implement the restrictions of a class in the C language. This includes the associated global data.
  • All data storage resources including the Post Office are strictly compliant with the principles of “Memory Cycling”
    • A storage resource must be empty before it can be loaded with data.
    • A storage resource can be formally emptied by a software parts command.
    • To update data in a storage resource, it must first be emptied.
    • A empty storage resource cannot be read (prevents “use after free” vulnerabilities)