$ID,2$I, $FG,2$Terry A. Davis$FG$, wrote all of ZenithOS over the past $TX,"13.8",D="DD_TEMPLEOS_AGE"$ years (full-time). It can run on some bare metal 64-bit PC's from about 2005-2010 with no layering, libraries, tools, modules or anything from other sources. Otherwise, you run it in a virtual machine, like $FG,2$VMware$FG$, $FG,2$QEMU$FG$ or $FG,2$VirtualBox$FG$. It is independent and stands alone. It has no networking, so it certainly doesn't call home. 100% of the src code is including on all distro's, from the kernel to the compiler to the boot loaders! See $LK,"::/Doc/Credits.DD"$.
$ID,2$ZenithOS executes no code not written by me at any time except for a few $FG,2$BIOS$FG$ calls for configuration. I even wrote boot-loaders, so I do not need Grub. See $LK,"::/Doc/Credits.DD"$.
$ID,2$ZenithOS was written from scratch, starting with $FG,2$TASM$FG$ long ago, launching from real-mode DOS. Now, there is no $FG,2$Linux$FG$ or $FG,2$GNU$FG$ or any other code in ZenithOS. Yes, I wrote the compiler from scratch. See $LK,"::/Doc/Credits.DD"$.
$ID,2$ZenithOS is 100% independent -- it does not access the files of your primary operating system and ZenithOS will work as the only operating system on your computer, but it has no networking. In your off hours, you will use your other operating system.
$ID,2$ZenithOS is an operating system, not a browser. $LK,"ZenithOS links",A="MN:LK_FILE"$ are a special format and only link too local files and symbol source addresses.
$ID,2$3D $LK,"Sprites",A="FI:::/Doc/Sprite.DD"$ are stored as a mesh of triangles. There are no GIF files. It $LK,"rotates",A="MN:Mat4x4MulXYZ"$ 3D sprite objects on the fly.
$ID,2$ZenithOS compiles, doesn't $FG,2$interpret$FG$, and uses no $FG,2$byte code$FG$ anywhere. I loosely use the word $FG,2$script$FG$ sometimes, but it's actually compiled. The compiler's $LK,"optimization",A="MN:OptPass012"$ code is actually where the compiler evaluates constants to simplify them, like every optimizing compiler.
$ID,2$$LK,"Fs",A="MN:Fs"$ is a segment reg, not $FG,2$file system$FG$. ($LK,"Fs",A="MN:Fs"$ is kept pointing to the current task's record.) There is no memory segmentation. It is 64-bit and flat. FS and GS are used as general purpose regs, more or less.
$ID,2$ZenithOS uses a dialect of C/C++ called $LK,"CosmiC",A="FI:::/Doc/CosmiC.DD"$. It is not $FG,2$Pascal$FG$. I altered the syntax making parenthesis optional on function calls with no paramaters.
$ID,2$$LK,"Yield",A="MN:Yield"$() saves the current task's regs (context) and loads in the next task. In a loop waiting for disk IO, it executes $LK,"Yield",A="MN:Yield"$() which pegs the CPU load, yet the system is responsive.
$ID,-2$$TR,"What is JIT Compiled Mode?"$
$ID,2$The term $LK,"JIT Compile Mode",A="FF:::/Doc/Glossary.DD,JIT Compile Mode"$ means it compiles and executes code placed into mem, not stored on disk.
$ID,-2$$TR,"Why do files end in .Z? Are they encrypted?"$
$ID,2$Files with names ending in $FG,2$.Z$FG$ are individually compressed using $LK,"ZenithOS Compression",A="FI:::/Kernel/Compress.CC"$. They are not encrypted. $LK,"Copy",A="MN:Copy"$() or rename them with $LK,"Move",A="MN:Move"$() to a name without $FG,2$.Z$FG$ and they will be stored in an uncompressed form. See $LK,"TOSZ",A="FI:::/Doc/TOSZ.DD"$ for Linux or Windows uncompress C/C++ code.
$ID,-2$$TR,"Is it open source? How do I build it?"$
$ID,2$ZenithOS is 100% open src. All the src code is included in the distro. Use $LK,"BootHDIns",A="MN:BootHDIns"$() to compile the kernel and compiler. The rest is $LK,"JIT Compiled",A="FF:::/Doc/Glossary.DD,JIT Compile Mode"$ during boot. See $LK,"::/StartOS.CC"$.
$ID,2$ZenithOS does not use object files or a linker. $LK,"AOT Compile Mode",A="FF:::/Doc/Glossary.DD,AOT Compile Mode"$ is used to directly create flat binary files, $LK,"::/Kernel.BIN.C",A="FI:::/Kernel/Kernel.PRJ"$ and $LK,"::/Compiler/Compiler.BIN",A="FI:::/Compiler/Compiler.PRJ"$ with no object files and linking.$FG$ $LK,"JIT Compile Mode",A="FF:::/Doc/Glossary.DD,JIT Compile Mode"$ place code in memory, ready to run, with no object files or linking. Linking is done when $FG,2$BIN$FG$ modules are $LK,"Load",A="MN:Load"$()ed.
$ID,2$The refresh rate is $TX,"(30000.0/1001)",D="WINMGR_FPS"$ frames-per-second. That is how often ZenithOS updates screen mem. It is not syncronized to the hardware.
$ID,2$ZenithOS allocs mem as more items are displayed in the window. Also, ZenithOS allocs mem for code as it is compiled at the cmd line. If you $FG,2$#include$FG$ a file twice, it allocs 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. If it bothers you, hit $FG,2$<CTRL-ALT-x>$FG$ and $FG,2$<CTRL-ALT-t>, $FG$periodically, to kill and recreate the task$FG$. Use the pop-up flag on macros in your $LK,"PersonalMenu",A="FI:::Home/PersonalMenu.DD"$ to spawn new tasks, run applications and free the applications when they are finished. Small mem chunks stick to the task when they are freed until it is killed. The only way to get in trouble is allocating multiple Meg chunks and freeing them. These can only be reused if the same size gets alloced again. Use $LK,"HeapLog",A="MN:HeapLog"$(), $LK,"HeapLogAddrRep",A="MN:HeapLogAddrRep"$() and $LK,"HeapLogSizeRep",A="MN:HeapLogSizeRep"$() to see who alloced mem and didn't free it. See $LK,"MemoryOverview",A="FI:::/Doc/MemoryOverview.DD"$.
$ID,2$ZenithOS runs in $FG,2$High-res 32-bit color VBE$FG$ graphics modes, not text mode. It changes to this mode with a $LK,"BIOS call",A="FF:::/Kernel/KStart16.CC,INT 0x10"$ while in real-mode before it switches to 64-bit mode. The text is $LK,"drawn by hand",A="MN:GrUpdateTextFG"$. See $LK,"::/Kernel/FontStd.CC"$.
$ID,2$ZenithOS identity-maps all memory, all the time. It is like paging is not used. There is no special kernel $FG,2$high half$FG$ memory space. ZenithOS is ring-0-only, so everything is kernel, even user programs. There is a special task called $FG,2$Zenith$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. All code goes in the lowest 2Gig of addresses, known as the $LK,"Code Heap",A="FF:::/Doc/Glossary.DD,Code and Data Heaps"$, so that the $FG,2$REL32$FG$ addressing mode can be used. See $LK,"MemoryOverview",A="FI:::/Doc/MemoryOverview.DD"$.
$ID,2$ZenithOS puts all code in the lowest 2Gig, known as the $LK,"Code Heap",A="FF:::/Doc/Glossary.DD,Code and Data Heaps"$, so that the $FG,2$REL32$FG$ addressing mode can be used. ZenithOS is 64-bit, but $FG,2$2Gig$FG$ is 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"$() allocs higher memory.
$ID,2$ZenithOS doesn't use software interrupts or $FG,2$SYSCALL$FG$ insts because it never needs to change out of ring-0, even running user programs. Calls are always $FG,2$CALL REL32$FG$ insts.
$ID,2$The stack does not grow, so do not do deep recursion. In theory, memory gets fragmented, too.
$ID,-2$$TR,"How do I set the PATH?"$
$ID,2$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.DD"$.
$ID,2$If you use Grub, you $FG,2$chain-load$FG$ like Windows. See $LK,"Boot",A="FI:::/Doc/Boot.DD"$. You can use the ZenithOS boot-loader. $LK,"Master-Boot-Loader-Stage1",A="FI:::/Zenith/Boot/BootMHD.CC"$, $LK,"Master-Boot-Loader-Stage2",A="FI:::/Zenith/Boot/BootMHD2.CC"$, $LK,"Partition-Boot-Loader",A="FI:::/Zenith/Boot/BootHD.CC"$, $LK,"CD-DVD-Boot-Loader",A="FI:::/Zenith/Boot/BootDVD.CC"$.
$ID,2$The boot-loaders must be patched by you running $LK,"BootHDIns",A="MN:BootHDIns"$() or $LK,"BootMHDIns",A="MN:BootMHDIns"$(). 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/KStart16.CC"$ if you relocate it.
$ID,2$ZenithOS is 64-bit. Like all PC operating systems, the boot-loader starts in 16-bit real-mode. ZenithOS 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. ZenithOS calls $LK,"that",A="FI:::/Kernel/PCIBIOS.CC"$ a couple times. It must temporarily drop-out-of 64-bit mode for that and stop multi-tasking.
$ID,-2$$TR,"Why are you pushing 32-bit values on the stack?"$
$ID,2$$FG,2$PUSH EAX$FG$ : All stack operations in 64-bit mode are 64-bits.
$ID,-2$$TR,"Why are you using 32-bit insts and not setting high 32-bits?"$
$ID,2$$FG,2$XOR EAX,EAX$FG$ : Operations on 32-bit regs clear the high 32-bits.
$ID,-2$$TR,"How do you use the FS and GS segment registers."$
$ID,2$$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"$.
$ID,-2$$TR,"How do I set ORG for position of code?"$
$ID,2$The compiler creates $FG,2$pos independent$FG$ code. Don't create code which is loaded at a fixed, specified location. Code in a BIN file is $FG,2$pos independent$FG$ by virtue of a table in the BIN file for patching absolute addresses.
$ID,2$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$AutoComplete$FG$ feature can find src lines.
$ID,2$The word $FG,2$public$FG$ in $LK,"CosmiC",A="FI:::/Doc/CosmiC.DD"$ does very little except allow the $LK,"Help & Index",A="FI:::/Doc/HelpIndex.DD"$ 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"$.
$ID,-2$$TR,"How does the debugger do source debugging?"$
$ID,2$When compilation takes place, the structures used by the compiler stick around. Data on classes can be accessed. See $LK,"ClassRep",A="MN:ClassRep"$().
$ID,-2$$TR,"What are the ASCII 5 and ASCII 31 chars doing in my text files?"$
$ID,2$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$.
$ID,2$If you change code in the $FG,2$/Zenith$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 $LK,"JIT Compile Mode",A="FF:::/Doc/Glossary.DD,JIT Compile Mode"$. There is no $FG,2$.BIN$FG$ file for $FG,2$JIT$FG$ compilation. See $LK,"::/StartOS.CC"$.
$ID,2$If not found, $FG,2$.Z$FG$ is added or removed from filename 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.