$WW,1$$FG,5$$TX+CX,"Mysteries"$$FG$

* TempleOS runs in $FG,2$VGA 640x480 16 color$FG$ graphics mode, not text mode.  It changes to this mode with a $LK,"BIOS call",A="FF:::/Kernel/KStart.CPP,INT 0x10"$ while in real-mode before it switches to 64-bit mode.  The text is $LK,"drawn manually",A="MN:GrUpdateTextFG"$.  If graphics mode fails, it falls-back on text mode.  You can force text mode with an $LK,"Kernel config",A="FI:::/Kernel/KCfg.CPP"$ option.

* TempleOS identity-maps all memory, all the time.  There is no $FG,2$high half$FG$ memory space.  TempleOS is ring-0-only, so everything is kernel, even user programs.  There is a special task called $FG,2$Adam$FG$ and he doesn't die, so his heap never gets freed.  That's as close to $FG,2$kernel memory$FG$ as it gets.

* TempleOS puts all code in the lowest 2 Gig, so that $FG,2$REL32$FG$ addressing can be used.  TempleOS is 64-bit, but I just thought $FG,2$2 Gig$FG$ was enough for code.  It actually puts global variables there, too, but you can turn that off with $LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$.  $LK,"MAlloc",A="MN:MAlloc"$() can allocate any memory, of course.

* TempleOS doesn't use software interrupts or $FG,2$SYSCALL$FG$ instructions because it never needs to change out of ring-0, even running user programs.  Calls are always $FG,2$CALL REL32$FG$ instructions.

* The stack does not grow.  In theory, memory gets fragmented, too.

* There is no $FG,2$PATH$FG$.  You do not enter filenames at the command-line and expect them to run.  You enter C-like code.  $LK,"Get Started Here",A="FI:::/Doc/CmdLineOverview.TXT"$.

* If you use $LK,"Grub",A="FI:::/Doc/Grub.TXT"$, you $FG,2$chain-load$FG$ like Windows.  You can use the TempleOS boot-loader.  $LK,"Master-Boot-Loader-Stage1",A="FI:::/Adam/Boot/BootMHD.CPP"$, $LK,"Master-Boot-Loader-Stage2",A="FI:::/Adam/Boot/BootMHD2.CPP"$, $LK,"Partition-Boot-Loader",A="FI:::/Adam/Boot/BootHD.CPP"$, $LK,"CD-DVD-Boot-Loader",A="FI:::/Adam/Boot/BootCD.CPP"$.

* The boot-loaders must be patched by you running $LK,"MakeOSPrtBootInstall",A="MN:MakeOSPrtBootInstall"$() or $LK,"MasterBootIntall",A="MN:MasterBootIntall"$().  Those will write the block address into the boot-loader because the boot-loaders do not navigate file systems to find the $LK,"Stage2",A="FI:::/Kernel/KStart.CPP"$ if you relocate it.

* TempleOS is 64-bit.  Like all PC operating systems, the boot-loader starts in 16-bit real-mode.  TempleOS calls a few $FG,2$BIOS$FG$ info routines, switches to VGA-640x480x4bit, switches to 32-bit, then, 64-bit mode.  There is an odd thing called a $FG,2$$TX,"PCI BIOS",HTML="http://www.o3one.org/hwdocs/bios_doc/pci_bios_21.pdf"$$FG$ which is 32-bit used for $FG,2$PCI$FG$ config space access.  TempleOS calls $LK,"that",A="FI:::/Kernel/BIOS32.CPP"$ a couple times.  It must temporarily drop-out-of 64-bit mode for that and stop multi-tasking.

* $FG,2$PUSH EAX$FG$ : All stack operations in 64-bit mode are 64-bits.

* $FG,2$XOR EAX,EAX$FG$ : Operations on 32-bit regs clear the high 32-bits.

* $FG,2$MOV RAX,FS:[RAX]$FG$ : FS can be set with a $FG,2$WRMSR$FG$, but displacement is RIP relative, so it's tricky to use.  FS is used for the current $LK,"CTask",A="MN:CTask"$, GS for $LK,"CCPU",A="MN:CCPU"$.

* TempleOS uses $FG,2$JIT$FG$ file compression on a file-by-file basis.  Files are $LK,"compressed",A="FI:::/Kernel/Compress.CPP"$, not encrypted.

* TempleOS has a dictionary that is shipped compressed.  When you boot the first time it is uncompressed.  TempleOS has a Windows utility for uncompressing.  That utility needs $FG,2$Microsoft DLL$FG$ files.  TempleOS does not use any libraries, modules or code from other sources -- I wrote it all from scratch and it is self-contained.

* There are no OBJ or EXE files.  There are only two files compiled ahead-of-time -- $FG,2$Kernel.BIN.C$FG$ and $FG,2$Compiler.BIN.Z$FG$.  You can delete them and recompile with $LK,"MakeOSPrtBootInstall",A="MN:MakeOSPrtBootInstall"$().  TempleOS is $TX,"120,723",D="DD_TEMPLEOS_LOC"$ lines.  Roughly 50,000 is compiled AOT and 50,000 during boot $FG,2$JIT$FG$.  The rest is $FG,2$JIT$FG$ demos and applications.

* A major difference between TempleOS and other systems is that the heap and compiler sym table are associated with tasks, not applications.

* There are sym(hash) tables maintained by each task.  They are similar in scope to environment variables.  When a symbol is not found, the parent task's symbol table is checked.  All process chain back to the $FG,2$Adam$FG$ process.  $FG,2$Adam$FG$ has the symbols from headers you normally $FG,2$#include$FG$ in other operating systems, so you do not need to $FG,2$#include$FG$ any headers in TempleOS.

* The compiler only creates $FG,2$pos independent$FG$ code.  You can't create code which is loaded at a fixed, specified location.  The code is pos independent by virtue of the fact that abs addresses get patched.

* Binary executable files have export syms which are loaded into the sym tables.  The operating system $FG,2$Kernel$FG$ has such an export table.  In addition, some map files are processed to provide more information on syms -- src file links.  This is how the $LK,"Man",A="MN:Man"$()/$FG,2$WORDSTAT$FG$ feature can find src lines.

* $FG,2$#assert$FG$ might print a message at COMPILE time, not run time.

* The word $FG,2$public$FG$ does very little except allow the $LK,"Help & Index",A="FI:::/Doc/HelpIndex.TXT"$ and $LK,"Who",A="MN:Who"$() to exclude meaningless syms.  If you wish a full report of public and nonpublic syms $MA-X+PU,"Click Here",LM="DocMax(1000000);Who;View;\n"$.

* When compilation takes place, the structures used by the compiler stick around.  Data on classes can be accessed by code.  See $LK,"ClassRep",A="MN:ClassRep"$().

* Filenames ending in $FG,2$.Z$FG$ are automatically compressed and uncompressed when writing to disk.  File size in directory listing is the compressed size.  See $LK,"::/Doc/TSZ.TXT"$ for uncompressing from $FG,2$WINDOWS$FG$.

* Some memory objects are allocated when needed and will decrease the available memory displayed.  A task keeps mem objects smaller than a couple blocks in it's own separate heap when freed and these are not counted in the available system free memory, though they are free.  They get returned to the system when the task is killed.  To get a sense of this, compile the operating system and see the amount of mem used.  Then, compile it again and far less will be allocated.  This is because it is reusing the small chunks.  See $LK,"Memory Overview",A="FI:::/Doc/MemOverview.TXT"$ and $LK,"Memory Routines",A="HI:Memory"$.  $MA-X+PU,"Click Here",LM="MemRep;View;"$ for a $LK,"MemRep",A="MN:MemRep"$.

* The cursor location is stored as an $FG,2$ASCII 5$FG$ in files.  $FG,2$ASCII 31$FG$ is $FG,2$SHIFT-SPACE$FG$, a character which does not get converted to tabs by space-to-tabs, $LK,"S2T",A="MN:S2T"$().  The $FG,2$ASCII 28$FG$ is $FG,2$SHIFT-ESC$FG$. 

* Binary data is stored beyond the terminating $FG,2$NULL$FG$ in text files.  Map files store debug src lines and other files store sprites.

* Sprites can be stored as vector graphics so they might take shockingly little room.  They can be converted to bitmaps.

* If you change code in the $FG,2$/Adam$FG$, $FG,2$/Adam$FG$ or your $FG,2$HOME$FG$ directory, you don't need to recompile, you just need to reboot because those directories get recompiled when you boot.  It uses JIT compilation.  There is no $FG,2$.BIN$FG$ file for $FG,2$JIT$FG$ compilation.

* If not found, $FG,2$.Z$FG$ is added or removed and a search is done again.  If a file is still not found, the parent directories are searched for a file of the same name.

* TempleOS supports $FG,2$FAT32$FG$ and $LK,"RedSea",A="FI:::/Doc/RedSea.TXT"$ file systems.  The $LK,"RedSea",A="FI:::/Doc/RedSea.TXT"$ partitions will appear as $FG,2$FAT32$FG$ to other operating systems, but will not work.  Do not access the native TempleOS partitions from other operating systems.  This was to fool a bootloader when I tricked it to use it's recovery partition feature.

* The CPU usage during disk operation expands to 99%.  It polls while swapping-out.  You can do other, non-disk activity during disk operations because it swaps-out a lot and task swaps take only half a microsecond, probably a hundred times faster than a typical OS.  See $LK,"Cooperative Multitasking",A="FI:::/Demo/Lectures/Spinning.CPP"$.  It does not break-up disk operations into small pieces for sharing, however, so the disk is lock onto that one task.

$FG,8$
* "Windows" is a trademark of MicroSoft Corp.
$FG$