$WW,1$$FG,5$$TX+CX,"Clearing-up Confusions"$$FG$ * I, $FG,2$Terry A. Davis$FG$, wrote every one of the $TX,"121,847",D="DD_TEMPLEOS_LOC"$ lines of TempleOS over the past $TX,"10.9",D="DD_TEMPLEOS_AGE"$ years (full-time). It runs on bare hardware with no layering, libraries, tools, modules or anything from other sources. It's 100% independent and stands alone. It has no networking and certainly doesn't call home. Every line of TempleOS src code is including in all distro's, from the kernel to the compiler to the boot loaders. * TempleOS does not execute code not written by me and any time except for a few $FG,2$BIOS$FG$ calls for configuration. * TempleOS is 100% independent -- it does not access the files of your primary operating system. It will work as the only operating system on your computer. * TempleOS is 100% written from scratch. There is no $FG,2$Linux$FG$ or $FG,2$GNU$FG$ or any other code in TempleOS. Yes, I wrote the compiler from scratch. (I probably need to repeat that a few times.) * TempleOS is an operating system, not a browser. The cmd line has active links. They link to local files. * TempleOS compiles, not $FG,2$interprets$FG$, and uses no $FG,2$byte code$FG$ anywhere. I use the word $FG,2$script$FG$ sometimes for stuff, but it's actually compiled. * I am an evolutionist. $FG,2$Adam$FG$ is a better term for the father of all tasks than $FG,2$root$FG$ was! * $LK,"Bt",A="MN:Bt"$() is $FG,2$bit test$FG$, like the $FG,2$x86$FG$ instruction, not $FG,2$bit torrent$FG$. * $LK,"Fs",A="MN:Fs"$ is a segment reg, not $FG,2$file system$FG$. (It is kept pointing to the current task's record.) There is no memory segmentation -- FS and GS are used as general purpose regs, more or less. * TempleOS uses a dialect of C/C++ called $LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$. It is not $FG,2$PASCAL$FG$. I altered the syntax making parenthesis optional on function calls with no paramaters. * $LK,"Sleep",A="MN:Sleep"$() makes a program pause. It is not hybernation for a laptop. * $LK,"Yield",A="MN:Yield"$() saves the current task's regs (context) and loads in the next task. When waiting, it's better to do this than check a condition in a loop until you get preempted. Checking a condition until you get preempted wastes CPU. TempleOS does not use virtual memory, so $LK,"Yield",A="MN:Yield"$() involves no disk activity. A swap takes half a microsecond. See $LK,"::/Demo/Lectures/Spinning.CPP"$. * I use the term $LK,"JIT Compile Mode",A="FF:::/Doc/Glossary.TXT,JIT Compile Mode"$. This means it is compiled and executable code placed into mem, ready to be called. * Files with names ending in $FG,2$.Z$FG$ are compressed, not encrypted. $LK,"Copy",A="MN:Copy"$() or rename them with $LK,"Move",A="MN:Move"$() to store them uncompressed. * TempleOS is open src and every bit of the src code is included in the distro. Use $LK,"MakeOSPrtBootInstall",A="MN:MakeOSPrtBootInstall"$() to compile the kernel and compiler. * TempleOS does not use object files or a linker. * The swap rate is high because tasks stay in the queue and poll conditions and swap-out voluntarily. Swaps also occur at $FG,2$$TX,"1000 Hz",D="DD_JIFFY_HZ"$$FG$ due to the timer interrupt. See $LK,"JIFFY_FREQ",A="MN:JIFFY_FREQ"$. * Refresh rate is how often TempleOS updates screen mem. It is not syncronized to the hardware rate. It has nothing to do with it. * No application has a lock on the speaker so apps can interfere with each other and TempleOS makes speaker noise during disk access on purpose. * During boot, TempleOS reads-in all text files and collects statistic on them. It makes a sparse matrix containing the frequency each word was followed by each other word. This makes it able to predict the next word while you type. This feature is called $FG,2$WordStat$FG$. * There are no mem leaks. TempleOS allocates mem as more items are displayed on the screen. TempleOS allocates mem for code as it is compiled at the cmd line. If you $FG,2$#include$FG$ a file twice, it allocates more mem for it. If you have a 50,000 line program with each line taking twenty bytes on a machine with 1 Gig, you could $FG,2$#include$FG$ it a thousand times if it had no data or graphics and no other use of mem. Code entered at the cmd line gets allocated and persists. I don't want to hear any bullshit about leaks unless you actually run-out. If it bothers you, hit $FG,2$$FG$ and $FG,2$, $FG$periodically$FG$. Use the pop-up flag on macros in your menu to spawn new tasks, run applications and free the applications when they are finished and everything will be fine. Small mem chunks stick to the task when they are freed until it is killed. The only way to get in trouble involves allocating multiple Meg chunks and freeing them. These can only be reused if the same size gets allocated again. Use $LK,"HeapLog",A="MN:HeapLog"$() and $LK,"HeapLogRep",A="MN:HeapLogRep"$() to see who allocated mem and didn't free it. * The editor periodically takes a snap-shot for $FG,2$UNDO$FG$ and this looks like a memory leak. $FG,8$ * "Linux" is probably a trademark owned by Linus Torvalds. $FG$