Decisions Making ZealOS Simple

Linux is a semi-tractor -- you need professional drivers for 20 gears.  Linux has file permissions.  Common people are hurt by 
file permissions.

Windows is a car.

ZealOS is a motorcycle -- if you lean-over too far, a motorcycle will crash.    Don't do that!  There are no side air bags on 
a motorcycle.  DOS and C64 had no memory protections and ran in ring-0, with no security.  This saves an order of magnitude 
complexity.

Linux and Windows are general purpose operating systems.    They attempt to do any task you want.  ZealOS cherry-picks tasks 
and is designed to do the same things a C64 did.  This saves and order of magnitude complexity. For example, the RedSea file 
system allocates just contiguous files -- you load and save whole files at once.  Also, ZealOS does not do multimedia.  In 
theory, memory will fragment with lots of big files.    The system would fall to pieces with multimedia.

A three button mouse is like a leg you cannot put weight on.    ZealOS just does hardware everybody has, with no divergent 
code bases for each machine's custom hardware.  There is one graphics driver instead of 50 for different GPUs.  This saves an 
order of magnitude complexity and makes for a delightful API, so developer's code is not like a frayed rope end.



* Everything runs in kernel, ring 0, mode.

* One memory map for all tasks on all cores with virtual addresses set equal to physical, just as though paging is not used.

* One platform -- x86_64 PC's, no 32-bit support.

* No security or cryptography.

* Least (greatest) common denominator hardware support.  Mostly, one driver for each device class.  We can't be in the 
business of different drivers.  Compatibility is the greatest challenge for PC operating systems.  Disk code does not use 
interrupts, avoiding compatibility risks.  PS/2 keyboard/mouse is used instead of USB, also more compatible.

* Updates whole screen at 60 fps, optimized for full screen games where InvalidRectangles are counter-productive.

* One font, 8x8. Text and graphic layers done in software with text normally on an 8x8 grid.

* Compiler extends all values to 64-bit when fetched and does only 64-bit computations intermediately.  Assembler has minimal 
16-bit support, good enough for compiling boot loaders.

* No object files.  Use JIT.

* Whole files are processed almost exclusively.

* One language and compiler for command-line, scripts, songs, automations and code.

* One editor/word processor/browser for the command-line window, source code, documentation browser, dialog forms.

* No child windows.  One window per task.  Buttons are widgets, not child windows.  There are child tasks, however.

* No distinction between thread, process or task.

* The Scheduler is for home systems.  It is not preemptiove.  Disk requests are not broken-up, so sharing is bad.   It's 
wonderfully simple.

* MultiCore is done master/slave, instead of SMP.  Core0 applications explicitly assigns jobs.  Locks are present allowing 
multicore file, heap, and hardware access, though.

* Sound has single-voice 8-bit signed MIDI-like samples.

* All tasks have a heap and a symbol table. Scope is that of environment variables in other operating systems.  As text is 
typed at the command line or you run programs by #includeing them, the symbols go in the table. If a symbol is not found, the 
parent task's table is checked. The father of all tasks has the API symbols you'll need waiting in it's table.  No need to #in
clude headers.

* No need for namespaces -- scoping occurs automatically based on task symbol table hierarchy with the System Task's symbol 
system-wide global.

* Sometimes, we cut corners in the interest of keeping the code beautiful.