The key to the UniOS system, will be abstracted hardware.  This mean that instead of programming the hardware directly, you program a simplified object that represents the hardware itself.  This method produces slightly slower programs, but allows program code to be portable. Hardware abstracts, are absolutely necessary to maintaining hardware independence.  A good example of a system with hardware abstracts is Java.  Java uses a set of classes that abstract the physical hardware. When this technique is done right, it can provide total platform independence. 

Hardware abstracts are objects and fall into two categories:
1) High Level - Platform independent, and universal to all UniOS implementations
2) Low Level - System level drivers

High level abstracts map directly to low level functions.  This means that if you have a common function in the High level, how it would be exectuted would be dependent on the low level, as the low level contains all the necessary code.  The reason for having two layers, is to allow for universal functions across all UniOS implementation, while still allowing specialized programs to access hardware functions we have not made universal  through the  low level abstract.  For example, if a hardware developer was implementing new features into a video card, he/she could write these functions into the low level driver, and could take advantage of them through an application, via the low level driver.  We always will recommend using the high level generic abstracts, but we know it is a necessity to not limit programmers to them. If a function is important enough, it will be added into the next standardized release of the particular hardware abstract object.

Proposed High Level Abstracts Objects By Category:

1) System
- SYSTEM - Used for system status and configuration
- CPU - Used for compiling to native code on application install
- TASK - Used to multitask system
- MEMORY MANAGER - Manages memory resources
- TIME - Timing related I/O for events and observing
- USER - User configuration and information
2) Storage 
- FIXED - Hard drives, or otherwise non removable storage methods
- REMOVABLE - Disks, of any size, shape, capacity, and read/write ability
- LINEAR - Linear storage devices such as tapes.
- REMOTE - Any storage device where the availability may be in question
3) Network 
- LAN - Methods for communicating local
- WAN - Methods for communication with remote (difference in procedures)
4) Stream (Text)
- SERIAL - I/O from a video display, modem, printer, USB, or dumb terminal device
- PARALLEL - I/O from printer or specialized I/O channels
5) Graphical 
- 2D - Graphical Bit mapped or Vector 2D I/O for mice, scanners, 2D video cards
- 3D - Graphical Bit mapped or Vector 3D I/O for video cards
6) Sound 
- SEQUENCED - MIDI type I/O
- VOICE - PCM related I/O

Each abstract can map to multiple low level devices (multiple hard drives under fixed storage), with a definable default. An object (application) would be programmed generically for the abstract with the methods contained within the abstract object. Specific implementations of protocols and API's, such as TCP/IP or OpenGL would be built on top of the abstracts, as interfaceable objects.

This (like all other document ;), is only a suggestion. It may be better to have a different set of abstracts to allow for better flexibility or portability.