139 lines
9.2 KiB
HTML
Executable File
139 lines
9.2 KiB
HTML
Executable File
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="UTF-8">
|
|
<meta name="generator" content="TempleOS V5.03">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<link rel="stylesheet" href="/style/templeos.css">
|
|
<script src="/script/templeos.js"></script>
|
|
<style type="text/css">
|
|
.cF0{color:#000000;background-color:#ffffff;}
|
|
.cF1{color:#0000aa;background-color:#ffffff;}
|
|
.cF2{color:#00aa00;background-color:#ffffff;}
|
|
.cF3{color:#00aaaa;background-color:#ffffff;}
|
|
.cF4{color:#aa0000;background-color:#ffffff;}
|
|
.cF5{color:#aa00aa;background-color:#ffffff;}
|
|
.cF6{color:#aa5500;background-color:#ffffff;}
|
|
.cF7{color:#aaaaaa;background-color:#ffffff;}
|
|
.cF8{color:#555555;background-color:#ffffff;}
|
|
.cF9{color:#5555ff;background-color:#ffffff;}
|
|
.cFA{color:#55ff55;background-color:#ffffff;}
|
|
.cFB{color:#55ffff;background-color:#ffffff;}
|
|
.cFC{color:#ff5555;background-color:#ffffff;}
|
|
.cFD{color:#ff55ff;background-color:#ffffff;}
|
|
.cFE{color:#ffff55;background-color:#ffffff;}
|
|
.cFF{color:#ffffff;background-color:#ffffff;}
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<pre style="font-family: courier, monospace; font-size: 10pt;">
|
|
<a name="l1"></a><span class=cF5> Decisions Making TempleOS Simple
|
|
<a name="l2"></a></span><span class=cF0>
|
|
<a name="l3"></a>Everybody is obsessed, Jedi mind-tricked, by the notion that when you scale-up,
|
|
<a name="l4"></a>it doesn't get bad, it gets worse. They automatically think things are going to
|
|
<a name="l5"></a>get bigger. Guess what happens when you scale down? It doesn't get good, it
|
|
<a name="l6"></a>gets better!
|
|
<a name="l7"></a>
|
|
<a name="l8"></a>I limited it to 100,000 lines of code, forever! I never need a linker or make
|
|
<a name="l9"></a>utility and I can use small labels.
|
|
<a name="l10"></a>
|
|
<a name="l11"></a>People mock Bill Gates for, "640K should be enough." I say, "2Gig for code
|
|
<a name="l12"></a>should be enough." The same people who mock Bill Gates are probably just like
|
|
<a name="l13"></a>the black woman who sued for a trillion dollars.
|
|
<a name="l14"></a>
|
|
<a name="l15"></a>My Dad worked on converting the Titan missile to the Gemini Mission rocket. It
|
|
<a name="l16"></a>had to be "man-rated". You can bet that everything got an order of magnitude
|
|
<a name="l17"></a>more complexity and documentation. My vision is a souped-up C64, not a 1970's
|
|
<a name="l18"></a>mainframe; a kayak, not a Titanic.
|
|
<a name="l19"></a>
|
|
<a name="l20"></a>Linux is a semi-tractor -- you need professional drivers for 20 gears. Linux
|
|
<a name="l21"></a>has file permissions. Common people are hurt by file permissions.
|
|
<a name="l22"></a>
|
|
<a name="l23"></a>Windows is a car.
|
|
<a name="l24"></a>
|
|
<a name="l25"></a>TempleOS is a motorcycle -- if you lean-over too far, a motorcycle will crash.
|
|
<a name="l26"></a>Don't do that! There are no side air bags on a motorcycle. DOS and C64 had no
|
|
<a name="l27"></a>memory protections and ran in ring-0, with no security. This saves an order of
|
|
<a name="l28"></a>magnitude complexity.
|
|
<a name="l29"></a>
|
|
<a name="l30"></a>Linux and Windows are general purpose operating systems. They attempt to do any
|
|
<a name="l31"></a>task you want. TempleOS cherry-picks tasks and is designed to do the same
|
|
<a name="l32"></a>things a C64 did. This saves and order of magnitude complexity. For example,
|
|
<a name="l33"></a>the </span><a href="/Wb/Doc/RedSea.DD.HTML#l1"><span class=cF4>RedSea</span></a><span class=cF0> file system allocates just contiguous files -- you load and save
|
|
<a name="l34"></a>whole files at once. A benefit is this allows compression. Also, TempleOS does
|
|
<a name="l35"></a>not do networking or multimedia. In theory, memory will fragment with lots of
|
|
<a name="l36"></a>big files. The system would fall to pieces with multimedia, but God said
|
|
<a name="l37"></a>640x480 16 color is a permanent covenant like circumcision.
|
|
<a name="l38"></a>
|
|
<a name="l39"></a>A three bttn mouse is like a leg you cannot put weight on. TempleOS just does
|
|
<a name="l40"></a>hardware everybody has, with no divergent code bases for each machine's custom
|
|
<a name="l41"></a>hardware. There is one graphics driver instead of 50 for different GPUs. This
|
|
<a name="l42"></a>saves an order of magnitude complexity and makes for a delightful API, so
|
|
<a name="l43"></a>developer's code is not like a frayed rope end.
|
|
<a name="l44"></a>
|
|
<a name="l45"></a>
|
|
<a name="l46"></a>
|
|
<a name="l47"></a>* Everything runs in kernel, </span><span class=cF2>ring 0</span><span class=cF0>, mode.
|
|
<a name="l48"></a>
|
|
<a name="l49"></a>* </span><span class=cF2>One memory map</span><span class=cF0> for all tasks on all cores with virtual addresses set equ to
|
|
<a name="l50"></a>physical, just as though paging is not used.
|
|
<a name="l51"></a>
|
|
<a name="l52"></a>* One platform -- </span><a href="http://en.wikipedia.org/wiki/Amd64#AMD64"><span class=cF4>x86_64</span></a><span class=cF0> PC's, no 32-bit support.
|
|
<a name="l53"></a>
|
|
<a name="l54"></a>* No security or cryptography.
|
|
<a name="l55"></a>
|
|
<a name="l56"></a>* No networking.
|
|
<a name="l57"></a>
|
|
<a name="l58"></a>* Least (greatest) common denominator hardware support. Mostly, one driver for
|
|
<a name="l59"></a>each device class. I can't be in the business of different drivers.
|
|
<a name="l60"></a>Compatibility is the greatest challenge for PC operating systems. Disk code
|
|
<a name="l61"></a>does not use interrupts, avoiding compatibility risks. </span><span class=cF2>PS/2</span><span class=cF0> keyboard/mouse is
|
|
<a name="l62"></a>used instead of </span><span class=cF2>USB</span><span class=cF0>, also more compatible.
|
|
<a name="l63"></a>
|
|
<a name="l64"></a>* </span><span class=cF2>640x480</span><span class=cF0> 16 colors. Updates whole scrn at </span><span class=cF2>30 fps</span><span class=cF0>, optimized for full scrn
|
|
<a name="l65"></a>games where </span><span class=cF2>InvalidRectangle</span><span class=cF0>s are counter-productive.
|
|
<a name="l66"></a>
|
|
<a name="l67"></a>* One font, 8x8. Text and graphic layers done in software with text normally on
|
|
<a name="l68"></a>an 8x8 grid. It can run in Text mode if graphic initialization fails.
|
|
<a name="l69"></a>
|
|
<a name="l70"></a>* Compiler extends all values to 64-bit when fetched and does only 64-bit
|
|
<a name="l71"></a>computations intermediately. Assembler has minimal 16-bit support, good enough
|
|
<a name="l72"></a>for compiling boot loaders.
|
|
<a name="l73"></a>
|
|
<a name="l74"></a>* No object files. Use </span><span class=cF2>JIT</span><span class=cF0>.
|
|
<a name="l75"></a>
|
|
<a name="l76"></a>* Whole files are processed almost exclusively, allowing compression.
|
|
<a name="l77"></a>
|
|
<a name="l78"></a>* </span><a href="/Wb/Doc/HolyC.DD.HTML#l1"><span class=cF4>One language</span></a><span class=cF0> and compiler for command-line, scripts, songs, automations and
|
|
<a name="l79"></a>code.
|
|
<a name="l80"></a>
|
|
<a name="l81"></a>* One editor/word processor/browser for the command-line window, source code,
|
|
<a name="l82"></a>documentation browser, dialog forms.
|
|
<a name="l83"></a>
|
|
<a name="l84"></a>* No child windows. One window per task. Bttns are widgets, not child windows.
|
|
<a name="l85"></a> There are child tasks, however.
|
|
<a name="l86"></a>
|
|
<a name="l87"></a>* No distinction between </span><span class=cF2>thread</span><span class=cF0>, </span><span class=cF2>process</span><span class=cF0> or </span><span class=cF2>task</span><span class=cF0>.
|
|
<a name="l88"></a>
|
|
<a name="l89"></a>* The </span><a href="/Wb/Kernel/Sched.HC#l1"><span class=cF4>Scheduler</span></a><span class=cF0> is for home systems. It is not preemptiove. Disk requests are
|
|
<a name="l90"></a>not broken-up, so sharing is bad. It's wonderfully simple.
|
|
<a name="l91"></a>
|
|
<a name="l92"></a>* </span><a href="/Wb/Doc/MultiCore.DD.HTML#l1"><span class=cF4>MultiCore</span></a><span class=cF0> is done </span><span class=cF2>master/slave</span><span class=cF0>, instead of </span><span class=cF2>SMP</span><span class=cF0>. </span><span class=cF2>Core0</span><span class=cF0> applications explicitly
|
|
<a name="l93"></a>assigns jobs. Locks are present allowing multicore file, heap, and hardware
|
|
<a name="l94"></a>access, though.
|
|
<a name="l95"></a>
|
|
<a name="l96"></a>* </span><span class=cF4><u>Sound</u></span><span class=cF0> has single-voice 8-bit signed MIDI-like samples.
|
|
<a name="l97"></a>
|
|
<a name="l98"></a>* All tasks have a heap and a sym table. Scope is that of environment vars in
|
|
<a name="l99"></a>other operating systems. As text is typed at the command line or you run
|
|
<a name="l100"></a>programs by </span><span class=cF2>#include</span><span class=cF0>ing them, the syms go in the table. If a sym is not found,
|
|
<a name="l101"></a>the parent task's table is checked. The father of all tasks has the API syms
|
|
<a name="l102"></a>you'll need waiting in it's table. No need to </span><span class=cF2>#include</span><span class=cF0> headers.
|
|
<a name="l103"></a>
|
|
<a name="l104"></a>* No need for namespaces -- scoping occurs automatically based on task symbol
|
|
<a name="l105"></a>table hierarchy with the </span><a href="/Wb/Doc/Glossary.DD.HTML#l171"><span class=cF4>Adam Task</span></a><span class=cF0>'s symbol system-wide global.
|
|
<a name="l106"></a>
|
|
<a name="l107"></a>* Sometimes, I </span><a href="/Wb/Doc/CutCorners.DD.HTML#l1"><span class=cF4>cut corners</span></a><span class=cF0> in the interest of keeping the code beautiful.
|
|
</span></pre></body>
|
|
</html>
|