Features of EOS

The operating system (tentatively called Eos), will meet the following criteria:

• It will be a 32-bit operating system.

• It will be free to the end-user and developer.

• Full FREE!!! Documentation, software and support.

• It will be developed for the IBM compatible personal computer, with porting to other environments in mind.

• It will consist of a small, fast kernel and loadable modules (dynamic link libraries and device drivers).

• It will be designed with both the applications programmer and the end-user in mind. It will be elegant and easy to use for the consumer and will provide a common Application Programmer's Interface for the developer.

• It will be designed with a high-level API in a modular fashion. This will facilitate porting of the system to other environments and ease the strain on developers.

• It will include services for memory management, input devices, disk devices, CD-ROM devices, networking, sound and graphics. Support for these devices will be loaded by the startup file/system, with only the most crucial device support (hard/floppy disk etc) in the kernel itself.

• Eos will implement multi-threading/multi-tasking. Games/Applications can take advantage of the multi-taskin capabilities or turn it off, in which case they can control all processes themselves. This will provide the flexibility that game developers require. The multi-tasking will be pre-emptive so that important threads of execution can receive immediate attention.

• There will be several (probably two or three) priority levels for applications. Level One applications receive full control of everything but the lowest level (the kernel itself). They may be multi-tasking or single-tasking and may, although it is poor programming practice, access hardware devices directly. Lower level applications are more restricted, and therefore offer better protection. All non-speed critical applications should run as lower level apps, where they can be multi-tasked etc. When a Level One application is started, the lower level apps will be suspended or halted.

• The file system will be able to sit on top of DOS, but will also have a version that can reside in its own partition. Eos will be designed from the start to meet both of these criteria. The native version (with its own partition) will have the benefit of speed, while the DOS version will have the benefit of greater compatibility.

• Eos will use its own executable format, but the linker will be able to accept standard object formats so that developers can use the compilers that they are familiar with. This means that Eos will use its own linker and assembler.

• The system will be object oriented through modularity. Drivers and dynamic link libraries in particular will be implemented in a generic manner so that applications don't have to know the details of a particular driver or dll in order to use it.

• The user will be able to boot directly from the Master Boot Record for a system with its own partition, or be able to load from DOS, for a system using the file-system that sits on top of DOS. When loading from DOS, the loader will need to detect EMS/XMS/VCPI/DPMI set-ups so that it can take appropriate action. EMS and DPMI in particular dislike other system trying to take control of the computer, so a warm-boot may be necessary. Obviously this will be accompanied by a friendly message, and made as easy as possible for the end-user. Windows, OS/2 and dosemu would need to be detected so that the user could be informed that they need to exit to an actual DOS prompt.

• The file system will be an i-node based file system with long(er) file names (probably 32 characters). If it resides on top of DOS it will exist in a single large file in a directory of it's own. It will be a hidden, system, read-only file from DOS's point of view, to reduce the chances of it getting altered. Eos will use its own (fast) routines to access this file. Because of this, Eos will not initially be able to support Compressed disks. To do so would require calls to DOS, which would sacrifice the integrity of the system. Therefore, disk compression must be detected at setup/installation so the user can be informed and asked to choose another disk or form a separate partition.

• An optional disk cache will be implemented. It will be dynamically resizable. It will designed to increase disk performance, particularly on systems where Eos sits on top of a DOS FAT file structure.

• Near calls will be used for calls whenever possible, even system calls. This will provide significant speed benefits.