                            Decisions Making TempleOS Simple

    Everybody is obsessed, Jedi mind-tricked, by the notion that when you scale-up,
    it doesn't get bad, it gets worse.  They automatically think things are going to
    get bigger.  Guess what happens when you scale down?  It doesn't get good, it
    gets better!

    I limited it to 100,000 lines of code, forever!  I never need a linker or make
    utility and I can use small labels.

    People mock Bill Gates for, "640K should be enough."  I say, "2Gig for code
    should be enough."  The same people who mock Bill Gates are probably just like
    the black woman who sued for a trillion dollars.

    My Dad worked on converting the Titan missile to the Gemini Mission rocket.  It
    had to be "man-rated".  You can bet that everything got an order of magnitude
    more complexity and documentation.  My vision is a souped-up C64, not a 1970's
    mainframe; a kayak, not a Titanic.

    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.

    TempleOS 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.  TempleOS 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.  A benefit is this allows compression.  Also, TempleOS does
    not do networking or multimedia.  In theory, memory will fragment with lots of
    big files.  The system would fall to pieces with multimedia, but God said
    640x480 16 color is a permanent covenant like circumcision.

    A three bttn mouse is like a leg you cannot put weight on.  TempleOS 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 equ to
    physical, just as though paging is not used.

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

    * No security or cryptography.

    * No networking.

    * Least (greatest) common denominator hardware support.  Mostly, one driver for
    each device class.  I 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.

    * 640x480 16 colors.  Updates whole scrn at 30 fps, optimized for full scrn
    games where InvalidRectangles are counter-productive.

    * One font, 8x8.  Text and graphic layers done in software with text normally on
    an 8x8 grid.  It can run in Text mode if graphic initialization fails.

    * 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, allowing compression.

    * 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.  Bttns 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 sym table.  Scope is that of environment vars in
    other operating systems.  As text is typed at the command line or you run
    programs by #includeing them, the syms go in the table.  If a sym is not found,
    the parent task's table is checked.  The father of all tasks has the API syms
    you'll need waiting in it's table.  No need to #include headers.

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

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