$WW,1$$FG,5$$TX+CX,"Strategic Decisions Making"$
$TX+CX,"TempleOS Simple"$
$FG$
The $FG,2$$TX,"trivial solution",HTML="http://en.wikipedia.org/wiki/Trivial_solution"$$FG$ in math is the simple, obvious answer.  TempleOS has many examples of using trivial solutions.

* Everything runs in kernel, $FG,2$ring 0$FG$, mode.

* $FG,2$One memory map$FG$ for all tasks on all cores with virtual addresses set equal to physical.

* One platform -- $FG,4$$TX,"x86_64",HTML="http://en.wikipedia.org/wiki/Amd64#AMD64"$$FG$ PC's, no 32-bit support.

* No security.

* 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.  $FG,2$PS/2$FG$ keyboard/mouse is used instead of $FG,2$USB$FG$, also more compatible.

* $FG,2$640x480$FG$ 16 colors.  Updates whole screen at $FG,2$60 fps$FG$, optimized for full screen games where $FG,2$InvalidRectangle$FG$s 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 $FG,2$JIT$FG$.

* 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.  Buttons are widgets, not child windows.  There are child tasks, however.

* No distinction between $FG,2$thread$FG$, $FG,2$process$FG$ or $FG,2$task$FG$.

* The $LK,"Scheduler",A="FI:::/Kernel/Sched.CPP"$ is mostly for home systems, not servers or mainframes.  The focus task is all important.  Disk requests are not broken-up, so sharing is bad, however.

* $LK,"MultiCore",A="FI:::/Doc/MultiCore.TXT"$ is done $FG,2$master/slave$FG$, instead of $FG,2$SMP$FG$.  Core zero explicitly assigns jobs.  Locks are present allowing multicore file, heap, and hardware access, though.

* $LK,"Music",A="MN:Play"$ is done with an elegant one-voice notation.

* 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 $FG,2$#include$FG$ing 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 $FG,2$#include$FG$ headers.

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

* Sometimes, I $LK,"cut corners",A="FI:::/Doc/CutCorners.TXT"$ in the interest of keeping the code beautiful.