Features of EOS
This is a proposal for a joint effort at creating an
operating system specifically designed for the playing
and development of games and entertainment packages.
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.