ZenithOS

.gitignore

@@ -1 +0,0 @@
-src/Kernel.BIN.C

src/Adam/ADefine.HC

@@ -4,7 +4,7 @@ U0 LoadDocDefines()
 {
   CBinFile *bfh=mem_boot_base-sizeof(CBinFile);
 
-  DefinePrint("DD_OS_NAME_VERSION","TempleOS V%0.2f",sys_os_version);
+  DefinePrint("DD_OS_NAME_VERSION","ZenithOS V%0.2f",sys_os_version);
   DefinePrint("DD_TEMPLEOS_AGE","%0.1f",
 	(Now-Str2Date("8/1/2003"))/ToF64(1<<32)/CDATE_YEAR_DAYS);
 

src/Adam/DolDoc/DocGr.HC

@@ -19,7 +19,7 @@ public I64 PopUpColor(U8 *header=NULL,
 }
 
 public I64 PopUpColorLighting(U8 *header=NULL)
-{//Chooser for std TempleOS $LK,"DCLighting",A="MN:DCLighting"$() color.
+{//Chooser for std ZenithOS $LK,"DCLighting",A="MN:DCLighting"$() color.
   I64 i;
   CDoc *doc=DocNew;
   if (header)

src/Adam/DolDoc/DocLink.HC

@@ -1,6 +1,6 @@
 #help_index "DolDoc/Link"
 
-/* See $LK,"TempleOS Link Types",A="MN:ST_LINK_TYPES"$.
+/* See $LK,"ZenithOS Link Types",A="MN:ST_LINK_TYPES"$.
 "filename"
 "FI:filename"
 "FA:haystack_filename,needle_anchor_str"

src/Adam/DolDoc/MakeDoc.HC

@@ -4,7 +4,7 @@ Cd(__DIR__);;
 #help_file "::/Doc/DolDoc"
 
 /*
-TempleOS DolDoc's can have "cursor movement" cmds which can move the cursor up
+ZenithOS DolDoc's can have "cursor movement" cmds which can move the cursor up
 the scrn and layer on existing text.It can also have callback funs which
 supply live, changing text.For these reasons, you can't assume you know
 where the vis portion of the document is and must process much

src/Adam/Gr/GrComposites.HC

@@ -323,7 +323,7 @@ public U0 DrawWaitMs(CDC *dc,I64 x,I64 y)
 
 #help_index "Graphics/GR Files;Graphics/Scrn"
 public Bool GRScrnCaptureRead(U8 *filename,CDC *dc=gr.dc,I64 x=0,I64 y=0)
-{//GrBlot TempleOS GR File to dc,x,y.
+{//GrBlot ZenithOS GR File to dc,x,y.
   CDC *dc2;
   if (dc2=GRRead(filename)) {
     dc->color=ROP_EQU;
@@ -335,7 +335,7 @@ public Bool GRScrnCaptureRead(U8 *filename,CDC *dc=gr.dc,I64 x=0,I64 y=0)
 }
 
 public I64 GRScrnCaptureWrite(U8 *filename,Bool include_zoom=TRUE)
-{//Capture scrn to a TempleOS GR File.
+{//Capture scrn to a ZenithOS GR File.
   I64 size;
   CDC *dc=DCScrnCapture(include_zoom);
   size=GRWrite(filename,dc,DCSF_COMPRESSED|DCSF_PALETTE_GET);

src/Adam/Gr/GrDC.HC

@@ -92,7 +92,7 @@ public U0 DCLighting(CDC *dc,
   //gives an illumination number.
   //65536*65536>>16=65536
 
-  //TempleOS will generate a random U16
+  //ZenithOS will generate a random U16
   //and compare to dither_probability_u16 and
   //will pick from two colors.
   //Probability dithering does not work with thick>1 at this time.
@@ -381,7 +381,7 @@ public CDC *DCLoad(U8 *src,I64 *_size=NULL,CTask *task=NULL)
 	COLORS_NUM*sizeof(CBGR48)+sizeof(CArcCtrl)+GR_WIDTH*GR_HEIGHT)
 
 public I64 GRWrite(U8 *filename,CDC *dc,I64 dcsf_flags=DCSF_COMPRESSED)
-{//TempleOS GR File.
+{//ZenithOS GR File.
   I64	size;
   U8	*st=ExtDft(filename,"GR"),
 	*src=DCSave(dc,&size,dcsf_flags);
@@ -392,7 +392,7 @@ public I64 GRWrite(U8 *filename,CDC *dc,I64 dcsf_flags=DCSF_COMPRESSED)
 }
 
 public CDC *GRRead(U8 *filename,CTask *task=NULL)
-{//TempleOS GR File.
+{//ZenithOS GR File.
   CDC	*dc=NULL;
   U8	*st=ExtDft(filename,"GR"),
 	*src=FileRead(st);

src/Adam/Opt/Boot/BootDVD.HC

@@ -48,10 +48,10 @@ BDVD_DAP_BUF:		DU16	0,0;
 BDVD_DAP_BLK:		DU64	0;
 	
 BDVD_TEMPLEOS_MSG:
-	DU8	"LoadingTempleOS",0;
+	DU8	"LoadingZenithOS",0;
 
 BDVD_NOT64_MSG:
-	DU8	"TempleOS requires a 64-bit capable processor.\n\r",0;
+	DU8	"ZenithOS requires a 64-bit capable processor.\n\r",0;
 
 //These get patched.
 BDVD_BLK_LO::		DU16	0;

src/Adam/Opt/Boot/BootMHDIns.HC

@@ -53,9 +53,9 @@ public U0 BootMHDZero(U8 dst_drv)
 {//Set MBR of disk with dst partition to zero.
 
   //This is dangerous!!
-  //The TempleOS partitioner doesn't play well
+  //The ZenithOS partitioner doesn't play well
   //with other operating systems at this time and you need
-  //to do this on a drive partitioned by TempleOS
+  //to do this on a drive partitioned by ZenithOS
   //if you wish to partition with another operating system.
   CBlkDev *bd=Let2BlkDev(dst_drv);
   CMasterBoot mbr;
@@ -99,7 +99,7 @@ public Bool BootMHDIns(U8 drv_let,U8 *drv_lst=NULL)
       _q=BMHD2_BLK_ARRAY;
       MemSet(_q,0,sizeof(I64)*8);
       menu_ptr=BMHD2_BOOT_MSG;
-      StrPrint(menu_ptr,"\n\r\n\rTempleOS Boot Loader\n\r\n\r");
+      StrPrint(menu_ptr,"\n\r\n\rZenithOS Boot Loader\n\r\n\r");
       j=0;
       if (FileFind(BOOT_DIR_OLDMBR_BIN_C,&de,FUF_JUST_FILES)) {
 	Free(de.full_name);

src/Adam/Opt/Boot/DskISORedSea.HC

@@ -72,7 +72,7 @@ U0 RedSeaISO9660(U8 *iso_filename,U8 drv_let)
     FillU32Palindrome(&iso_pri->vol_space_size,iso_size);
     FillU32Palindrome(&iso_pri->root_dir_record,dv->root_clus);
     iso_pri->file_structure_version=1;
-    StrCpy(iso_pri->publisher_id,"TempleOS RedSea");
+    StrCpy(iso_pri->publisher_id,"ZenithOS RedSea");
 
     MemCpy(iso_sup,iso_pri,DVD_BLK_SIZE);
     iso_sup->type=ISOT_SUPPLEMENTARY_DESC;
@@ -95,7 +95,7 @@ U0 RedSeaISO9660(U8 *iso_filename,U8 drv_let)
     FBlkWrite(out_file,iso_term,19<<2,4);
 
     et->w[0]=1;
-    StrCpy(&et->w[2],"TempleOS");
+    StrCpy(&et->w[2],"ZenithOS");
     et->w[15]=0xAA55;
     j=0;
     for (i=0;i<16;i++) //Checksum

src/Apps/KeepAway/KeepAway.HC

@@ -218,8 +218,8 @@ Frame imgs[LAST_STOPPED_DRIBBLING+1]={
   {{$IB,"<22>",BI=22$,$IB,"<23>",BI=23$},DRIBBLE_T/STOPPED_DRIBBLING_IMGS_NUM},
 };
 
-RegDft("TempleOS/KeepAway","I64 best_score0=0,best_score1=9999;\n");
+RegDft("ZenithOS/KeepAway","I64 best_score0=0,best_score1=9999;\n");
-RegExe("TempleOS/KeepAway");
+RegExe("ZenithOS/KeepAway");
 
 F64 game_t_end,foul_t_end;
 I64 score0,score1;
@@ -702,7 +702,7 @@ ka_done: //Don't goto out of try
     PutExcept;
   SettingsPop;
   MenuPop;
-  RegWrite("TempleOS/KeepAway","I64 best_score0=%d,best_score1=%d;\n",
+  RegWrite("ZenithOS/KeepAway","I64 best_score0=%d,best_score1=%d;\n",
 	best_score0,best_score1);
 }
 Êp¨­ÿÿÿûÿÿÿûÿÿÿ­ÿÿÿûÿÿÿ·ÿÿÿûÿÿÿûÿÿÿ·ÿÿÿûÿÿÿ­ÿÿÿûÿÿÿ­ÿÿÿ·ÿÿÿûÿÿÿ·ÿÿÿ

src/Apps/Titanium/Titanium.HC

@@ -1,5 +1,5 @@
-RegDft("TempleOS/Titanium","I64 best_score=0;\n");
+RegDft("ZenithOS/Titanium","I64 best_score=0;\n");
-RegExe("TempleOS/Titanium");
+RegExe("ZenithOS/Titanium");
 
 #define MAP_HEIGHT	4096
 
@@ -951,7 +951,7 @@ to_done:
     PutExcept;
   SettingsPop;
   MenuPop;
-  RegWrite("TempleOS/Titanium","I64 best_score=%d;\n",best_score);
+  RegWrite("ZenithOS/Titanium","I64 best_score=%d;\n",best_score);
 }
 Ró˙˙˙Ď˙˙˙2˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙
 ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙

src/Apps/ToTheFront/TTFVis.HC

@@ -139,7 +139,7 @@ Bool VisRecalc(I64 mode,Unit *tmpu=NULL)
 to know if something is const.;-)This
 just compiles with the val at compile
 time, an advantage of just-in-time over
-AOT binaries.TempleOS has a limited
+AOT binaries.ZenithOS has a limited
 stk size, so don't get in the habit.
 $LK,"MAlloc",A="MN:MAlloc"$() would probably be the better choice.
 */

src/Apps/X-Caliber/X-Caliber.HC

@@ -1,10 +1,10 @@
 #define  XMSGF_ANTISPIN		0
 #define  XMSGF_SOLAR_STORM	1
-RegDft("TempleOS/XCaliber",
+RegDft("ZenithOS/XCaliber",
 	"I64 best_score=0;\n"
 	"I64 msg_flags=0;\n"
 	);
-RegExe("TempleOS/XCaliber");
+RegExe("ZenithOS/XCaliber");
 
 #define MT_HUMAN_SHIP		0
 #define MT_ENEMY_SHIP		1
@@ -1510,7 +1510,7 @@ U0 XCaliber()
   SettingsPop;
   CtrlPanelDel(cp);
   MenuPop;
-  RegWrite("TempleOS/XCaliber",
+  RegWrite("ZenithOS/XCaliber",
 	"I64 best_score=%d;\n"
 	"I64 msg_flags=%d;\n",best_score,msg_flags);
 }

src/Compiler/OpCodes.DD

@@ -9,7 +9,7 @@
 '*'= IEF_STI_LIKE	Floating STI-like for UAsm.
 '$$'= IEF_ENDING_ZERO	Ending zero for ENTER.
 
-$FG,4$Note:$FG$ TempleOS uses nonstandard opcodes.
+$FG,4$Note:$FG$ ZenithOS uses nonstandard opcodes.
 Asm is kind-of a bonus and I made changes
 to make the assembler simpler. For opcodes
 which can have different numbers of

src/Compiler/PrsExp.HC

@@ -728,7 +728,7 @@ I64 PrsUnaryTerm(CCmpCtrl *cc,CPrsStk *ps,CMemberLst **_local_var,
     case '(':
       if (Lex(cc)==TK_IDENT && cc->hash_entry &&
 	    cc->hash_entry->type & (HTT_CLASS|HTT_INTERNAL_TYPE))
-	LexExcept(cc,"Use TempleOS postfix typecasting at ");
+	LexExcept(cc,"Use ZenithOS postfix typecasting at ");
       else {
 	if (PREC_TERM>*max_prec)
 	  *max_prec=PREC_TERM;

src/Demo/AcctExample/PersonalNotes.DD

@@ -309,7 +309,7 @@ $FG,5$$TX+CX,"Committee Needed"$$FG$
 
 * I use fixed-point in $LK,"Circle",A="MN:Circle"$(), $LK,"Ellipse",A="MN:Ellipse"$(), $LK,"Mat4x4MulXYZ",A="MN:Mat4x4MulXYZ"$(), $LK,"Mat4x4MulMat4x4New",A="MN:Mat4x4MulMat4x4New"$() and others.  God says I might want to change to float.  $LK,"::/Demo/Lectures/FixedPoint.HC"$ $LK,"::/Demo/Lectures/FixedPointAdvanced.HC"$.
 
-* Note: We will never put multiple $LK,"Keyboard Tables",A="FI:::/Kernel/SerialDev/Keyboard.HC"$.  Each country must make their own version of TempleOS.  The $LK,"Intel Factory ROM",A="FF:::/Doc/Demands.DD,English"$ will have just English.  Our $LK,"Charter",A="FI:::/Doc/Charter.DD"$ bans multiple country or architectures in the same version.
+* Note: We will never put multiple $LK,"Keyboard Tables",A="FI:::/Kernel/SerialDev/Keyboard.HC"$.  Each country must make their own version of ZenithOS.  The $LK,"Intel Factory ROM",A="FF:::/Doc/Demands.DD,English"$ will have just English.  Our $LK,"Charter",A="FI:::/Doc/Charter.DD"$ bans multiple country or architectures in the same version.
 
 * 12 border chars in scrn font codes 0x02-0x0D.  $LK,"TextBorder",A="MN:TextBorder"$() $LK,"RawDr",A="MN:RawDr"$() $LK,"::/Demo/Games/CharDemo.HC"$. LineFeed shows-up in $FG,2$<CTRL-m>$FG$ PersonalMenu.
 

src/Demo/AcctExample/Registry.HC

@@ -21,7 +21,7 @@ HashPublic("INS_REG_MACHINE_NUM",HTT_DEFINE_STR);
 "InsReg:%s:%d\n",INS_REG_PERSONAL_INITIALS,INS_REG_MACHINE_NUM;
 
 #help_index ""
-$ID,-2$$ID,-2$$TR-UL,"TempleOS"$
+$ID,-2$$ID,-2$$TR-UL,"ZenithOS"$
 $ID,2$$TR,"EagleDive"$
 $ID,2$F64 best_score=147.6932;
 $ID,-2$$TR,"DiningStars"$

src/Demo/AcctExample/TOS/TOSDistro.HC

@@ -142,7 +142,7 @@ U0 MakeStdDistro()
   StdDistroPrep;
   RedSeaISO(TOS_ISO_NAME,TOS_DISTRO_DIR,TOS_DISTRO_DIR BOOT_DIR_KERNEL_BIN_C);
   DefinePrint("DD_TEMPLEOSCD_SIZE",
-	"Download $TX,"TempleOS V5.03",D="DD_OS_NAME_VERSION"$ - Standard Distro (%0.1fMB)",
+	"Download $TX,"ZenithOS V5.03",D="DD_OS_NAME_VERSION"$ - Standard Distro (%0.1fMB)",
 	0.1*(10*Size(TOS_ISO_NAME,"+s")/1024/1024));
   Drv('C');
 }
@@ -173,7 +173,7 @@ U0 MakeLiteDistro()
   LiteDistroPrep;
   RedSeaISO(TOS_ISO_NAME,TOS_DISTRO_DIR,TOS_DISTRO_DIR BOOT_DIR_KERNEL_BIN_C);
   DefinePrint("DD_TEMPLEOSCD_SIZE",
-	"Download $TX,"TempleOS V5.03",D="DD_OS_NAME_VERSION"$ - Standard Distro (%0.1fMB)",
+	"Download $TX,"ZenithOS V5.03",D="DD_OS_NAME_VERSION"$ - Standard Distro (%0.1fMB)",
 	0.1*(10*Size(TOS_ISO_NAME,"+s")/1024/1024));
   Drv('C');
 }
@@ -199,7 +199,7 @@ U0 MakeDbgDistro()
   DbgDistroPrep;
   RedSeaISO(TOS_ISO_NAME,TOS_DISTRO_DIR,TOS_DISTRO_DIR BOOT_DIR_KERNEL_BIN_C);
   DefinePrint("DD_TEMPLEOS_DBG_SIZE",
-	"Download $TX,"TempleOS V5.03",D="DD_OS_NAME_VERSION"$ - Debug Distro (%0.1fMB)",
+	"Download $TX,"ZenithOS V5.03",D="DD_OS_NAME_VERSION"$ - Debug Distro (%0.1fMB)",
 	0.1*(10*Size(TOS_ISO_NAME,"+s")/1024/1024));
   Drv('C');
 }
@@ -223,7 +223,7 @@ U0 MakeStaffDistro()
   StaffDistroPrep;
   RedSeaISO(TOS_ISO_NAME,TOS_DISTRO_DIR,TOS_DISTRO_DIR BOOT_DIR_KERNEL_BIN_C);
   DefinePrint("DD_TEMPLEOS_STAFF_SIZE",
-	"Download $TX,"TempleOS V5.03",D="DD_OS_NAME_VERSION"$ - T.S. Company Internal Distro (%0.1fMB)",
+	"Download $TX,"ZenithOS V5.03",D="DD_OS_NAME_VERSION"$ - T.S. Company Internal Distro (%0.1fMB)",
 	0.1*(10*Size(TOS_ISO_NAME,"+s")/1024/1024));
   Drv('C');
 }
@@ -260,7 +260,7 @@ U0 UpdateISODocDefines()
 {
   try {
     DefinePrint("DD_TEMPLEOSCD_SIZE",
-	  "Download $TX,"TempleOS V5.03",D="DD_OS_NAME_VERSION"$ - Standard Distro (%0.1fMB)",
+	  "Download $TX,"ZenithOS V5.03",D="DD_OS_NAME_VERSION"$ - Standard Distro (%0.1fMB)",
 	  0.1*(10*Size("D:/Downloads/TOS_Distro.ISO","+s")/1024/1024));
     DefinePrint("DD_TEMPLEOSCD_K_SIZE",
 	  "%dKB",Size("D:/Downloads/TOS_Distro.ISO","+s")/1024);
@@ -293,7 +293,7 @@ U0 TOSRegen2()
   SettingsPush; //See $LK,"SettingsPush",A="MN:SettingsPush"$
   tos_progress=-1;
   tos_progress_t0=tS;
-  RegExe("TempleOS/TOSRegen");
+  RegExe("ZenithOS/TOSRegen");
 
   TOSProgress("DskChk All");
   AutoComplete;
@@ -364,7 +364,7 @@ U0 TOSRegen2()
   SettingsPop;
   "F2(\"/Home\") Cnt\t:%d\n",slash_home;
   "Elapsed Time\t:%5.3fs\n",tS-progress4_t0;
-  ProgressBarsRst("TempleOS/TOSRegen");
+  ProgressBarsRst("ZenithOS/TOSRegen");
 }
 
 public U0 TOSPreRegen()

src/Demo/Asm/AsmAndC1.HC

@@ -55,7 +55,7 @@ I64 AsmAndC1()
 
 		//U0 $LK,"Snd",A="MN:Snd"$(I8 ona);
     MOV		RAX,RCX	//ona=loop*10+50
-    IMUL2	RAX,10 //TempleOS uses nonstandard opcodes
+    IMUL2	RAX,10 //ZenithOS uses nonstandard opcodes
 		//to avoid multiple form of the same one.
 		//See $LK,"::/Compiler/OpCodes.DD"$.
     ADD		RAX,40

src/Demo/Games/CastleFrankenstein.HC

@@ -1,7 +1,7 @@
 //Uses $LK,"fixed-point",A="FI:::/Demo/Lectures/FixedPoint.HC"$.
 
-RegDft("TempleOS/CastleFrankenstein","F64 best_score=9999;\n");
+RegDft("ZenithOS/CastleFrankenstein","F64 best_score=9999;\n");
-RegExe("TempleOS/CastleFrankenstein");
+RegExe("ZenithOS/CastleFrankenstein");
 
 //Set snap to 4 and width to 4
 //if you edit this map.
@@ -589,7 +589,7 @@ fs_done:
   SettingsPop;
   CleanUp;
   MenuPop;
-  RegWrite("TempleOS/CastleFrankenstein","F64 best_score=%5.4f;\n",
+  RegWrite("ZenithOS/CastleFrankenstein","F64 best_score=%5.4f;\n",
 	best_score);
 }
 

src/Demo/Games/CircleTrace.HC

@@ -2,8 +2,8 @@
 
 //Giotto, a famous artist, drew a freehand circle to get a job.
 
-RegDft("TempleOS/CircleTrace","F64 best_score=999;\n");
+RegDft("ZenithOS/CircleTrace","F64 best_score=999;\n");
-RegExe("TempleOS/CircleTrace");
+RegExe("ZenithOS/CircleTrace");
 
 I64 cx,cy;
 F64 avg_error=0,elapsed_time=0,total_error=0,score=999;
@@ -122,7 +122,7 @@ U0 CircleTrace()
   SettingsPop;
   DCFill;
   DCDel(dc);
-  RegWrite("TempleOS/CircleTrace","F64 best_score=%5.4f;\n",best_score);
+  RegWrite("ZenithOS/CircleTrace","F64 best_score=%5.4f;\n",best_score);
 }
 
 CircleTrace;  //Execute when #included

src/Demo/Games/DunGen.HC

@@ -1,5 +1,5 @@
-RegDft("TempleOS/DunGen","F64 best_score=9999;\n");
+RegDft("ZenithOS/DunGen","F64 best_score=9999;\n");
-RegExe("TempleOS/DunGen");
+RegExe("ZenithOS/DunGen");
 
 //Set snap to 4 and width to 4
 //if you edit this map.
@@ -439,7 +439,7 @@ dg_done:
   SettingsPop;
   CleanUp;
   MenuPop;
-  RegWrite("TempleOS/DunGen","F64 best_score=%5.4f;\n",best_score);
+  RegWrite("ZenithOS/DunGen","F64 best_score=%5.4f;\n",best_score);
 }
 
 DunGen;

src/Demo/Games/Maze.HC

@@ -22,7 +22,7 @@ U0 DrawIt(CTask *task,CDC *)
 //We would put these as local vars
 //in SolveMaze() but the system stk size
 //is limited, so it's a bad habit.The heap
-//is the normal TempleOS technique, but
+//is the normal ZenithOS technique, but
 //it's a pain in this case.
 I64	stk_ptr,
 	stk_x  [STK_SIZE],

src/Demo/Games/RawHide.HC

@@ -1,7 +1,7 @@
 //Uses $LK,"fixed-point",A="FI:::/Demo/Lectures/FixedPoint.HC"$.
 
-RegDft("TempleOS/RawHide","F64 best_score=9999;\n");
+RegDft("ZenithOS/RawHide","F64 best_score=9999;\n");
-RegExe("TempleOS/RawHide");
+RegExe("ZenithOS/RawHide");
 
 F64 t0,tf;
 I64 outside_cnt;
@@ -585,7 +585,7 @@ rh_done:
   SettingsPop;
   CleanUp;
   MenuPop;
-  RegWrite("TempleOS/RawHide","F64 best_score=%5.4f;\n",best_score);
+  RegWrite("ZenithOS/RawHide","F64 best_score=%5.4f;\n",best_score);
 }
 
 RawHide;

src/Demo/Games/Talons.HC

@@ -1,7 +1,7 @@
 //Uses $LK,"fixed-point",A="FI:::/Demo/Lectures/FixedPoint.HC"$.
 
-RegDft("TempleOS/Talons","F64 best_score=9999;\n");
+RegDft("ZenithOS/Talons","F64 best_score=9999;\n");
-RegExe("TempleOS/Talons");
+RegExe("ZenithOS/Talons");
 
 //Keep these power of two so shift is used instead of multiply
 //to index arrays.
@@ -1227,7 +1227,7 @@ U0 Talons()
   CleanUp;
   PostCleanUp;
   MenuPop;
-  RegWrite("TempleOS/Talons","F64 best_score=%5.4f;\n",best_score);
+  RegWrite("ZenithOS/Talons","F64 best_score=%5.4f;\n",best_score);
 }
 
 Talons;

src/Demo/Games/Varoom.HC

@@ -87,8 +87,8 @@
 
 
 
-RegDft("TempleOS/Varoom","F64 best_score=9999;\n");
+RegDft("ZenithOS/Varoom","F64 best_score=9999;\n");
-RegExe("TempleOS/Varoom");
+RegExe("ZenithOS/Varoom");
 
 F64 distance,t0,tf;
 Bool game_over;
@@ -697,7 +697,7 @@ vr_done: //Don't goto out of try
   SettingsPop;
   CleanUp;
   MenuPop;
-  RegWrite("TempleOS/Varoom","F64 best_score=%5.4f;\n",best_score);
+  RegWrite("ZenithOS/Varoom","F64 best_score=%5.4f;\n",best_score);
 }
 
 Varoom;

src/Demo/Games/Wenceslas.HC

@@ -1,5 +1,5 @@
-RegDft("TempleOS/Wenceslas","F64 best_score=9999;\n");
+RegDft("ZenithOS/Wenceslas","F64 best_score=9999;\n");
-RegExe("TempleOS/Wenceslas");
+RegExe("ZenithOS/Wenceslas");
 
 #define BORDER		5
 #define KING_STEP	6
@@ -586,7 +586,7 @@ ws_done:
   SettingsPop;
   CleanUp;
   MenuPop;
-  RegWrite("TempleOS/Wenceslas","F64 best_score=%5.4f;\n",best_score);
+  RegWrite("ZenithOS/Wenceslas","F64 best_score=%5.4f;\n",best_score);
 }
 
 Wenceslas;

src/Demo/Graphics/CommonAncestor.HC

@@ -113,7 +113,7 @@ U0 TreeCommonAncestor()
 }
 
 TreeCommonAncestor;
-/*Be careful with recursive routines in TempleOS
+/*Be careful with recursive routines in ZenithOS
 because the stack does not grow and will overflow.
 
 See $LK,"::/Demo/StkGrow.HC"$.

src/Demo/Graphics/Shading.HC

@@ -36,7 +36,7 @@ U0 Lighting(CDC *dc,CD3I32 *ls,CD3I32 *poly,I64 color)
   //vect and the surface normal
   //gives an illumination number.
 
-  //TempleOS will generate a random U16
+  //ZenithOS will generate a random U16
   //and compare to dither_probability_u16 and
   //will pick from two colors.
   //Probability dithering does not work with thick>1 at this time.

src/Demo/Lectures/64BitAsmQuiz.DD

@@ -54,7 +54,7 @@ $WW,1$$FG,5$$TX+CX,"64-Bit Assembly Quiz"$$FG$
 
 ----
 
-TempleOS identity-maps everything, all the time, so the usual convention of upper memory being for kernel does not apply.  It uses physical addresses, basically.  It puts all code in the lowest 2-Gig memory range so that it can use the CALL REL32 instruction, the fastest.  It never changes privilege levels or messes with page tables, once it is up-and-running.
+ZenithOS identity-maps everything, all the time, so the usual convention of upper memory being for kernel does not apply.  It uses physical addresses, basically.  It puts all code in the lowest 2-Gig memory range so that it can use the CALL REL32 instruction, the fastest.  It never changes privilege levels or messes with page tables, once it is up-and-running.
 
 ----
 

src/Demo/Lectures/MiniCompiler.HC

@@ -15,7 +15,7 @@ $ID,2$For this mini compiler, some things you should know about 64-bit asm:
 
 * "PUSH EAX", "POP EAX" and "XOR EAX,EAX" will behave as 64-bit even without REX because the stk is always 64 bit and because the XOR clears the upper 32-bits.
 
-It is okay in TempleOS to change RAX, RBX, RCX, RDX, R8 and R9 without restoring them to their original values.
+It is okay in ZenithOS to change RAX, RBX, RCX, RDX, R8 and R9 without restoring them to their original values.
 $ID,-2$$WW,0$*/
 
 #define TK_EOF		0

src/Demo/Lectures/MiniGrLib.HC

@@ -116,10 +116,10 @@ U0 MiniGrLibDemo()
   MGUpdate;
   Busy(1500000);
 /*
-We are returning graphics to normal operations under TempleOS.
+We are returning graphics to normal operations under ZenithOS.
-It is not normal to by-pass the TempleOS graphcis routines.
+It is not normal to by-pass the ZenithOS graphcis routines.
-The TempleOS graphics don't know VGA has changed.
+The ZenithOS graphics don't know VGA has changed.
-This bit tells TempleOS to update whole scrn.
+This bit tells ZenithOS to update whole scrn.
 */
   //<CTRL-ALT-v> will flush scrn VGA cache.
   VGAFlush;

src/Demo/Lectures/Ring3.HC

@@ -1,7 +1,7 @@
-/*TempleOS runs exclusively in ring 0.
+/*ZenithOS runs exclusively in ring 0.
 Ring 0 is part of the $LK,"Charter",A="FI:::/Doc/Charter.DD"$.
 This demo is for you to play around
-with ring 3.  TempleOS is for
+with ring 3.  ZenithOS is for
 recreational programming, after all.
 
 This redirects the general protection

src/Demo/Lectures/ScrnMemory.HC

@@ -37,7 +37,7 @@ That means no read-modify-writes, too.
 */
   Busy(4000000);
 
-  //TempleOS has a 4 plane memory duplicate of the scrn, $LK,"gr.scrn_image",A="MN:CGrGlbls"$,
+  //ZenithOS has a 4 plane memory duplicate of the scrn, $LK,"gr.scrn_image",A="MN:CGrGlbls"$,
   //and only writes actual changes.See $LK,"GrUpdateVGAGraphics",A="MN:GrUpdateVGAGraphics"$().
   //<CTRL-ALT-v> will flush scrn VGA cache.
   VGAFlush;

src/Demo/Print.HC

@@ -1,4 +1,4 @@
-//TempleOS supports standard $LK,"Print",A="MN:Print"$()
+//ZenithOS supports standard $LK,"Print",A="MN:Print"$()
 //codes and extended ones.
 //See $LK,"Print(\"\") Fmt Strings",A="FI:::/Doc/Print.DD"$.
 

src/Demo/SubIntAccess.HC

@@ -1,4 +1,4 @@
-/*TempleOS has a feature that allows
+/*ZenithOS has a feature that allows
 access to bytes and words of larger
 ints.
 

src/Demo/ToHtmlToTXTDemo/DemoInPage.DD

@@ -1,11 +1,11 @@
 $WW,1$$FG,5$$TX+CX,"The Temple Operating System",HTML="http://www.templeos.org"$$FG,0$
 
-$FG,4$$TX,"TempleOS File Downloads (100% Public Domain)",HTML="http://www.templeos.org/Downloads"$$FG$
+$FG,4$$TX,"ZenithOS File Downloads (100% Public Domain)",HTML="http://www.templeos.org/Downloads"$$FG$
 
-TempleOS is a free, public domain, open source, x86_64, non-preemptive multi-tasking, multi-cored, ring-0-only, single-address-map (identity-mapped), non-networked, PC operating system.  Paging is, basically, not used.
+ZenithOS is a free, public domain, open source, x86_64, non-preemptive multi-tasking, multi-cored, ring-0-only, single-address-map (identity-mapped), non-networked, PC operating system.  Paging is, basically, not used.
 
-The CIA obsfucates to foil India, China, Russia and Korea.  They make things more complicated than necessary.  TempleOS is more simple than necessary.  It is obnoxiously simple.  If you look at this $TX,"\"Hello World\" joke",HTML="http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html"$, you can see why I capped the line count of TempleOS at 100,000.
+The CIA obsfucates to foil India, China, Russia and Korea.  They make things more complicated than necessary.  ZenithOS is more simple than necessary.  It is obnoxiously simple.  If you look at this $TX,"\"Hello World\" joke",HTML="http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html"$, you can see why I capped the line count of ZenithOS at 100,000.
 
-God said TempleOS must be perfect, so backward compatibility is not promised.
+God said ZenithOS must be perfect, so backward compatibility is not promised.
 
-I, Terry Davis, wrote all $TX,"80,847",D="DD_TEMPLEOS_LOC"$ lines of TempleOS over the last $TX,"13.9",D="DD_TEMPLEOS_AGE"$ years, including the 64-bit compiler.  I have been a professional operating system developer since 1990 when I worked on Ticketmaster's VAX OS.
+I, Terry Davis, wrote all $TX,"80,847",D="DD_TEMPLEOS_LOC"$ lines of ZenithOS over the last $TX,"13.9",D="DD_TEMPLEOS_AGE"$ years, including the 64-bit compiler.  I have been a professional operating system developer since 1990 when I worked on Ticketmaster's VAX OS.

src/Demo/ToHtmlToTXTDemo/HtmlGen.HC

@@ -5,11 +5,11 @@ Notice that an entry like $$TX,"GOOGLE",HTML="http://www.google.com"$$
 will be converted to text in the html with an html link.
 
 I cheated by hardcoding $LK,"www.templeos.org",A="FF:::/Demo/ToHtmlToTXTDemo/ToHtml.HC,www.templeos.org"$ as the website
-for $LK,"TempleOS Links",A="MN:LK_FILE"$.  Why don't you copy
+for $LK,"ZenithOS Links",A="MN:LK_FILE"$.  Why don't you copy
 $LK,"::/Demo/ToHtmlToTXTDemo/ToHtml.HC"$ to your /Home directory
 and modify it?	You are welcome to link to
 http://www.templeos.org if you want file that come on the
-TempleOS distribution.
+ZenithOS distribution.
 
 You can pass html meta data as args to $LK,"ToHtml",A="FF:::/Demo/ToHtmlToTXTDemo/ToHtml.HC,ToHtml"$().
 */

src/Demo/ToHtmlToTXTDemo/ToHtml.HC

@@ -184,7 +184,7 @@ public CDoc *Doc2Html(CDoc *doc_in,U8 *html_header=NULL,U8 *body_header=NULL,
 	  "<head>\n"
 	  "<meta http-equiv=\"Content-Type\" "
 	  "content=\"text/html;charset=US-ASCII\">\n"
-	  "<meta name=\"generator\" content=\"$TX,"TempleOS V5.03",D="DD_OS_NAME_VERSION"$\">\n";
+	  "<meta name=\"generator\" content=\"$TX,"ZenithOS V5.03",D="DD_OS_NAME_VERSION"$\">\n";
   if (!body_header) body_header=
 	  "<body>\n"
 	  "<pre style=\"font-family:courier;font-size:10pt\">\n";

src/Doc/AboutTempleOS.DD

@@ -1,4 +1,4 @@
-$WW,1$$FG,5$$TX+CX,"TempleOS"$$FG$
+$WW,1$$FG,5$$TX+CX,"ZenithOS"$$FG$
 
 
 $FG,5$Websites:$FG$

src/Doc/AutoComplete.DD

@@ -16,4 +16,4 @@ $FG,2$<CTRL-1>$FG$	Autocompletes the 1st dictionary word in the window.
 $FG,2$<CTRL-2>$FG$	Autocompletes the 2nd dictionary word in the window.
 $FG,2$<CTRL-n>$FG$	Autocompletes the n-th dictionary word in the window.
 
-If you have the raw Project Gutenberg dictionary file, you can generate the TempleOS processed dictionary files with the stand-alone program $LK,"::/Adam/AutoComplete/ACDictGen.HC"$.
+If you have the raw Project Gutenberg dictionary file, you can generate the ZenithOS processed dictionary files with the stand-alone program $LK,"::/Adam/AutoComplete/ACDictGen.HC"$.

src/Doc/BlkChain.DD

@@ -4,17 +4,17 @@ There was a technique on the Commodore 64 where disk blocks were chained togethe
 
 The $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ file system does not allow files to grow because it only has an allocation bitmap and not a FAT table.  This "flaw" is by design.  I am intentionally crippling this operating system, making it a toy with the wisdom that this will prevent commercialization and corruption.  The toy spirit of the operating system will be preserved going into the future.  The vision for this operating system was a modern Commodore 64, which was a fun toy.
 
-Doing whole file operations is the TempleOS way of doing thinks.  It is the simplest and, ironically, the fastest.  It is obnoxious in the characteristic way that TempleOS is obnoxious, flaunting massive modern resources in a way that makes old programmers protest.
+Doing whole file operations is the ZenithOS way of doing thinks.  It is the simplest and, ironically, the fastest.  It is obnoxious in the characteristic way that ZenithOS is obnoxious, flaunting massive modern resources in a way that makes old programmers protest.
 
 Doing whole file operations will sabotage efforts to change the 640x480 resolution and violate the ban on multimedia.  When doing large, whole-file operations, immediately memory fragmentation is a serious problem, but not so for allocations in the range under a Meg (with occasional larger ones).
 
-The file compression scheme in TempleOS only works on whole file operations and the $LK,"DolDoc",A="FI:::/Doc/DolDoc.DD"$ format cannot have text tacked onto the end, since binary data is at the end.
+The file compression scheme in ZenithOS only works on whole file operations and the $LK,"DolDoc",A="FI:::/Doc/DolDoc.DD"$ format cannot have text tacked onto the end, since binary data is at the end.
 
 I don't want to spoil fun, so of course I offer a way to get awesome performance that is, ironically, superior.  $LK,"FBlkRead",A="MN:FBlkRead"$() and $LK,"FBlkWrite",A="MN:FBlkWrite"$() allow you to read a block offset from the start of a file.  Since files are all contiguous, this is incredibly efficient.  You just have to declare the desired file size when you create it with $LK,"FOpen",A="MN:FOpen"$() and cannot change it.  See $LK,"::/Demo/Dsk/DataBase.HC"$.
 
 If you like, you are encouraged to to do raw $LK,"BlkRead",A="MN:BlkRead"$() and $LK,"BlkWrite",A="MN:BlkWrite"$() directly on a drive.  Just get a pointer to a $LK,"CDrv",A="MN:CDrv"$ with $LK,"Let2Drv",A="MN:Let2Drv"$() and you are on your way!  Your computer is supposed to be a fun toy!  You can make an entire partition used for a database, or invent a file system.
 
-On the whole, the $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ file system with its whole-file-only limitation bring beautiful harmony.  It beautifully captures the spirit of TempleOS with simplicity and, ironic speed, since contiguous is fastest.
+On the whole, the $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ file system with its whole-file-only limitation bring beautiful harmony.  It beautifully captures the spirit of ZenithOS with simplicity and, ironic speed, since contiguous is fastest.
 
 $FG,8$
 * "Commodore 64" is a trademark owned by Polabe Holding NV.

src/Doc/CharOverview.DD

@@ -1,18 +1,18 @@
 $WW,1$$FG,5$$TX+CX,"Char Overview"$$FG$
 
-A $FG,2$Char$FG$acter is a single byte holding an ASCII code for a letter, num or sym.  The $FG,2$TempleOS$FG$ term is a $FG,2$U8$FG$.
+A $FG,2$Char$FG$acter is a single byte holding an ASCII code for a letter, num or sym.  The $FG,2$ZenithOS$FG$ term is a $FG,2$U8$FG$.
 
-Standard ASCII values range from 0 to 127.  Values below 32 are ctrl key's.  So, an ASCII #3 is a $FG,2$<CTRL-c>$FG$.  TempleOS uses a few nonstandard values below 32.  See $LK,"Char Definitions",A="MN:CH_SHIFT_SPACE"$.
+Standard ASCII values range from 0 to 127.  Values below 32 are ctrl key's.  So, an ASCII #3 is a $FG,2$<CTRL-c>$FG$.  ZenithOS uses a few nonstandard values below 32.  See $LK,"Char Definitions",A="MN:CH_SHIFT_SPACE"$.
 
 ASCII #5  is the cursor location in a saved file.
 ASCII #28 is $FG,2$<SHIFT-ESC>$FG$.
 ASCII #31 is a $FG,2$<SHIFT-SPACE>$FG$.
 
-TempleOS ASCII is 8-bit instead of 7-bit, so it also uses the range from 128-255.  Press $FG,2$<CTRL-ALT-a>$FG$ to see shapes for 128-255.  Technically, $FG,2$<CTRL-ALT-a>$FG$ are $LK,"scrn codes",A="HI:TextBase Layer"$.
+ZenithOS ASCII is 8-bit instead of 7-bit, so it also uses the range from 128-255.  Press $FG,2$<CTRL-ALT-a>$FG$ to see shapes for 128-255.  Technically, $FG,2$<CTRL-ALT-a>$FG$ are $LK,"scrn codes",A="HI:TextBase Layer"$.
 
-A $FG,2$Key$FG$ is typically specified with a scan code.  TempleOS scan codes contain the key value in the lowest $FG,2$U8$FG$, and flags in the upper 3 bytes.  See $LK,"Scan Code Flags",A="MN:SCF_CTRL"$ and $LK,"Scan Codes",A="MN:SC_INS"$.
+A $FG,2$Key$FG$ is typically specified with a scan code.  ZenithOS scan codes contain the key value in the lowest $FG,2$U8$FG$, and flags in the upper 3 bytes.  See $LK,"Scan Code Flags",A="MN:SCF_CTRL"$ and $LK,"Scan Codes",A="MN:SC_INS"$.
 
-TempleOS stores scan codes in 8 bytes.
+ZenithOS stores scan codes in 8 bytes.
   $FG,2$Byte 0$FG$   is the code.  NumPad keys, SHIFT, ALT, CTRL and GUI keys combined.
   $FG,2$Byte 1-3$FG$ are $LK,"flags",A="MN:SCf_KEY_UP"$
 

src/Doc/Charter.DD

@@ -1,4 +1,4 @@
-$FG,5$$WW,1$$TX+CX,"TempleOS Charter"$$FG$
+$FG,5$$WW,1$$TX+CX,"ZenithOS Charter"$$FG$
 
 Why did they make Solomon's Temple?  It was a direction to look, to focus on, a special place for meditation, to do offerings, a community center, a home to God's beauty, that encouraged love of God.  People cherished God's temple, beautifying it with gold and all fine things to show love of God, as great $TX,"cathedrals",HTML="https://www.youtube.com/watch?v=xkfmK-CLvcc"$ were decorated with astounding, awe-striking intricate art and gargoyles, incredible devotion to God with hours of effort, toiling and slaving-away for the glory of God, for families with children to see $TX,"stained-glass",HTML="https://www.youtube.com/watch?v=t8g1e-JLrhM"$ windows and tomes with ridiculously elaborate $TX,"calligraphy",HTML="https://www.youtube.com/watch?v=Oa8gMb0YC68"$ to show love of God, from a people who did little else but show love toward God, lived in dire conditions by today's standards, yet with so much difficulty scraping-by, found the time to devote $TX,"even all free-time",HTML="https://www.youtube.com/watch?v=tZw5V4XuUIo"$ to God!
 
@@ -17,7 +17,7 @@ with gold.
 ten cubits high.
 $ID,-5$
 
-* TempleOS is God's official temple.  Just like Solomon's temple, this is a community focal point where offerings are made and God's oracle is consulted.
+* ZenithOS is God's official temple.  Just like Solomon's temple, this is a community focal point where offerings are made and God's oracle is consulted.
 
 * God said $FG,2$640x480 16 color$FG$ graphics is a covenant like circumcision.  Children will do offerings.  Think of 16 colors like the Simpson's cartoons.  In the future, even if one GPU were universal, we would still keep 640x480 16 color and not use GPU acceleration.  Graphics operations should be transparent, not hidden in a GPU.
 
@@ -33,7 +33,7 @@ $ID,-5$
 
 * There is a limit of 100,000 lines of code for all time, not including applications and demos.  $FG,4$Code comments count$FG$, however.  Currently, there are $TX,"81,494",D="DD_TEMPLEOS_LOC"$ lines of code.  $FG,4$3rd party libraries are banned$FG$ because they circumvent the intent of this limit.  The vision is a Commodore 64 ROM -- a fixed core API that is the only dependency of applications.  Dependency on components and libraries creates a hell that is no longer blissful.
 
-* The metric for resolving all TempleOS code governance issues is how fast the compiler compiles itself and the kernel with $LK,"BootHDIns",A="MN:BootHDIns"$().  The $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ language should be changed to optimize this metric, as I did when I changed type casting from prefix standard C to postfix $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$, but we need a rule to prevent degenerating into a brainfuck language.
+* The metric for resolving all ZenithOS code governance issues is how fast the compiler compiles itself and the kernel with $LK,"BootHDIns",A="MN:BootHDIns"$().  The $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ language should be changed to optimize this metric, as I did when I changed type casting from prefix standard C to postfix $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$, but we need a rule to prevent degenerating into a brainfuck language.
  
 * Minimal abstraction is a goal.  Sheep are fools.  They always respect a design that is more complicated than another.  Any genius can make it complicated.  Like in physics, it takes a supra-genius to make it simple.
 
@@ -72,4 +72,4 @@ $FG$
 
 $FG,5$$WW,1$$TX+CX,"Possible Amendments"$$FG$
 
-The compiler's parser makes RISC code which it optimizes to CISC.  I discovered this does not matter because the CPU converts it back to RISC and schedules it, internally.  A TempleOS zealot with more zeal than I, might say we should save lines-of-code by removing the CISC optimizing.
+The compiler's parser makes RISC code which it optimizes to CISC.  I discovered this does not matter because the CPU converts it back to RISC and schedules it, internally.  A ZenithOS zealot with more zeal than I, might say we should save lines-of-code by removing the CISC optimizing.

src/Doc/Credits.DD

@@ -1,6 +1,6 @@
 $WW,1$$FG,5$$TX+CX,"Credits"$$FG$
 
-I, $FG,2$Terry A. Davis$FG$, wrote all of TempleOS over the past $TX,"13.9",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!  It is public domain, not GPL.
+I, $FG,2$Terry A. Davis$FG$, wrote all of ZenithOS over the past $TX,"13.9",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!  It is public domain, not GPL.
 
 *) $LK,"::/Kernel/FontStd.HC"$, is taken from $FG,4$$TX,"FreeDOS",HTML="http://www.freedos.org"$$FG$.  It's public domain.
 

src/Doc/Ctrls.DD

@@ -1 +1 @@
-$WW,1$To create a TempleOS graphic ctrl, you define callback functions and insert a $LK,"CCtrl",A="MN:CCtrl"$ structure in the $LK,"CTask",A="MN:CTask"$ queue.  See $LK,"::/Demo/Graphics/Slider.HC"$, $LK,"::/Demo/Graphics/ScrollBars.HC"$ and $LK,"TermBttnNew",A="FF:::/Adam/WallPaper.HC,TermBttnNew"$.  There is a template-code ctrl generator, if you press $FG,2$<CTRL-SHIFT-L>$FG$.
+$WW,1$To create a ZenithOS graphic ctrl, you define callback functions and insert a $LK,"CCtrl",A="MN:CCtrl"$ structure in the $LK,"CTask",A="MN:CTask"$ queue.  See $LK,"::/Demo/Graphics/Slider.HC"$, $LK,"::/Demo/Graphics/ScrollBars.HC"$ and $LK,"TermBttnNew",A="FF:::/Adam/WallPaper.HC,TermBttnNew"$.  There is a template-code ctrl generator, if you press $FG,2$<CTRL-SHIFT-L>$FG$.

src/Doc/CutCorners.DD

@@ -1,10 +1,10 @@
 $WW,1$$FG,5$$TX+CX,"Cut Corners"$
 $FG$
-There are a few places where I cut corners in the interest of not junking-up code.  This is part of the TempleOS mentality.  I try not to let stupid legacy compatibility issues enter and junk-up TempleOS.
+There are a few places where I cut corners in the interest of not junking-up code.  This is part of the ZenithOS mentality.  I try not to let stupid legacy compatibility issues enter and junk-up ZenithOS.
 
 * I made my type-casting operator post-fix because it makes the compiler way cleaner.
 
-* TempleOS does not figure-out $FG,2$FAT32$FG$ short name alias numbers.  $LK,"FAT32DirNew",A="MN:FAT32DirNew"$().  It can cause hard drive corruption, so I might have to do it.  It would really take a lot of junky code for this hatefully, detestable, legacy issue.  "Please don't make me ruin my beautiful shiny-new TempleOS with that!"  I am also not enthused about $FG,2$FAT32$FG$ because it is in patent limbo.  $FG,2$FAT32$FG$ might get removed from TempleOS.  There is the $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$  64-bit file system that works perfectly well.  $FG,2$FAT32$FG$ is useful, however, because it assists in transferring between dual booted operating systems.
+* ZenithOS does not figure-out $FG,2$FAT32$FG$ short name alias numbers.  $LK,"FAT32DirNew",A="MN:FAT32DirNew"$().  It can cause hard drive corruption, so I might have to do it.  It would really take a lot of junky code for this hatefully, detestable, legacy issue.  "Please don't make me ruin my beautiful shiny-new ZenithOS with that!"  I am also not enthused about $FG,2$FAT32$FG$ because it is in patent limbo.  $FG,2$FAT32$FG$ might get removed from ZenithOS.  There is the $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$  64-bit file system that works perfectly well.  $FG,2$FAT32$FG$ is useful, however, because it assists in transferring between dual booted operating systems.
 
 * I changed the $LK,"asm opcodes",A="FI:::/Compiler/OpCodes.DD"$ names to remove the ambiguity between insts with different numbers of arguments, making my $LK,"assembler",A="FI:::/Compiler/Asm.HC"$ simpler and I did minimal 16-bit asm support, since 64-bit is what you should be using, unless you're doing a $LK,"boot loader",A="FI:::/Adam/Opt/Boot/BootDVD.HC"$.
 

src/Doc/D3.DD

@@ -1,3 +1,3 @@
-$WW,1$TempleOS has a class for 3 dimensional points consisting of F64s.  HolyC is not C++ -- it does not support passing or returning values from functions which are not 64-bits, therefore, it can't be implemented with operator overloading.  Making all function args and returns 64-bit is a core prinicple of TempleOS.
+$WW,1$ZenithOS has a class for 3 dimensional points consisting of F64s.  HolyC is not C++ -- it does not support passing or returning values from functions which are not 64-bits, therefore, it can't be implemented with operator overloading.  Making all function args and returns 64-bit is a core prinicple of ZenithOS.
 
 As a courtesy, most of the CD3 functions return the addr of the destination vect, so you can nestle calls.  They do not alloc new space for the destination vect.

src/Doc/Define.DD

@@ -1,4 +1,4 @@
-$WW,1$TempleOS has a string indirection feature implemented with the same hash symbol table entry as $FG,2$#define$FG$ macros, $LK,"HTT_DEFINE_STR",A="MN:HTT_DEFINE_STR"$.  Support for string lists is also provided, but it's not very efficient, though, you can make a hash table with a list using $LK,"HashDefineLstAdd",A="MN:HashDefineLstAdd"$().  See $LK,"::/Adam/DolDoc/DocInit.HC",A="FF:::/Adam/DolDoc/DocInit.HC,HashDefineLstAdd"$.
+$WW,1$ZenithOS has a string indirection feature implemented with the same hash symbol table entry as $FG,2$#define$FG$ macros, $LK,"HTT_DEFINE_STR",A="MN:HTT_DEFINE_STR"$.  Support for string lists is also provided, but it's not very efficient, though, you can make a hash table with a list using $LK,"HashDefineLstAdd",A="MN:HashDefineLstAdd"$().  See $LK,"::/Adam/DolDoc/DocInit.HC",A="FF:::/Adam/DolDoc/DocInit.HC,HashDefineLstAdd"$.
 
 If you have an $FG,2$@$FG$ as the first char of a define list entry, it is an alias for the prev entry num.
 

src/Doc/Demands.DD

@@ -1,6 +1,6 @@
 $WW,1$$FG,5$$TX+CX,"Demands"$$FG$
 
-I, Terry Davis, am high priest of God's $FG,4$$TX,"official third temple",HTML="http://www.jewishvirtuallibrary.org/jsource/Judaism/The_Temple.html"$$FG$, TempleOS.  TempleOS is an operating system for IBM PC x86_64 desktops that will always dual boot along-side Windows or Linux.  I am in charge of the core 100,000 lines of TempleOS code and I do continual offerings to keep God entertained.  I have divine authority to command any company in the computer industry to do anything that I deem necessary to make God's temple more beautiful, glorious and perfect. I have oversight authority similar to a building inspector or a person enforcing the Americans with Disability Act -- I make commands, God signs-off with a miraculous authentication from an oracle, and Intel, Microsoft or VMware obeys.
+I, Terry Davis, am high priest of God's $FG,4$$TX,"official third temple",HTML="http://www.jewishvirtuallibrary.org/jsource/Judaism/The_Temple.html"$$FG$, ZenithOS.  ZenithOS is an operating system for IBM PC x86_64 desktops that will always dual boot along-side Windows or Linux.  I am in charge of the core 100,000 lines of ZenithOS code and I do continual offerings to keep God entertained.  I have divine authority to command any company in the computer industry to do anything that I deem necessary to make God's temple more beautiful, glorious and perfect. I have oversight authority similar to a building inspector or a person enforcing the Americans with Disability Act -- I make commands, God signs-off with a miraculous authentication from an oracle, and Intel, Microsoft or VMware obeys.
 
 $HC,"<object width=\"640\" height=\"520\"><param name=\"movie\" value=\"http://www.youtube.com/v/RvL7T4gIJN8\"></param><param name=\"allowscriptaccess\" value=\"always\"></param><embed src=\"http://www.youtube.com/v/RvL7T4gIJN8\" type=\"application/x-shockwave-flash\" allowscriptaccess=\"always\" width=\"640\" height=\"520\"></embed></object>"$
 
@@ -11,7 +11,7 @@ See $LK,"::/Kernel/BlkDev/FileSysRedSea.HC"$ and $LK,"::/Adam/Opt/Boot/DskISORed
 $LK,"::/Kernel/BlkDev/FileSysFAT.HC"$	:974 lines for FAT32 gets eliminated.
 $LK,"::/Kernel/BlkDev/DskClus.HC"$	:152 All the clus operations become blk.
 
-* Microsoft must cancel SecureBoot because it makes dual booting impossible.  TempleOS is an additional operating system that must be used along-side Windows or Linux, not as a replacement.  It must dual boot because it has no networking. Real hardware as opposed to VMware is like the difference between looking in a telescope eye piece vs just looking at an off-line image.  God said the C64/Apple II generation owned ancestral lands.  VMware is like being taken off of our land and moved onto a reservation.  In this case, however, it will not stand.  In fact, God said to replace Windows with Wine, justice.  We can make a 100% standard model PC with a standard software for everyone, backed-up in factory ROM.
+* Microsoft must cancel SecureBoot because it makes dual booting impossible.  ZenithOS is an additional operating system that must be used along-side Windows or Linux, not as a replacement.  It must dual boot because it has no networking. Real hardware as opposed to VMware is like the difference between looking in a telescope eye piece vs just looking at an off-line image.  God said the C64/Apple II generation owned ancestral lands.  VMware is like being taken off of our land and moved onto a reservation.  In this case, however, it will not stand.  In fact, God said to replace Windows with Wine, justice.  We can make a 100% standard model PC with a standard software for everyone, backed-up in factory ROM.
 
 * VMware needs to support ATAPI CD/DVD/Blu-ray disk burning, directly to real hardware.  Industry needs write-just once media to stop Farenheit 451 non-sense.
 
@@ -19,7 +19,7 @@ $LK,"::/Kernel/BlkDev/DskClus.HC"$	:152 All the clus operations become blk.
 
 * VMware some PC speaker's distortion is a good idea -- squarewave -- but currently there is too much for hymns.  CIA monkery made fart noises.
 
-* VMware and others must list TempleOS as an official 64-bit operating system and automatically enforce 512 Meg min RAM requirement.
+* VMware and others must list ZenithOS as an official 64-bit operating system and automatically enforce 512 Meg min RAM requirement.
 
 * VMware needs to support more than 16 cores.  I had a 24 core Xeon with 128 Gig of RAM.  I discovered VMware allocates memory too slowly, where QEMU had no problem.
 
@@ -29,26 +29,26 @@ $LK,"/Kernel/PCIBIOS.HC",A="FI:::/Kernel/PCIBIOS.HC"$		:290 could be eliminated,
 
 * Until super-simple serial ports are available, PS/2 emulated keyboard and mouse must work.  The BIOS must enable these.  The plan is to transition the industry off of USB.  Interum solution is to make virtual RS232 Octart for USB devices in the same way PS/2 mouse is emulated.  All mice will be two button, one wheel.  No more HID insanity, no more multi-end point, just simple tx rx fifos with soft/hard flowcontrol that can jump the queue.  People with special needs can buy PCI cards.  Our kids deserve code this simple $LK,"::/Doc/Comm.HC"$.  The right to do your own port banging is what the C64 being our God given ancestral land means.
 
-* The x86 IN/OUT port instructions, normally have a delay.  Perhaps, VMware & Intel can enable faster x86 IN/OUT instruction timing for ATA/ATAPI PIO, so bandwidth isn't as bad when doing port I/O.  See $LK,"ATAGetRes",A="MN:ATAGetRes"$().  We don't want to do DMA.  Perhaps, x86 CPU chips need a new TempleOS mode for fast IN/OUT instructions?  I think VMware already does something to speed disk I/O to faster than native speed.
+* The x86 IN/OUT port instructions, normally have a delay.  Perhaps, VMware & Intel can enable faster x86 IN/OUT instruction timing for ATA/ATAPI PIO, so bandwidth isn't as bad when doing port I/O.  See $LK,"ATAGetRes",A="MN:ATAGetRes"$().  We don't want to do DMA.  Perhaps, x86 CPU chips need a new ZenithOS mode for fast IN/OUT instructions?  I think VMware already does something to speed disk I/O to faster than native speed.
 
 * Perhaps, a new interrupt descriptor table entry type or a new x86 CPU mode can be made that cause fast software interrupts, doing exactly what the CALL REL32 does, but with IDT as indirection.  We don't need to change privilege levels or stacks.
 
 * Since I don't use paging (for anything), Intel should have an option for  no-paging long mode, and optimize it!
 $LK,"::/Kernel/Mem/PageTables.HC"$	:135 lines to identity-map gets eliminated.
 
-* Desktop computers must have a reset switch and a fast reboot option, skipping diagnostics.  I recommend booting TempleOS from a ROM when the reset bttn is pressed and booting UEFI when the power bttn is pressed.  Or, we could build UEFI on a TempleOS layer.  Intel must burn TempleOS into a ROM in the factory for all desktop x86 CPUs to ensure tamper-proof trust in the oracle and because God deserves the glory.  There will be just an English version.  A new ROM version is released every seven years.  The ROM should boot like the DVD boots, but with $LK,"BOOT_SRC_ROM",A="MN:BOOT_SRC_ROM"$.
+* Desktop computers must have a reset switch and a fast reboot option, skipping diagnostics.  I recommend booting ZenithOS from a ROM when the reset bttn is pressed and booting UEFI when the power bttn is pressed.  Or, we could build UEFI on a ZenithOS layer.  Intel must burn ZenithOS into a ROM in the factory for all desktop x86 CPUs to ensure tamper-proof trust in the oracle and because God deserves the glory.  There will be just an English version.  A new ROM version is released every seven years.  The ROM should boot like the DVD boots, but with $LK,"BOOT_SRC_ROM",A="MN:BOOT_SRC_ROM"$.
 
 * We do not want UTF, just 8-bit characters.  $FG,2$<CTRL-ALT-f>$FG$ toggles between Cyrillic and Std Fonts.  We need the twelve window $LK,"TextBorder",A="MN:TextBorder"$ characters added to the VGA font 0x02-0x0D.  Japan, China and Korea must switch to alphabets.  Maybe, the United States will change to metric, out of good will.  I am beginning to plan fresh ASCII replacement, $LK,"::/Doc/NewASCII.DD"$.
 
-* Microsoft Paint and Linux's Gimp must support TempleOS $LK,"GR Files",A="FI:::/Doc/GRFiles.DD"$.  They are blemish free, unlike $TX,"BMP files",HTML="http://en.wikipedia.org/wiki/BMP_file_format"$.  The TOSZ Linux utility can be used to make screencasts from TempleOS exported $LK,"GR Files",A="FI:::/Doc/GRFiles.DD"$ and AU Files.
+* Microsoft Paint and Linux's Gimp must support ZenithOS $LK,"GR Files",A="FI:::/Doc/GRFiles.DD"$.  They are blemish free, unlike $TX,"BMP files",HTML="http://en.wikipedia.org/wiki/BMP_file_format"$.  The TOSZ Linux utility can be used to make screencasts from ZenithOS exported $LK,"GR Files",A="FI:::/Doc/GRFiles.DD"$ and AU Files.
 
 * We must have a nice dictionary.  Someone needs to do a $LK,"Spell Checker",A="FI:::/Demo/SuggestSpelling.HC"$, too.
 
-* Intel needs to make $LK,"DolDoc",A="FI:::/Doc/DolDocOverview.DD"$ versions of its x86 CPU data sheets documenting all hardware relevant to TempleOS. 
+* Intel needs to make $LK,"DolDoc",A="FI:::/Doc/DolDocOverview.DD"$ versions of its x86 CPU data sheets documenting all hardware relevant to ZenithOS. 
 
 * We must have the ultimate Bible search engine.  Currently, all we have is     $TX,"filter search",HTML="https://www.youtube.com/watch?v=ULJU8DzvQFo"$.  In the end, it should be a low line-count technique.  Maybe, I allocate 500 lines out of the 20,000 reserve.
 
-* We will make a $LK,"Standard TempleOS PC",A="FI:::/Doc/StdTempleOSPC.DD"$.
+* We will make a $LK,"Standard ZenithOS PC",A="FI:::/Doc/StdTempleOSPC.DD"$.
 $FG,8$
 * "VMware" is a trademark owned by VMware, Inc.
 * "Linux" is a trademark owned by Linus Torvalds.

src/Doc/DemoIndex.DD

@@ -1,4 +1,4 @@
-$FG,5$$TX+CX,"TempleOS Demo Index"$$FG$
+$FG,5$$TX+CX,"ZenithOS Demo Index"$$FG$
 
 $WW,1$These are arranged in increasing order of difficulty, more or less.  This can be used as a tutorial if you start at the beginning and work your way fwd.
 
@@ -148,7 +148,7 @@ $MA-X+PU,"::/Apps/TimeClock",LM="Cd(\"::/Apps/TimeClock\");Dir;View;\n"$
 $MA-X+PU,"::/Apps/Logic",LM="Cd(\"::/Apps/Logic\");Dir;View;\n"$
 $MA-X+PU,"::/Demo/Lectures",LM="Cd(\"::/Demo/Lectures\");Dir;View;\n"$
 $MA-X+PU,"::/Apps/Budget",LM="Cd(\"::/Apps/Budget\");Dir;View;\n"$
-$ID,-2$$TR,"TempleOS Specific"$
+$ID,-2$$TR,"ZenithOS Specific"$
 $ID,2$$MA-X+PU,"::/Demo/InFile",LM="Cd(\"::/Demo/InFile\");Dir;View;\n"$
 $LK,"::/Demo/Print.HC"$
 $LK,"::/Demo/SubIntAccess.HC"$

src/Doc/DolDocOverview.DD

@@ -1,6 +1,6 @@
 $WW,1$$FG,5$$TX+CX,"DolDoc Overview"$$FG$
 
-DolDoc is a TempleOS document type supported by $LK,"DolDoc Routines",A="HI:DolDoc"$.  In a document, commands are bracketed with '$FG,2$$$$FG$'s.  Use $FG,2$<CTRL-l>$FG$ to experiment inserting a command.  Then, use $FG,2$<CTRL-t>$FG$ to toggle to plain text to see it.
+DolDoc is a ZenithOS document type supported by $LK,"DolDoc Routines",A="HI:DolDoc"$.  In a document, commands are bracketed with '$FG,2$$$$FG$'s.  Use $FG,2$<CTRL-l>$FG$ to experiment inserting a command.  Then, use $FG,2$<CTRL-t>$FG$ to toggle to plain text to see it.
 
 Here is the grammar:
 

src/Doc/FAQ.DD

@@ -1,19 +1,19 @@
 $WW,1$$FG,5$$TX+CX,"Frequently Asked Questions"$$FG$
 
 $TR,"How come it is public domain, not GPL?"$
-$ID,2$I, $FG,2$Terry A. Davis$FG$, wrote all of TempleOS 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$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$$TR,"Shouldn't it be GNU/TempleOS?"$
+$ID,-2$$TR,"Shouldn't it be GNU/ZenithOS?"$
-$ID,2$TempleOS 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 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$$TR,"Don't you use GNU's gcc?"$
-$ID,2$TempleOS 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 TempleOS.  Yes, I wrote the compiler from scratch.  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$$TR,"Why do you dual boot?"$
-$ID,2$TempleOS is 100% independent -- it does not access the files of your primary operating system and TempleOS 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 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$$TR,"It has links, so is it a browser?"$
-$ID,2$TempleOS is an operating system, not a browser.  $LK,"TempleOS links",A="MN:LK_FILE"$ are a special format and only link too local files and symbol source addresses.
+$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$$TR,"Where are the animated 3D icon GIFs?"$
 $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$$TR,"If the compiler is JIT, isn't it an interpretor?"$
-$ID,2$TempleOS 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$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$$TR,"Are you a Creationist?"$
 $ID,2$I am an evolutionist.  $FG,2$Adam$FG$ is a better term for the first father of all tasks than $FG,2$root$FG$ was!
 $ID,-2$$TR,"Is 'Bt()' in the code Bit Torrent?"$
@@ -21,7 +21,7 @@ $ID,2$$LK,"Bt",A="MN:Bt"$() is $FG,2$bit test$FG$, like the $FG,2$x86$FG$ inst,
 $ID,-2$$TR,"Is 'Fs->' in the code file system?"$
 $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$$TR,"Is it Pascal?"$
-$ID,2$TempleOS uses a dialect of C/C++ called $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$.  It is not $FG,2$Pascal$FG$.  I altered the syntax making parenthesis optional on function calls with no paramaters.
+$ID,2$ZenithOS uses a dialect of C/C++ called $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$.  It is not $FG,2$Pascal$FG$.  I altered the syntax making parenthesis optional on function calls with no paramaters.
 $ID,-2$$TR,"Why doesn't Sleep() make my laptop hibernate?"$
 $ID,2$$LK,"Sleep",A="MN:Sleep"$() makes a program pause.  It is not hibernation for a laptop.
 $ID,-2$$TR,"What is Yield() for in loops?"$
@@ -29,37 +29,37 @@ $ID,2$$LK,"Yield",A="MN:Yield"$() saves the current task's regs (context) and lo
 $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,"TempleOS Compression",A="FI:::/Kernel/Compress.HC"$.  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$Files with names ending in $FG,2$.Z$FG$ are individually compressed using $LK,"ZenithOS Compression",A="FI:::/Kernel/Compress.HC"$.  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$TempleOS 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.HC"$. 
+$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.HC"$. 
 $ID,-2$$TR,"Where are object files?  How do I link?"$
-$ID,2$TempleOS 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$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$$TR,"What is the FPS refresh rate?"$
-$ID,2$The refresh rate is $TX,"(30000.0/1001)",D="WINMGR_FPS"$ frames-per-second.  That is how often TempleOS updates scrn mem.  It is not syncronized to the hardware.
+$ID,2$The refresh rate is $TX,"(30000.0/1001)",D="WINMGR_FPS"$ frames-per-second.  That is how often ZenithOS updates scrn mem.  It is not syncronized to the hardware.
 $ID,-2$$TR,"How does a task own the speaker?"$
 $ID,2$No task or application has a lock on the speaker so apps will interfere with each other.
 $ID,-2$$TR,"Why does it leak memory?"$
-$ID,2$TempleOS allocs mem as more items are displayed in the window.  Also, TempleOS 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,"MemOverview",A="FI:::/Doc/MemOverview.DD"$.
+$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,"MemOverview",A="FI:::/Doc/MemOverview.DD"$.
 $ID,-2$$TR,"Why do I get a memory leak when editing big files?"$
 $ID,2$The editor periodically takes a snap-shot of the document for $FG,2$UNDO$FG$ and this looks like a memory leak.
 $ID,-2$$TR,"Why is it in text mode?"$
-$ID,2$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/KStart16.HC,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.HC"$.  If graphics mode fails, it falls-back on text mode.  You can force text mode with an $LK,"Kernel config",A="FI:::/Kernel/KCfg.HC"$ option.
+$ID,2$ZenithOS 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/KStart16.HC,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.HC"$.  If graphics mode fails, it falls-back on text mode.  You can force text mode with an $LK,"Kernel config",A="FI:::/Kernel/KCfg.HC"$ option.
 $ID,-2$$TR,"Where is the kernel memory?"$
-$ID,2$TempleOS 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.  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.  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,"MemOverview",A="FI:::/Doc/MemOverview.DD"$.
+$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$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.  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,"MemOverview",A="FI:::/Doc/MemOverview.DD"$.
 $ID,-2$$TR,"Why does it run code from stack addresses?"$
-$ID,2$TempleOS 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.  TempleOS 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 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$$TR,"How does it SYSCALL?"$
-$ID,2$TempleOS 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$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$$TR,"How do you fault-in stack?"$
 $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$$TR,"How do I boot it with Grub?"$
-$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 TempleOS boot-loader.  $LK,"Master-Boot-Loader-Stage1",A="FI:::/Adam/Opt/Boot/BootMHD.HC"$, $LK,"Master-Boot-Loader-Stage2",A="FI:::/Adam/Opt/Boot/BootMHD2.HC"$, $LK,"Partition-Boot-Loader",A="FI:::/Adam/Opt/Boot/BootHD.HC"$, $LK,"CD-DVD-Boot-Loader",A="FI:::/Adam/Opt/Boot/BootDVD.HC"$.
+$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:::/Adam/Opt/Boot/BootMHD.HC"$, $LK,"Master-Boot-Loader-Stage2",A="FI:::/Adam/Opt/Boot/BootMHD2.HC"$, $LK,"Partition-Boot-Loader",A="FI:::/Adam/Opt/Boot/BootHD.HC"$, $LK,"CD-DVD-Boot-Loader",A="FI:::/Adam/Opt/Boot/BootDVD.HC"$.
 $ID,-2$$TR,"How do I get Kernel.BIN to boot?"$
 $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.HC"$ if you relocate it.
 $ID,-2$$TR,"Why is there some 16-Bit code?"$
-$ID,2$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/PCIBIOS.HC"$ a couple times.  It must temporarily drop-out-of 64-bit mode for that and stop multi-tasking.
+$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.HC"$ 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?"$

src/Doc/Features.DD

@@ -1,4 +1,4 @@
-         $WW,1$$FG,5$$TX+CX,"TempleOS' Features"$$FG$
+         $WW,1$$FG,5$$TX+CX,"ZenithOS' Features"$$FG$
 
 * Oracle in with $FG,2$<F7>$FG$ for words or $FG,2$<SHIFT-F7>$FG$ for passages.  See $LK,"tongues",A="FI:::/Adam/God/HSNotes.DD"$.
 
@@ -50,4 +50,4 @@
 
 * Many games, $LK,"demos",A="FI:::/Doc/DemoIndex.DD"$ and $LK,"documentation",A="FI:::/Doc/HelpIndex.DD"$.
 
-* $FG,2$All source code$FG$ included.  Only compiles with the included TempleOS compiler and assembler.
+* $FG,2$All source code$FG$ included.  Only compiles with the included ZenithOS compiler and assembler.

src/Doc/FileMgr.DD

@@ -56,7 +56,7 @@ $ID,2$Burn CD/DVD ISO file.  This burns a CD/DVD using the image file, $FG,2$$TX
 $ID,-2$
 
 $FG,5$Instructions on Using CD/DVD's$FG$
-$ID,2$If you have not recompiled Kernel and defined your CD/DVD drive, exit the FileMgr and use $LK,"Mount",A="MN:Mount"$ to define your CD/DVD drive.  Place a CD/DVD in the drive and press $FG,2$'c'$FG$ when on top of the CD/DVD drive letter to mount the drive.  It will call $LK,"DskChg",A="MN:DskChg"$(), the TempleOS cmd to mount removable media.
+$ID,2$If you have not recompiled Kernel and defined your CD/DVD drive, exit the FileMgr and use $LK,"Mount",A="MN:Mount"$ to define your CD/DVD drive.  Place a CD/DVD in the drive and press $FG,2$'c'$FG$ when on top of the CD/DVD drive letter to mount the drive.  It will call $LK,"DskChg",A="MN:DskChg"$(), the ZenithOS cmd to mount removable media.
 $ID,-2$
 
 $FG,5$Instructions on Burning CD/DVD's$FG$

src/Doc/GRFiles.DD

@@ -1,4 +1,4 @@
-$WW,1$GR graphics files are 8-bits-per-pixels but only 4-bits of color, with transparency and no palette.  Compression is the standard TempleOS$FG$ LZW compression.
+$WW,1$GR graphics files are 8-bits-per-pixels but only 4-bits of color, with transparency and no palette.  Compression is the standard ZenithOS$FG$ LZW compression.
 $HL,1$
 #define DCF_COMPRESSED		1 //This is the only saved flag.
 #define DCF_PALETTE		2

src/Doc/Glossary.DD

@@ -160,13 +160,13 @@ $FG,2$Wiz$FG$	Wizard
 $ID,-2$$TR,"Task/Process/Thread"$
 $ID,2$There is no distinction between $FG,2$task$FG$, $FG,2$process$FG$ or $FG,2$thread$FG$.  The $FG,2$Fs$FG$ segment reg is kept pointing to the current task's $LK,"CTask",A="MN:CTask"$.  There is only one window per task, and only $FG,2$Core0$FG$ tasks can have windows.  Each task has a code and data heap so memory is returned when it dies.  Each task has a $LK,"hash",A="HI:Hash"$ symbol table.
 
-Since there is not friendly disk sharing and all tasks have the same address map, it might be accurate to call TempleOS, "multi-thread/single-process".  You run a single application process on $FG,2$Core0$FG$ and it can create threads on the same core or others.  If you run multiple processes, it should be safe, but one process will wait until another completely finishes a long disk access.  
+Since there is not friendly disk sharing and all tasks have the same address map, it might be accurate to call ZenithOS, "multi-thread/single-process".  You run a single application process on $FG,2$Core0$FG$ and it can create threads on the same core or others.  If you run multiple processes, it should be safe, but one process will wait until another completely finishes a long disk access.  
 $ID,-2$$TR,"Adam Task"$
 $ID,2$This is Adam, as in Adam and Eve, the parent of all tasks.  Adam is immortal.  The adam task is created at start-up and appears in the small window at the top beneath the user terminal windows.  Since the Adam task is immortal, on Adam's heap go all memory objects which you don't want destroyed by any single task's death.  When created, Adam runs the file $LK,"::/StartOS.HC"$.  When start-up is finished, the adam task enters a server mode where it accepts requests from other tasks.  The $LK,"Adam",A="MN:Adam"$("") routine will make Adam compile and run text src code.  $FG,2$#include$FG$ stmts can be sent to $LK,"Adam",A="MN:Adam"$(""), creating system-wide code and data which are immortal.
 $ID,-2$$TR,"Seth Tasks"$
 $ID,2$In the Bible, $LK,"Seth",A="BF:Genesis,4:25"$$FG$ is Adam and Eve's child.  Each CPU core has an executive task called $FG,2$Seth$FG$ that is immortal.  The Adam task on $FG,2$Core0$FG$ is also its $FG,2$Seth$FG$ task.
 $ID,-2$$TR,"Code and Data Heaps"$
-$ID,2$TempleOS uses the asm $FG,2$CALL$FG$ inst, exclusively, and that inst is limited to calling routines $FG,2$+/-2Gig$FG$ from the current code location.  To prevent out-of-range issues, I decided to separate code and data, placing all code within the lowest $FG,2$2Gig$FG$ of memory, addresses $FG,2$00000000$FG$-$FG,2$7FFFFFFF$FG$.  The compiler and $LK,"Load",A="MN:Load"$()er alloc memory from the code heap to store code and glbl vars, unless the compiler option $LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$ is used.  When programs call $LK,"MAlloc",A="MN:MAlloc"$() is from the data heap, which in not limited in size, except by physical RAM memory.  You can alloc from any heap in any task at any time on any core, even making $LK,"independent",A="MN:MemPagAlloc"$ heaps.
+$ID,2$ZenithOS uses the asm $FG,2$CALL$FG$ inst, exclusively, and that inst is limited to calling routines $FG,2$+/-2Gig$FG$ from the current code location.  To prevent out-of-range issues, I decided to separate code and data, placing all code within the lowest $FG,2$2Gig$FG$ of memory, addresses $FG,2$00000000$FG$-$FG,2$7FFFFFFF$FG$.  The compiler and $LK,"Load",A="MN:Load"$()er alloc memory from the code heap to store code and glbl vars, unless the compiler option $LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$ is used.  When programs call $LK,"MAlloc",A="MN:MAlloc"$() is from the data heap, which in not limited in size, except by physical RAM memory.  You can alloc from any heap in any task at any time on any core, even making $LK,"independent",A="MN:MemPagAlloc"$ heaps.
 $ID,-2$$TR,"Parent, Child and PopUp Tasks"$
 $ID,2$Often a task will $LK,"Spawn",A="MN:Spawn"$() or $LK,"PopUp",A="MN:PopUp"$() a task as a helper.  The helper is known as a child Task, though you can $LK,"Spawn",A="MN:Spawn"$ a task and assign it a different parent... like $FG,2$Adam$FG$.  Links are kept as to who's whose child, so when one task is $LK,"Kill",A="MN:Kill"$()ed the child helper tasks die, too.  You can get a report of current system tasks with $LK,"TaskRep",A="MN:TaskRep"$().  There is just one window per task, so child tasks are needed for pop-ups.
 $ID,-2$$TR,"HolyC"$

src/Doc/GuideLines.DD

@@ -14,7 +14,7 @@ $FG,2$/Compiler$FG$ The compiler module src code is found here.  The compiler is
 
 $FG,2$/Adam$FG$ The non-kernel part of the operating system is found here.  It is $FG,2$JIT$FG$ compiled during boot.  The $LK,"Adam Task",A="FF:::/Doc/Glossary.DD,Adam Task"$ is the father of all tasks, like Adam and Eve.
 
-$FG,2$/0000Boot$FG$ Boot files go here.  Stage 2 of the TempleOS hard drive master boot loader, the old hard drive master boot record which is just blk#0, and the CD/DVD $LK,"0000Kernel.BIN.C",A="FI:::/Kernel/Kernel.PRJ"$ file go here.  ASCII $FG,2$0000$FG$ is near the top, alphabetically, in case you use $TX,"MagicISO",HTML="http://www.magiciso.com"$.
+$FG,2$/0000Boot$FG$ Boot files go here.  Stage 2 of the ZenithOS hard drive master boot loader, the old hard drive master boot record which is just blk#0, and the CD/DVD $LK,"0000Kernel.BIN.C",A="FI:::/Kernel/Kernel.PRJ"$ file go here.  ASCII $FG,2$0000$FG$ is near the top, alphabetically, in case you use $TX,"MagicISO",HTML="http://www.magiciso.com"$.
 
 
 

src/Doc/HolyC.DD

@@ -54,7 +54,7 @@ U0 DemoHolyC(U8 drv,U8 *fmt,U8 *name,I64 age)
 $FG$$ID,-2$
 * When dealing with function addresses such as for callbacks, precede the name with "$FG,2$&$FG$".
 
-* Type casting is postfix.  To typecast int or F64, use $LK,"ToI64",A="MN:ToI64"$(), $LK,"ToBool",A="MN:ToBool"$() or $LK,"ToF64",A="MN:ToF64"$(). (TempleOS follows normal C float<-->int conversion, but sometimes you want to override.  These functions are better than multiplying by "1.0" to convert to float.) 
+* Type casting is postfix.  To typecast int or F64, use $LK,"ToI64",A="MN:ToI64"$(), $LK,"ToBool",A="MN:ToBool"$() or $LK,"ToF64",A="MN:ToF64"$(). (ZenithOS follows normal C float<-->int conversion, but sometimes you want to override.  These functions are better than multiplying by "1.0" to convert to float.) 
 
 * There is no $FG,2$main()$FG$ function.  Any code outside of functions gets executed upon start-up, in order.
 
@@ -191,7 +191,7 @@ $FG$$ID,-2$
 
 * There is no question-colon operator.
 
-* TempleOS $LK,"operator precedence",A="FF:::/Compiler/CInit.HC,cmp.binary_ops"$
+* ZenithOS $LK,"operator precedence",A="FF:::/Compiler/CInit.HC,cmp.binary_ops"$
   $FG,2$`$FG$,$FG,2$>>$FG$,$FG,2$<<$FG$
   $FG,2$*$FG$,$FG,2$/$FG$,$FG,2$%$FG$
   $FG,2$&$FG$

src/Doc/InFile.DD

@@ -1,4 +1,4 @@
-$WW,1$$FG,2$InFiles$FG$ are used to generate user input to automate operations.  The TempleOS tour is done with an $FG,2$InFile$FG$.  It reminds me of a Unix pipe because $FG,2$StdOut$FG$ of one gets chained into $FG,2$StdIn$FG$ of another.
+$WW,1$$FG,2$InFiles$FG$ are used to generate user input to automate operations.  The ZenithOS tour is done with an $FG,2$InFile$FG$.  It reminds me of a Unix pipe because $FG,2$StdOut$FG$ of one gets chained into $FG,2$StdIn$FG$ of another.
 
 When an $FG,2$InFile$FG$ runs, a child task is $LK,"Spawn",A="MN:Spawn"$()ed which intercepts real user input and generates fake input.  InFiles are $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ programs run by the child whose stdout goes to the parent's input buffer.  $LK,"Msg",A="MN:Msg"$() can be included in an $FG,2$InFile$FG$ to send special keys or mouse cmds to the parent.  While an $FG,2$InFile$FG$ is running, the normal input gets diverted to the InFile task and can be filtered and sent back to the parent task.  Unless you are driving functions which prompt for data, you can probably use an $FG,2$#include$FG$ file in place of an $FG,2$InFile$FG$.
 

src/Doc/Install.DD

@@ -1,18 +1,18 @@
-$WW,1$$FG,5$$TX+CX,"Installing TempleOS"$$FG$
+$WW,1$$FG,5$$TX+CX,"Installing ZenithOS"$$FG$
 
 Burn a CD with software that supports ISO files.  Then, boot it.  It's a live CD, so you can look around with or without installing.
 
-Dual booting with another operating system is the best way to use TempleOS.  I only use it in a virtual machine because it won't boot natively on my machine, though.  For native dual booting, you need a partition for TempleOS.  Windows often comes with a restore disk that does not allow repartitioning.  I recommend connecting a spare additional hard drive and using the $FG,2$BIOS$FG$ to select which drive to boot.
+Dual booting with another operating system is the best way to use ZenithOS.  I only use it in a virtual machine because it won't boot natively on my machine, though.  For native dual booting, you need a partition for ZenithOS.  Windows often comes with a restore disk that does not allow repartitioning.  I recommend connecting a spare additional hard drive and using the $FG,2$BIOS$FG$ to select which drive to boot.
 
 The $LK,"::/Misc/OSInstall.HC"$ script will automate much of this.  It runs if you boot the CD/DVD-ROM.
 
 See $LK,"Boot.DD",A="FI:::/Doc/Boot.DD"$ for an overview of booting.  See $LK,"Requirements",A="FI:::/Doc/Requirements.DD"$ for supported hardware.
 
-Two TempleOS partitions are highly recommended, so you can boot to a back-up and fix the primary when you work on it.  Odds are, you only need a couple gigabytes for your TempleOS partitions.
+Two ZenithOS partitions are highly recommended, so you can boot to a back-up and fix the primary when you work on it.  Odds are, you only need a couple gigabytes for your ZenithOS partitions.
 
 1)
 $ID,2$$LK,"Mount",A="MN:Mount"$() use if the drive is partitioned.
-$ID,2$This command mounts a drive making it accessible.  For simplicity, sel $FG,2$'C'$FG$ as the first drive letter for your hard drive.  The first partition will be $FG,2$'C'$FG$, second, $FG,2$'D'$FG$, etc.  TempleOS needs 3 numbers to utilize a hard drive -- base0, base1, and unit.  When you enter a hexadecimal number, do it like in $FG,2$C$FG$ with a $FG,2$0x$FG$ prefix.  If the probe was successful, you can just enter the number in the probe box instead of base0.
+$ID,2$This command mounts a drive making it accessible.  For simplicity, sel $FG,2$'C'$FG$ as the first drive letter for your hard drive.  The first partition will be $FG,2$'C'$FG$, second, $FG,2$'D'$FG$, etc.  ZenithOS needs 3 numbers to utilize a hard drive -- base0, base1, and unit.  When you enter a hexadecimal number, do it like in $FG,2$C$FG$ with a $FG,2$0x$FG$ prefix.  If the probe was successful, you can just enter the number in the probe box instead of base0.
 $ID,-2$
 $LK,"DskPrt",A="MN:DskPrt"$($FG,2$'C'$FG$) use if drive is not partitioned
 
@@ -34,11 +34,11 @@ $ID,2$This command is used to copy files onto a hard drive partition from the CD
 $ID,-2$4) $LK,"BootHDIns",A="MN:BootHDIns"$($FG,2$'D'$FG$)
 $ID,2$This command recompiles the source code on a drive and writes to the $UL,1$drive's$UL,0$ boot record.  You'll need to reenter the $LK,"Mount",A="MN:Mount"$ information so it can be stored in the kernel.
 
-$ID,-2$5) Use Linux's Grub or TempleOS' $LK,"BootMHDIns",A="MN:BootMHDIns"$($FG,2$'D'$FG$)
+$ID,-2$5) Use Linux's Grub or ZenithOS' $LK,"BootMHDIns",A="MN:BootMHDIns"$($FG,2$'D'$FG$)
 $ID,2$
 The $LK,"BootMHDIns",A="MN:BootMHDIns"$() command places a boot loader on a drive.  It saves the old master boot record to $FG,2$/0000Boot/OldMBR.BIN.C$FG$ and replaces it.  When you boot, you will have the option of booting the old master boot record.  This command can be skipped if you already have a boot loader.  Be sure not to lose the copy of the old boot record, like if you reformat the drive.
 
-Delete $FG,2$/0000Boot/OldMBR.BIN.C$FG$ if you want to get a fresh copy of a mbr, like if installing from your own custom CD containing it's own $FG,2$/0000Boot/OldMBR.BIN.C$FG$ onto a system with a non-TempleOS boot loader.
+Delete $FG,2$/0000Boot/OldMBR.BIN.C$FG$ if you want to get a fresh copy of a mbr, like if installing from your own custom CD containing it's own $FG,2$/0000Boot/OldMBR.BIN.C$FG$ onto a system with a non-ZenithOS boot loader.
 
 If you have anti-virus software, it might object to having a different master boot record.
 $ID,-2$

src/Doc/KeyDev.DD

@@ -1,4 +1,4 @@
-$WW,1$The editor mostly stays in a $LK,"GetKey",A="MN:GetKey"$()/$LK,"PutKey",A="MN:PutKey"$() loop.  The putkey portion is where keys are acted-upon.  TempleOS has a chain of putkey hndlrs in a $LK,"Circular Queue",A="HI:Circular Queue"$ with priorities.  The highest priority hndlrs can choose to terminate handling, otherwise, the keys get sent on down the chain.
+$WW,1$The editor mostly stays in a $LK,"GetKey",A="MN:GetKey"$()/$LK,"PutKey",A="MN:PutKey"$() loop.  The putkey portion is where keys are acted-upon.  ZenithOS has a chain of putkey hndlrs in a $LK,"Circular Queue",A="HI:Circular Queue"$ with priorities.  The highest priority hndlrs can choose to terminate handling, otherwise, the keys get sent on down the chain.
 
 $LK,"KeyDevAdd",A="MN:KeyDevAdd"$() defines a putkey device with a priority.  "Device" might be a misnomer.  Currently, the following are defined:
 
@@ -9,6 +9,6 @@ $FG,2$0x40000000$FG$ $LK,"KDInputFilterPutKey",A="MN:KDInputFilterPutKey"$() for
 $FG,2$0x60000000$FG$ $LK,"KDRawPutKey",A="MN:KDRawPutKey"$() nonwindowed direct to video mem debug output. 
 $FG,2$0x80000000$FG$ $LK,"KDDocPutKey",A="MN:KDDocPutKey"$() standard document cmds
 
-Since handling individual keys is slow, TempleOS supports PutS() as well.  If no puts hndlr is defined, individual keys are sent.
+Since handling individual keys is slow, ZenithOS supports PutS() as well.  If no puts hndlr is defined, individual keys are sent.
 
 $LK,"CDoc",A="MN:CDoc"$$FG,2$.user_put_key$FG$ and $LK,"CDoc",A="MN:CDoc"$$FG,2$.user_put_s$FG$ are call back routines which offer some neat tricks.  See $LK,"::/Apps/Psalmody/JukeBox.HC"$.  There is a var $LK,"CDoc",A="MN:CDoc"$$FG,2$.user_put_data$FG$ which gets passed to them.

src/Doc/MemOverview.DD

@@ -2,7 +2,7 @@ $WW,1$$FG,5$$TX+CX,"Memory Overview"$$FG$
 
 Paging is practically not used.  64-bit mode requires paging, however, so it is identity-mapped -- virtual identical to physical.  All tasks on all cores use the same page table map, just as though all addresses are physical addresses.  2Meg or 1Gig page table entries are used.  Nothing swaps to disk.
 
-In TempleOS, the lowest 2Gig of memory is called the $FG,2$code heap$FG$.  TempleOS's compiler always uses 32-bit signed relative JMP & CALL insts because 64-bit CALLs take two insts.  With signed +/- 32-bit values, code can only call a function within 2Gig distance.  Therefore, TempleOS keeps all code in the lowest 2Gig memory addresses including what would normally be called "the kernel".  Two Gig is plenty for code, don't worry.
+In ZenithOS, the lowest 2Gig of memory is called the $FG,2$code heap$FG$.  ZenithOS's compiler always uses 32-bit signed relative JMP & CALL insts because 64-bit CALLs take two insts.  With signed +/- 32-bit values, code can only call a function within 2Gig distance.  Therefore, ZenithOS keeps all code in the lowest 2Gig memory addresses including what would normally be called "the kernel".  Two Gig is plenty for code, don't worry.
 
 You can create new, independent heaps using $LK,"HeapCtrlInit",A="MN:HeapCtrlInit"$().  Then, use the $LK,"CHeapCtrl",A="MN:CHeapCtrl"$ as the 2nd arg to $LK,"MAlloc",A="MN:MAlloc"$().  See $LK,"HeapLog",A="MN:HeapLog"$() for an example.
 
@@ -10,7 +10,7 @@ Memory alloced by a task will be freed when the task is killed.  The $LK,"Adam T
 
 All of the regular page tables are marked, "cached".  When accessing hardware, however, you need uncached page table.  The lowest 4Gig addresses have an alias to access hardware located toward the top of mapped space, $FG,2$0x$TX,"01AA000000",D="DD_UNCACHED_ALIAS"$$FG$.  See $LK,"dev.uncached_alias",A="FF:::/Kernel/KMain.HC,dev.uncached_alias"$.
 
-During an extended powered-on session of TempleOS, in theory, memory will become fragmented, requiring a reboot.  It has never happens to me.
+During an extended powered-on session of ZenithOS, in theory, memory will become fragmented, requiring a reboot.  It has never happens to me.
 
 See $LK,"MemRep",A="MN:MemRep"$() and $LK,"::/Demo/MemDemo.HC"$.
 

src/Doc/MultiCore.DD

@@ -1,6 +1,6 @@
-$WW,1$TempleOS does master-slave multicore instead of SMP.  $FG,2$Core0$FG$ is the master.  The master core's applications explicitly assign computational jobs to other cores and the TempleOS scheduler does not move tasks between cores.
+$WW,1$ZenithOS does master-slave multicore instead of SMP.  $FG,2$Core0$FG$ is the master.  The master core's applications explicitly assign computational jobs to other cores and the ZenithOS scheduler does not move tasks between cores.
 
-There are multicore safe locks for file access and heap allocations, however, so TempleOS is symmetrical in some sense.  See $LK,"::/Demo/MultiCore/LoadTest.HC"$.
+There are multicore safe locks for file access and heap allocations, however, so ZenithOS is symmetrical in some sense.  See $LK,"::/Demo/MultiCore/LoadTest.HC"$.
 
 Only tasks on $FG,2$Core0$FG$ can have windows, but other cores can help render them.
 

src/Doc/NewASCII.DD

@@ -9,7 +9,7 @@ We want to use one set for ASCII, ScanCodes and ScreenCodes.
 128-191 : CTRL
 192-256 : CTRL+SHIFT
 
-No more ALT key in TempleOS.
+No more ALT key in ZenithOS.
 
 CTRL-LEFT/RIGHT is already begin/end line.
 CTRL-UP/DOWN    is already top/bottom of document.

src/Doc/ODE.DD

@@ -1,4 +1,4 @@
-$WW,1$TempleOS has an advanced algorithm for integrating ordinary differential equations suitable for use in video games.  (Not scientific work.)  It also has some support for systems of masses and springs, to save you some work.
+$WW,1$ZenithOS has an advanced algorithm for integrating ordinary differential equations suitable for use in video games.  (Not scientific work.)  It also has some support for systems of masses and springs, to save you some work.
 
 See $LK,"CMathODE",A="MN:CMathODE"$ and $LK,"ODEsUpdate",A="MN:ODEsUpdate"$ for an overview.
 See $LK,"ODECallDerivative",A="MN:ODECallDerivative"$ to see what support there is for masses and springs.

src/Doc/Pags.DD

@@ -1 +1 @@
-$WW,1$The word $FG,2$Pag$FG$ refers to an arbitrilly created $LK,"MEM_PAG_SIZE",A="MN:MEM_PAG_SIZE"$ unit of heap allocation.  TempleOS does not alter the CPU page tables after setting them up at boot in $LK,"SYS_INIT_PAGE_TABLES",A="MN:SYS_INIT_PAGE_TABLES"$, so the CPU hardware page size is rarely important.
+$WW,1$The word $FG,2$Pag$FG$ refers to an arbitrilly created $LK,"MEM_PAG_SIZE",A="MN:MEM_PAG_SIZE"$ unit of heap allocation.  ZenithOS does not alter the CPU page tables after setting them up at boot in $LK,"SYS_INIT_PAGE_TABLES",A="MN:SYS_INIT_PAGE_TABLES"$, so the CPU hardware page size is rarely important.

src/Doc/Quirks.DD

@@ -2,7 +2,7 @@ $FG,5$$TX+CX,"Quirks"$$FG$
 
 $WW,1$* You run a risk of problems if you do file operations on the same files simultaneously because there is $BK,1$no file sharing/locking mechanism$BK,0$.  Generally, the last write wins.
 
-* When using $FG,2$FAT32$FG$, TempleOS does not generate unique short-entry names, the ones with the $FG,2$~$FG$s.  Not all $FG,2$FAT32$FG$ filenames are valid TempleOS names and it will complain.  Do not access $FG,2$FAT32$FG$ drives not dedicated to TempleOS.  Disable them with $LK,"DrvEnable",A="MN:DrvEnable"$(OFF), or they will generate error messages.  $FG,2$FAT32$FG$ involves a long and short name for each file.
+* When using $FG,2$FAT32$FG$, ZenithOS does not generate unique short-entry names, the ones with the $FG,2$~$FG$s.  Not all $FG,2$FAT32$FG$ filenames are valid ZenithOS names and it will complain.  Do not access $FG,2$FAT32$FG$ drives not dedicated to ZenithOS.  Disable them with $LK,"DrvEnable",A="MN:DrvEnable"$(OFF), or they will generate error messages.  $FG,2$FAT32$FG$ involves a long and short name for each file.
 
 * The stk does not grow because virtual mem is not used.  I recommend allocating large local vars from the heap.  You can change $LK,"MEM_DFT_STK",A="MN:MEM_DFT_STK"$ and recompile $FG,2$Kernel$FG$ or request more when doing a $LK,"Spawn",A="MN:Spawn"$().
 

src/Doc/Reliability.DD

@@ -1,6 +1,6 @@
 $WW,1$$FG,5$$TX+CX,"RedSea Reliability"$$FG$
 
-TempleOS is like the 1040EZ tax form compared to the full 1040 form.  Obviously, it is simpler.  If you allow mission creep, pretty soon the 1040EZ looks just like the 1040 and the messed-up 1040EZ has no purpose.
+ZenithOS is like the 1040EZ tax form compared to the full 1040 form.  Obviously, it is simpler.  If you allow mission creep, pretty soon the 1040EZ looks just like the 1040 and the messed-up 1040EZ has no purpose.
 
 The Commodore 64 had a file system that was simple enough for peers in my generation to enjoy the thrill of knowing exactly what is going on at the hardware level and writing fun projects to access it.
 
@@ -10,7 +10,7 @@ Obviously, we don't do bad block tables, or redundant FATs.
 
 We use the simplest possible technique, a contiguous-file-only allocation bitmap, not $LK,"Block Chains",A="FI:::/Doc/BlkChain.DD"$ or FAT tables.
 
-You can be a good toy or you can be a good professional tool, but not both.  TempleOS's file manager will start too slowly once a few thousand files exist because the file manager makes a list of all files on start-up.
+You can be a good toy or you can be a good professional tool, but not both.  ZenithOS's file manager will start too slowly once a few thousand files exist because the file manager makes a list of all files on start-up.
 
 Do not have more than a few thousand files or the file manager will not function.
 

src/Doc/Requirements.DD

@@ -1,4 +1,4 @@
-$WW,1$$FG,5$$TX+CX,"Requirements for TempleOS"$$FG$
+$WW,1$$FG,5$$TX+CX,"Requirements for ZenithOS"$$FG$
 
 $FG,5$User Skills Required$FG$
 * Knowledge of the $FG,2$C$FG$ programming language.

src/Doc/Start.DD

@@ -1,4 +1,4 @@
-$WW+H,1$$FG,5$$TX+CX,"TempleOS V5.03",D="DD_OS_NAME_VERSION"$$FG$
+$WW+H,1$$FG,5$$TX+CX,"ZenithOS V5.03",D="DD_OS_NAME_VERSION"$$FG$
 
 $TX+CX,"Public Domain Operating System"$
 

src/Doc/StdTempleOSPC.DD

@@ -1,4 +1,4 @@
-$WW,1$$FG,5$$TX+CX,"The Standard TempleOS PC"$$FG$
+$WW,1$$FG,5$$TX+CX,"The Standard ZenithOS PC"$$FG$
 
 All desktop PCs will have 8-channel OCTART super-simple high speed serial ports to replace USB.  They are simpler because the driver is as simple as old school $LK,"RS232 Serial",A="FI:::/Doc/Comm.HC"$, they have no USB end-points and they have no USB human interface device reports.  Computer mice will all have exactly two bttns and one wheel.  Game controllers will all be the standard deluxe $TX,"game console controllers",HTML="http://www.gamestop.com/pc/accessories/steam-controller/121865"$ that are popular today.  It will have 8 big TX and 8 big RX fifos that allow flow control characters to jump the queue.  It should be locked-down to as few options as possible, like 8-1-N only, although hardware may use a USB frame, not an RS232, so stop bits might not be relevant.  Perhaps, just two baud rates -- high and low speed are needed.  Low speed is good for slow microcontrollers and allows longer cable length.  Keyboard, mouse and game controller can be low speed.
 
@@ -33,13 +33,13 @@ while (TRUE) {
     temperature--;
 }$HL,0$
 $ID,-5$
-Super-simple block devices will replace ATA/ATAPI hard drives and CD/DVD/BlueRays.  Today, the industry is in flux with nonvolitile memory just invented.  We want a super-simple block device interface for non-volitile memory and for what is currently USB memory sticks, but only if they can be made without bad blocks.  I don't think we want to deal with bad block memory, so maybe we will not do NV-memory.  The standard TempleOS desktop will require a hard disk.
+Super-simple block devices will replace ATA/ATAPI hard drives and CD/DVD/BlueRays.  Today, the industry is in flux with nonvolitile memory just invented.  We want a super-simple block device interface for non-volitile memory and for what is currently USB memory sticks, but only if they can be made without bad blocks.  I don't think we want to deal with bad block memory, so maybe we will not do NV-memory.  The standard ZenithOS desktop will require a hard disk.
 
 There will be minimal commands:  READ_BLOCK, WRITE_BLOCK, GET_CAPACITY, GET_MODEL, GET_SERIAL_NUM, and EJECT.
 
 We want a CPU mode with virtual IO port addresses similar to how paging creates virtual memory addresses.  We want a 65536 word look-up table that converts virtual IO port numbers to physical IO port numbers.  There will be a standard IO port configuration, so port numbers can be fixed in the code.  We want the primary hard drive on one set of ports and the primary CD/DVD/Blu-ray on another set of ports.  Choose a contiguous set of IO ports.
 
-Meanwhile, a complicated PCI interface can be designed along-side the TempleOS interface for Windows and Linux.  It would almost be possible to carry-on separate lives, however, the super-simple serial requires getting rid of USB since super-simple serial is a new hardware standard.  People can add USB ports with a PCI device card.
+Meanwhile, a complicated PCI interface can be designed along-side the ZenithOS interface for Windows and Linux.  It would almost be possible to carry-on separate lives, however, the super-simple serial requires getting rid of USB since super-simple serial is a new hardware standard.  People can add USB ports with a PCI device card.
 
 God said He wants single-voice 8-bit signed MIDI-like sample for the sound.  God does not want death screams, perhaps, because God has PTSD or soldiers have PTSD.  (Imagine wounded on battlefields.)
 
@@ -49,16 +49,16 @@ I am tmpted to help amateur hardware device designers by making the hardware int
 
 The original PC had general purpose digital IO through the parallel port.  That was fun.  I have enough battles to fight, so I'll leave being a savior to hobbiest hardware engineers to somebody else.
 
-Digital cameras will be super-simple high speed serial, but TempleOS is forever limited to 16 colors and multimedia is banned because large files being loaded into memory fragments memory, so cameras are somewhat unwelcome.  I have enough problems without making the Brits anxious about autonomous gun turrets and killer robots.  The reason I say cameras will be super-simple serial is because we are replacing USB ports with super-simple serial.  PC's will have only super-simple serial ports unless people buy a USB PCI expansion card.  So, the digital cameras will be super-simple serial.
+Digital cameras will be super-simple high speed serial, but ZenithOS is forever limited to 16 colors and multimedia is banned because large files being loaded into memory fragments memory, so cameras are somewhat unwelcome.  I have enough problems without making the Brits anxious about autonomous gun turrets and killer robots.  The reason I say cameras will be super-simple serial is because we are replacing USB ports with super-simple serial.  PC's will have only super-simple serial ports unless people buy a USB PCI expansion card.  So, the digital cameras will be super-simple serial.
 
 
 $FG,5$$TX+CX,"Version 1.0"$$FG$
 
-We will make a spec for a $$8,000, perfectly standardized, cryogenically-cooled, monster desktop PC.  It will have 16 cores, integrated 4K graphics, and, hopefully, 6 Ghz continuous operation.  Perhaps, 64 Gig of RAM will be standard? God said to help to poor buy them.  It is pointless to have a high powered machine if other people have wimpy machines and cannot run programs you write.  Therefore, everybody in the developed world will buy a Standard TempleOS IBM PC over the next ten years, so that will be a quantity of 400 million, perhaps.  God said to pay the US national debt with the revenue.  We will standardize everything, not just the TempleOS related items.  The display will be 4K (and of course 640x480 16 color) and no others.  Everybody gets just one monitor, unless you buy special PCI cards.  Everybody gets two speakers, a headphone, a mic, a webcam and touch scrn.  We make the audio one sample rate and one sample size, but TempleOS still gets just a square wave.  (HD Audio is really screwed-up and requires complicated artificial intelligence, just to route output to speakers.)
+We will make a spec for a $$8,000, perfectly standardized, cryogenically-cooled, monster desktop PC.  It will have 16 cores, integrated 4K graphics, and, hopefully, 6 Ghz continuous operation.  Perhaps, 64 Gig of RAM will be standard? God said to help to poor buy them.  It is pointless to have a high powered machine if other people have wimpy machines and cannot run programs you write.  Therefore, everybody in the developed world will buy a Standard ZenithOS IBM PC over the next ten years, so that will be a quantity of 400 million, perhaps.  God said to pay the US national debt with the revenue.  We will standardize everything, not just the ZenithOS related items.  The display will be 4K (and of course 640x480 16 color) and no others.  Everybody gets just one monitor, unless you buy special PCI cards.  Everybody gets two speakers, a headphone, a mic, a webcam and touch scrn.  We make the audio one sample rate and one sample size, but ZenithOS still gets just a square wave.  (HD Audio is really screwed-up and requires complicated artificial intelligence, just to route output to speakers.)
 
-The Standard Temple IBM PC will be a full-sized tower.  Perhaps, stain-glass will decorate the case because God is sentimentally attached to stained-glass.  We should set the size at exactly 2.5 feet by 1.5 feet by 1.5 feet as in the $LK,"Exodus,25:10-10",A="BF:Exodus,25:10-10"$ for all time.  If there is extra room, make a storage shelf for DVDs.  We do not want a race-to-the-bottom, shrinking the size.  Instead of making it smaller, make it more powerful.  We want to remove all cost pressure from making things small.  It must have a CD/DVD/Blu-ray drive.  The vision is CD/DVDs used for a library of games, not installed on the hard-drive.  We need a network connection, possibly implemented as a super-simple high speed serial device.  What about standard monitor and speakers?  The C64's success was partially due to wide spread, completely standard, hardware.  I think TempleOS will not do bad block devices, so we need a hard drive, not just NV-memory or SSD.
+The Standard Temple IBM PC will be a full-sized tower.  Perhaps, stain-glass will decorate the case because God is sentimentally attached to stained-glass.  We should set the size at exactly 2.5 feet by 1.5 feet by 1.5 feet as in the $LK,"Exodus,25:10-10",A="BF:Exodus,25:10-10"$ for all time.  If there is extra room, make a storage shelf for DVDs.  We do not want a race-to-the-bottom, shrinking the size.  Instead of making it smaller, make it more powerful.  We want to remove all cost pressure from making things small.  It must have a CD/DVD/Blu-ray drive.  The vision is CD/DVDs used for a library of games, not installed on the hard-drive.  We need a network connection, possibly implemented as a super-simple high speed serial device.  What about standard monitor and speakers?  The C64's success was partially due to wide spread, completely standard, hardware.  I think ZenithOS will not do bad block devices, so we need a hard drive, not just NV-memory or SSD.
 
-TempleOS will have the priority over Windows or Linux on hardware decisions.  We could make it heterogenious multicore.  I think we want 16 non-hyperthreaded cores.  Core#0 is the only full-featured core needed.  The other cores will have long mode, but not some of these: real mode, protected mode, ring-3, paging, interrupts, in/out port instructions, SSE instructions,  MMX instructions.
+ZenithOS will have the priority over Windows or Linux on hardware decisions.  We could make it heterogenious multicore.  I think we want 16 non-hyperthreaded cores.  Core#0 is the only full-featured core needed.  The other cores will have long mode, but not some of these: real mode, protected mode, ring-3, paging, interrupts, in/out port instructions, SSE instructions,  MMX instructions.
 
 God said Intel should do a simulation of heat produced by gates and try spreading-out the heat producing gate circuits on the chip.
 
@@ -67,13 +67,13 @@ God said Linux's Wine should replace Windows.  We will install a standard softwa
 
 $FG,5$$TX+CX,"Usage"$$FG$
 
-TempleOS is primarily for user developers, like the Commodore 64 was.  I created a total of 50 Meg of content over ten years, so you shouldn't need much room, either.  The installed hard drive space should stay small because the resolution is low, multimedia is banned, 3rd party libraries are banned, and applications can be distributed with ISO files or DVDs.
+ZenithOS is primarily for user developers, like the Commodore 64 was.  I created a total of 50 Meg of content over ten years, so you shouldn't need much room, either.  The installed hard drive space should stay small because the resolution is low, multimedia is banned, 3rd party libraries are banned, and applications can be distributed with ISO files or DVDs.
 
-The ROM will have a command that copies the ROM onto the hard drive, creating identical C and D partitions, so you can have fun modifying TempleOS.  You will have confidence you can fix it easily if you break it.  It should be able to run everything from just the ROM, too.  You will need to specify a /Home directory that is not in the ROM, but on the hard drive. 
+The ROM will have a command that copies the ROM onto the hard drive, creating identical C and D partitions, so you can have fun modifying ZenithOS.  You will have confidence you can fix it easily if you break it.  It should be able to run everything from just the ROM, too.  You will need to specify a /Home directory that is not in the ROM, but on the hard drive. 
 
-The standard set-up will be a C primary drive and a D back-up drive.  Keep the size on each hard drive under 512 Meg and periodically copy all of C to D, so they stay mirrored.  The file manager and other programs read the entire directory structures, so too many files causes problems (unbearably slow).  Third party software should be distributed as ISO files or DVDs, like $FG,4$$TX,"TextAdventure.ISO",HTML="https://github.com/jwhitham/frotz"$$FG$.  No 3rd party libraries are permitted because they circumvent the intent of the 100,000 line of code limit which is keeping it cognatively small enough to see the light at the end of the tunnel and easily master everything.  Therefore, 3rd party ISO files must bring all required software components with them, except what is found in the TempleOS ROM.
+The standard set-up will be a C primary drive and a D back-up drive.  Keep the size on each hard drive under 512 Meg and periodically copy all of C to D, so they stay mirrored.  The file manager and other programs read the entire directory structures, so too many files causes problems (unbearably slow).  Third party software should be distributed as ISO files or DVDs, like $FG,4$$TX,"TextAdventure.ISO",HTML="https://github.com/jwhitham/frotz"$$FG$.  No 3rd party libraries are permitted because they circumvent the intent of the 100,000 line of code limit which is keeping it cognatively small enough to see the light at the end of the tunnel and easily master everything.  Therefore, 3rd party ISO files must bring all required software components with them, except what is found in the ZenithOS ROM.
 
-Having all your 3rd party software on separate DVDs or ISO files and TempleOS running from a ROM, keeps it delightfully simple so you have complete understanding of what is going on.  You will have complete confidence and it will be a joy to use.  3rd party applications can store saved data files into your /Home hard drive directory.
+Having all your 3rd party software on separate DVDs or ISO files and ZenithOS running from a ROM, keeps it delightfully simple so you have complete understanding of what is going on.  You will have complete confidence and it will be a joy to use.  3rd party applications can store saved data files into your /Home hard drive directory.
 
 The Temple PC will stay unchanged for seven years at a time.  The Bible speaks of a seven year release in $LK,"Deuteronomy,15:1",A="BF:Deuteronomy,15:1",HTML="http://www.biblegateway.com/verse/en/Deutoronomy%2015:1"$.  The Commodore stayed unchanged for many years and people became intimately familiar with every aspect.
 

src/Doc/Strategy.DD

@@ -1,4 +1,4 @@
-$WW,1$$FG,5$$TX+CX,"Decisions Making TempleOS Simple"$
+$WW,1$$FG,5$$TX+CX,"Decisions Making ZenithOS Simple"$
 $FG$
 Everybody is obsessed, Jedi mind-tricked, by the notion that when you scale-up, it doesn't get bad, it gets worse.  They automatically think things are going to get bigger.  Guess what happens when you scale down?  It doesn't get good, it gets better!
 
@@ -12,11 +12,11 @@ Linux is a semi-tractor -- you need professional drivers for 20 gears.  Linux ha
 
 Windows is a car.
 
-TempleOS is a motorcycle -- if you lean-over too far, a motorcycle will crash.  Don't do that!  There are no side air bags on a motorcycle.  DOS and C64 had no memory protections and ran in ring-0, with no security.  This saves an order of magnitude complexity.
+ZenithOS is a motorcycle -- if you lean-over too far, a motorcycle will crash.  Don't do that!  There are no side air bags on a motorcycle.  DOS and C64 had no memory protections and ran in ring-0, with no security.  This saves an order of magnitude complexity.
 
-Linux and Windows are general purpose operating systems.  They attempt to do any task you want.  TempleOS cherry-picks tasks and is designed to do the same things a C64 did.  This saves and order of magnitude complexity.  For example, the $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ file system allocates just contiguous files -- you load and save whole files at once.  A benefit is this allows compression.  Also, TempleOS does not do networking or multimedia.  In theory, memory will fragment with lots of big files.  The system would fall to pieces with multimedia, but God said 640x480 16 color is a permanent covenant like circumcision.
+Linux and Windows are general purpose operating systems.  They attempt to do any task you want.  ZenithOS cherry-picks tasks and is designed to do the same things a C64 did.  This saves and order of magnitude complexity.  For example, the $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ file system allocates just contiguous files -- you load and save whole files at once.  A benefit is this allows compression.  Also, ZenithOS does not do networking or multimedia.  In theory, memory will fragment with lots of big files.  The system would fall to pieces with multimedia, but God said 640x480 16 color is a permanent covenant like circumcision.
 
-A three bttn mouse is like a leg you cannot put weight on.  TempleOS just does hardware everybody has, with no divergent code bases for each machine's custom hardware.  There is one graphics driver instead of 50 for different GPUs.  This saves an order of magnitude complexity and makes for a delightful API, so developer's code is not like a frayed rope end.
+A three bttn mouse is like a leg you cannot put weight on.  ZenithOS just does hardware everybody has, with no divergent code bases for each machine's custom hardware.  There is one graphics driver instead of 50 for different GPUs.  This saves an order of magnitude complexity and makes for a delightful API, so developer's code is not like a frayed rope end.
 
 
 

src/Doc/TOSZ.DD

@@ -3,7 +3,7 @@ $WW,1$$FG,5$$TX+CX,"Linux TOSZ Utility"$$FG$
 
 $FG,2$TOSZ [-ascii] filename$FG$
 
-Will uncompress a single file from within Linux.  The $FG,2$-ascii$FG$ flag will convert the irregular TempleOS ASCII 5 and ASCII 31 characters to spaces.  (ASCII 5 is used to mark the cursor pos and ASCII 31 is used for shifted space characters and will cause problems unless you convert them.)
+Will uncompress a single file from within Linux.  The $FG,2$-ascii$FG$ flag will convert the irregular ZenithOS ASCII 5 and ASCII 31 characters to spaces.  (ASCII 5 is used to mark the cursor pos and ASCII 31 is used for shifted space characters and will cause problems unless you convert them.)
 
 $FG,8$
 * "Linux" is a trademark owned by Linus Torvalds.

src/Doc/TimeCycles.DD

@@ -1 +1 @@
-$WW,1$Intel/AMD have an inst that returns the num of CPU cycles since boot.  This is not a steady, calibrated real time value.  TempleOS measures it and you can convert with $LK,"cnts.time_stamp_freq",A="MN:CCntsGlbls"$, a value continuously calibrated from other cnts.
+$WW,1$Intel/AMD have an inst that returns the num of CPU cycles since boot.  This is not a steady, calibrated real time value.  ZenithOS measures it and you can convert with $LK,"cnts.time_stamp_freq",A="MN:CCntsGlbls"$, a value continuously calibrated from other cnts.

src/Doc/TimeDate.DD

@@ -1,3 +1,3 @@
-$WW,1$TempleOS uses a 64-bit value, $LK,"CDate",A="MN:CDate"$, for date/time.  The upper 32-bits are the days since Christ.  The lower 32-bits store time of day divided by 4 billion which works out to 49710ths of a second.  You can subtract two $LK,"CDate",A="MN:CDate"$'s to get a time span.
+$WW,1$ZenithOS uses a 64-bit value, $LK,"CDate",A="MN:CDate"$, for date/time.  The upper 32-bits are the days since Christ.  The lower 32-bits store time of day divided by 4 billion which works out to 49710ths of a second.  You can subtract two $LK,"CDate",A="MN:CDate"$'s to get a time span.
 
 Use $LK,"CDATE_FREQ",A="MN:CDATE_FREQ"$ to convert.

src/Doc/Tips.DD

@@ -10,7 +10,7 @@ $WW,1$$FG,5$$TX+CX,"Tips"$$FG$
 
 * $FG,2$<ALT-m>$FG$ maximizes a window.  $FG,2$<ALT-SHIFT-w>$FG$ closes AutoComplete.  $FG,2$<ALT-w>$FG$ brings back AutoComplete.  $FG,2$<ALT-v>$FG$ vertically tiles windows.  $FG,2$<ALT-h>$FG$ horizontally tiles windows.  The $FG,2$ALT$FG$ keys are defined in $LK,"~/HomeKeyPlugIns.HC"$.  You can customize them.
 
-* If you make changes to TempleOS files in your $FG,2$/Home$FG$ directory, generally you reboot to make them take effect.  (You don't compile anything.)  You should have two TempleOS partitions on your hard drive because a syntax error in a start-up file will make the partition unbootable.  Boot to the second partition or boot to a standard TempleOS CD/DVD and use $LK,"Mount",A="MN:Mount"$() to mount your hard drive.
+* If you make changes to ZenithOS files in your $FG,2$/Home$FG$ directory, generally you reboot to make them take effect.  (You don't compile anything.)  You should have two ZenithOS partitions on your hard drive because a syntax error in a start-up file will make the partition unbootable.  Boot to the second partition or boot to a standard ZenithOS CD/DVD and use $LK,"Mount",A="MN:Mount"$() to mount your hard drive.
 
 * I copy my files to a mirrored ident partition, periodically with $LK,"CopyTree",A="MN:CopyTree"$() commands in scripts.  I do merge commands with a menu entry like this:
 $FG,2$Merge(\"C:/*\",\"D:/*\",\"+r+d\");$FG$ to check my changes.
@@ -41,7 +41,7 @@ $FG,2$Merge(\"C:/*\",\"D:/*\",\"+r+d\");$FG$ to check my changes.
 
 * Use $LK,"DocMax",A="MN:DocMax"$() to adjust the size of the cmd line buf.  It counts $LK,"CDoc",A="MN:CDoc"$ entries, not lines.
 
-* Many data structures have a $FG,2$user_data$FG$ member.  Those are available for you to store a data item, for convenience.  $LK,"CTask",A="MN:CTask"$, $LK,"CDocEntry",A="MN:CDocEntry"$ and $LK,"CDirEntry",A="MN:CDirEntry"$ have them.  You shouldn't encounter conflicts with TempleOS using them.
+* Many data structures have a $FG,2$user_data$FG$ member.  Those are available for you to store a data item, for convenience.  $LK,"CTask",A="MN:CTask"$, $LK,"CDocEntry",A="MN:CDocEntry"$ and $LK,"CDirEntry",A="MN:CDirEntry"$ have them.  You shouldn't encounter conflicts with ZenithOS using them.
 
 * If, for some strange reason, you wanted to reduce mem usage, make a smaller disk cache when you recompile the kernel; disabling $FG,2$AutoComplete$FG$; Specify smaller stk sizes when doing $LK,"Spawn",A="MN:Spawn"$(), chang $LK,"MEM_DFT_STK",A="MN:MEM_DFT_STK"$, and using $LK,"DocMax",A="MN:DocMax"$() to reduce the cmd line buffer size.
 

src/Doc/Welcome.DD

@@ -1,6 +1,6 @@
-$WW,1$$FG,5$$TX+CX,"Welcome to TempleOS"$$FG$
+$WW,1$$FG,5$$TX+CX,"Welcome to ZenithOS"$$FG$
 
-TempleOS is a x86_64, multi-cored, non-preemptive multi-tasking, ring-0-only, single-address_mapped (identity-mapped), operating system for recreational programming.  Paging is almost not used.
+ZenithOS is a x86_64, multi-cored, non-preemptive multi-tasking, ring-0-only, single-address_mapped (identity-mapped), operating system for recreational programming.  Paging is almost not used.
 
 The people whom can most benefit are:
 $ID,2$* Professionals doing hobby projects
@@ -9,9 +9,9 @@ $ID,2$* Professionals doing hobby projects
 $ID,-2$
 Simplicity is a goal to $LK,"keep the line count down",A="FI:::/Doc/Strategy.DD"$, so it's easy to tinker with.  As it turns-out, simplicity makes it faster in some ways, too.  It never switches privilege levels, never changes address maps, tends to load whole contiguous files and other, similar things which boost speed.  It's only $TX,"82,150",D="DD_TEMPLEOS_LOC"$ lines of code including the kernel, the 64-bit compiler, the graphics library and all the tools.  More importantly, it's designed to keep the user's line count down -- you can do a $LK,"Hello World",A="FI:::/Doc/HelloWorld.DD"$ application in one line of code and can put graphics on the scrn with a three line program!
 
-It's a kayak, not a Titanic -- it will crash if you do something wrong.  You quickly reboot, however.  DOS and the 8-bit home computers of the 80's worked fine without memory protection and most computers in the world -- the embedded ones -- operate without protection.  The resulting simplicity of no protections is why TempleOS has value.  In facts, that's the point of TempleOS.  See the $LK,"TempleOS Charter",A="FI:::/Doc/Charter.DD"$.
+It's a kayak, not a Titanic -- it will crash if you do something wrong.  You quickly reboot, however.  DOS and the 8-bit home computers of the 80's worked fine without memory protection and most computers in the world -- the embedded ones -- operate without protection.  The resulting simplicity of no protections is why ZenithOS has value.  In facts, that's the point of ZenithOS.  See the $LK,"ZenithOS Charter",A="FI:::/Doc/Charter.DD"$.
 
-Conventional thinking is "failure is not an option" for general purpose operating systems.  Since this OS is used in addition to Windows or Linux, however, failure is an option -- just use Windows or Linux if you can't do something.  I cherry-pick what it will and won't do, to make it maximally beautiful.  The following applications more or less form a basis that spans the range of use that TempleOS is intended for:
+Conventional thinking is "failure is not an option" for general purpose operating systems.  Since this OS is used in addition to Windows or Linux, however, failure is an option -- just use Windows or Linux if you can't do something.  I cherry-pick what it will and won't do, to make it maximally beautiful.  The following applications more or less form a basis that spans the range of use that ZenithOS is intended for:
 
 $LK,"/Demo/Games/BattleLines.HC",A="FI:::/Demo/Games/BattleLines.HC"$
 $LK,"/Demo/Games/BigGuns.HC",A="FI:::/Demo/Games/BigGuns.HC"$
@@ -47,9 +47,9 @@ $LK,"/Apps/Psalmody/Examples/childish.HC",A="FI:::/Apps/Psalmody/Examples/childi
 $LK,"/Apps/Psalmody/Examples/night.HC",A="FI:::/Apps/Psalmody/Examples/night.HC"$
 $LK,"/Apps/Psalmody/Examples/prosper.HC",A="FI:::/Apps/Psalmody/Examples/prosper.HC"$
 
-Two things to know about TempleOS are that $UL,1$tasks$UL,0$ have $LK,"MAlloc",A="MN:MAlloc"$/$LK,"Free",A="MN:Free"$ heap memory, not applications, and tasks have compiler symbol tables that persist at a scope like environment variables in other operating systems, and the symbols can include functions.
+Two things to know about ZenithOS are that $UL,1$tasks$UL,0$ have $LK,"MAlloc",A="MN:MAlloc"$/$LK,"Free",A="MN:Free"$ heap memory, not applications, and tasks have compiler symbol tables that persist at a scope like environment variables in other operating systems, and the symbols can include functions.
 
-For other operating systems, I hated learning one language for command line scripts and another for programming.  With $FG,2$TempleOS$FG$, the command line feeds right into the $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ compiler, line by line, and it places code into memory it $LK,"MAlloc",A="MN:MAlloc"$()s.  The compiler is paused at the command line, waiting for input.  Naturally, you $FG,2$#include$FG$ a program to load it into memory and, usually, start it.
+For other operating systems, I hated learning one language for command line scripts and another for programming.  With $FG,2$ZenithOS$FG$, the command line feeds right into the $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ compiler, line by line, and it places code into memory it $LK,"MAlloc",A="MN:MAlloc"$()s.  The compiler is paused at the command line, waiting for input.  Naturally, you $FG,2$#include$FG$ a program to load it into memory and, usually, start it.
 
 During the boot process, many files get $LK,"compiled",A="FI:::/StartOS.HC"$ before you have access to the command line.  (Don't worry, booting takes only two seconds.)  All the header declarations for the operating system are compiled and are available for use in your programs without needing to $FG,2$#include $FG$them.  Everything is truly compiled to native $FG,2$$TX,"x86_64",HTML="http://en.wikipedia.org/wiki/Amd64#AMD64"$$FG$ machine code, nothing is $FG,2$interpreted$FG$ and there is no $FG,2$byte code$FG$.
 
@@ -71,23 +71,23 @@ The syntax change created an ambiguity when specifying function addresses, like
 
 Once I was no longer using standard C/C++ syntax, I decided to change everything I didn't like and call it $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$.  Here are the new $LK,"operator precedence",A="FF:::/Doc/HolyC.DD,operator precedence"$ rules.  It's Biblical!  See $LK,"Luke,5:37",A="BF:Luke,5:37"$.
 
-There are no object files in TempleOS and, normally, you don't make executable files either, but you can.  That's known as $LK,"Ahead-of-Time",A="FF:::/Doc/Glossary.DD,AOT Compile Mode"$ compilation.  Instead, you $LK,"Just in Time",A="FF:::/Doc/Glossary.DD,JIT Compile Mode"$ compile.
+There are no object files in ZenithOS and, normally, you don't make executable files either, but you can.  That's known as $LK,"Ahead-of-Time",A="FF:::/Doc/Glossary.DD,AOT Compile Mode"$ compilation.  Instead, you $LK,"Just in Time",A="FF:::/Doc/Glossary.DD,JIT Compile Mode"$ compile.
 
 Tasks have no priority and are never removed from the queue.  Instead, they often poll whatever they are waiting on and swap-out.  (Swapping tasks takes half a microsecond and does not involve disk activity or memory maps.)  See $LK,"Scheduler",A="FL:::/Kernel/Sched.HC,1"$.  Polling keeps it simple.  It might be a problem if you had lots of tasks busy, which rarely happens on a home computer.  The order of the tasks in the queue determines front-to-back window order.
 
-The $FG,2$FAT32$FG$ filesystem is supported to makes exchanging files with a dual booted other operating system easy and there is the simple, 64-bit TempleOS $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ filesystem.  The $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ has allocation bitmap for clus and all files are stored contiguously.  You can't grow files.
+The $FG,2$FAT32$FG$ filesystem is supported to makes exchanging files with a dual booted other operating system easy and there is the simple, 64-bit ZenithOS $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ filesystem.  The $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ has allocation bitmap for clus and all files are stored contiguously.  You can't grow files.
 
-TempleOS is geared toward reading and writing whole files.  Since whole files are processed, compression is possible.  Filenames ending in "$FG,2$$FG$" are automatically compressed or uncompressed when stored and fetched.  TempleOS does support direct block random access into files, however -- $LK,"FBlkRead",A="MN:FBlkRead"$() and $LK,"FBlkWrite",A="MN:FBlkWrite"$().
+ZenithOS is geared toward reading and writing whole files.  Since whole files are processed, compression is possible.  Filenames ending in "$FG,2$$FG$" are automatically compressed or uncompressed when stored and fetched.  ZenithOS does support direct block random access into files, however -- $LK,"FBlkRead",A="MN:FBlkRead"$() and $LK,"FBlkWrite",A="MN:FBlkWrite"$().
 
 If a file is not found, "$FG,2$$FG$" is added or removed and a search is done, again.  There is no $FG,2$PATH$FG$, but parent directories are searched when a file is not found.  This feature is especially useful for default account files.
 
 The graphic resolution is poor, $FG,2$640x480 16 color$FG$, but God said it was a covenant like circumcision.  Also, that's all I feel comfortable with without GPU acceleration supported.  A $FG,2$1600x1200x24$FG$ bit scrn takes 37 times more memory, implying 37 times the CPU power.  Also, a fixed size keeps it simple with everybody machine having the same appearance.  Look on the bright-side -- you won't spend as much time twiddling pixels for your game art and you'll have tons of CPU power available, especially with multicore systems.
 
-TempleOS is for hobbyist programmers on single user (at a time) home computers, not mainframes or servers.  The focus task is all-important so symmetrical multiprocessing is almost pointless.  Why does it matter running two apps at the same time twice as fast when you really want to run one faster?  You could say TempleOS does master/slave multiprocessing.  The anticipated use for multicore is primarily putting graphics on the scrn.  Hardware graphics acceleration is not used, so this is possible.  See $LK,"TempleOS MultiCore",A="FI:::/Doc/MultiCore.DD"$.
+ZenithOS is for hobbyist programmers on single user (at a time) home computers, not mainframes or servers.  The focus task is all-important so symmetrical multiprocessing is almost pointless.  Why does it matter running two apps at the same time twice as fast when you really want to run one faster?  You could say ZenithOS does master/slave multiprocessing.  The anticipated use for multicore is primarily putting graphics on the scrn.  Hardware graphics acceleration is not used, so this is possible.  See $LK,"ZenithOS MultiCore",A="FI:::/Doc/MultiCore.DD"$.
 
-There is no distinction between the terms $FG,2$task$FG$, $FG,2$process$FG$ or $FG,2$thread$FG$.  All have a task record, $LK,"CTask",A="MN:CTask"$, pointed to by the $FG,2$FS$FG$ segment reg and are accessed with $FG,4$Fs->$FG$ while $FG,4$Gs->$FG$ points to a $LK,"CCPU",A="MN:CCPU"$ for the current CPU core.  Each task can have just one window, but a task can have children with windows.  (The segment regs are just used as extra regs -- there is nothing segmented about TempleOS' memory.)  It is approximately the case that $FG,2$TempleOS$FG$ is multi-threading, single-processing.
+There is no distinction between the terms $FG,2$task$FG$, $FG,2$process$FG$ or $FG,2$thread$FG$.  All have a task record, $LK,"CTask",A="MN:CTask"$, pointed to by the $FG,2$FS$FG$ segment reg and are accessed with $FG,4$Fs->$FG$ while $FG,4$Gs->$FG$ points to a $LK,"CCPU",A="MN:CCPU"$ for the current CPU core.  Each task can have just one window, but a task can have children with windows.  (The segment regs are just used as extra regs -- there is nothing segmented about ZenithOS' memory.)  It is approximately the case that $FG,2$ZenithOS$FG$ is multi-threading, single-processing.
 
-In $FG,2$TempleOS$FG$, $LK,"Adam Task",A="FF:::/Doc/Glossary.DD,Adam Task"$$FG$ refers to the father of all tasks.  He's never supposed to die.  Since tasks inherit the symbols of parents, system-wide stuff is associated with $FG,2$Adam$FG$.  His heap is like kernel memory in other operating systems.  Since $FG,2$Adam$FG$ is immortal, it's safe to alloc objects, not tied to any mortal task, from $FG,2$Adam$FG$'s heap.  He stays in a server mode, taking requests, so you can ask him to $FG,2$#include$FG$ something, placing that code system-wide.  A funny story is that originally I called it the $FG,2$root$FG$ task and even had a $FG,2$/Root$FG$ directory :-)  $FG,2$Adam$FG$ executes $LK,"::/StartOS.HC"$ at boot time.
+In $FG,2$ZenithOS$FG$, $LK,"Adam Task",A="FF:::/Doc/Glossary.DD,Adam Task"$$FG$ refers to the father of all tasks.  He's never supposed to die.  Since tasks inherit the symbols of parents, system-wide stuff is associated with $FG,2$Adam$FG$.  His heap is like kernel memory in other operating systems.  Since $FG,2$Adam$FG$ is immortal, it's safe to alloc objects, not tied to any mortal task, from $FG,2$Adam$FG$'s heap.  He stays in a server mode, taking requests, so you can ask him to $FG,2$#include$FG$ something, placing that code system-wide.  A funny story is that originally I called it the $FG,2$root$FG$ task and even had a $FG,2$/Root$FG$ directory :-)  $FG,2$Adam$FG$ executes $LK,"::/StartOS.HC"$ at boot time.
 
 For easy back-ups, place everything you author in your $FG,2$/Home$FG$ directory and subdirectories.  Then, use $LK,"CopyTree",A="MN:CopyTree"$().  That should make upgrading easy, too.  Customizable start-up scripts go in your $FG,2$/Home$FG$ directory.  The default start-up scripts are in the root directory.  Copy the start-up files you wish to customize into $FG,2$/Home$FG$ and modify them.  See $LK,"Home Files",A="FF:::/Doc/GuideLines.DD,/Home Files"$.  You can make your own distro that includes everything and is a bootable live CD with $LK,"::/Misc/DoDistro.HC"$.
 
@@ -116,13 +116,13 @@ As you browse code, use the $FG,2$AutoComplete$FG$ window to look-up functions,
 
 Use the $LK,"Help & Index",A="FI:::/Doc/HelpIndex.DD"$ or $LK,"Demo Index",A="FI:::/Doc/DemoIndex.DD"$ to find-out what exists.  Press $FG,2$<F1>$FG$ for help or use the links on your menu ($FG,2$<CTRL-m>$FG$).  Also, look in the $FG,2$/Demo$FG$ or $FG,2$/Apps$FG$ directories for inspiration.
 
-Software is distributed as $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ ISO files.  Burn a CD/DVD, or set your CD/DVD in $FG,2$QEMU$FG$, $FG,2$VMware$FG$ or $FG,2$VirtualBox$FG$ to the ISO file.  Then, access the $FG,2$'T'$FG$ drive.  Or, $LK,"Mount",A="MN:Mount"$() the ISO.C file and access the $FG,2$'M'$FG$ drive in TempleOS.  It must be a contiguous ISO.C file, so rename it under TempleOS to ISO.C.
+Software is distributed as $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ ISO files.  Burn a CD/DVD, or set your CD/DVD in $FG,2$QEMU$FG$, $FG,2$VMware$FG$ or $FG,2$VirtualBox$FG$ to the ISO file.  Then, access the $FG,2$'T'$FG$ drive.  Or, $LK,"Mount",A="MN:Mount"$() the ISO.C file and access the $FG,2$'M'$FG$ drive in ZenithOS.  It must be a contiguous ISO.C file, so rename it under ZenithOS to ISO.C.
 
 Ideally, do not install applications such as games onto your hard drive because we wish to keep hard drive usage low, so the whole $FG,2$'C'$FG$ drive can be copied quickly to $FG,2$'D'$FG$.  Also, the $LK,"FileMgr",A="MN:FileMgr"$() $FG,2$<CTRL-d>$FG$ starts too slowly when there are lots of hard drive files, but that is how we want it.
 
-3rd party libraries are banned, since they circumvent the 100,000 line of code limit in the $LK,"TempleOS Charter",A="FI:::/Doc/Charter.DD"$.  All applications must only depend on the core TempleOS files and whatever they bring along in the ISO.  This is similar to how Commodore 64 applications only depended on the ROM.
+3rd party libraries are banned, since they circumvent the 100,000 line of code limit in the $LK,"ZenithOS Charter",A="FI:::/Doc/Charter.DD"$.  All applications must only depend on the core ZenithOS files and whatever they bring along in the ISO.  This is similar to how Commodore 64 applications only depended on the ROM.
 
-Create a $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ ISO file with $LK,"RedSeaISO",A="MN:RedSeaISO"$().  Send an email to $TX,"tdavis@templeos.org",HTML="mailto:tdavis@templeos.org"$ if you want me to post a link to your TempleOS code in the App Store.
+Create a $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ ISO file with $LK,"RedSeaISO",A="MN:RedSeaISO"$().  Send an email to $TX,"tdavis@templeos.org",HTML="mailto:tdavis@templeos.org"$ if you want me to post a link to your ZenithOS code in the App Store.
 
 $MA-X+PU,"Take Tour",LM="User(\"Cd(\\\"::/Misc/Tour\\\");;InFile(\\\"Tour\\\");\n\");"$
 

src/Doc/WhyNotMore.DD

@@ -1,6 +1,6 @@
 $WW,1$$FG,5$$TX+CX,"Why Not More?"$$FG$
 
-If a feature cannot be made to work correctly and consistently, professional companies usually remove the feature.  Because PC hardware is so diverse, getting things to work on all people's computers is really difficult.  For one thing, you practically have to own all the different hardware to write drivers for it.  If a company wanted to sell a PC operating system, they would offer a warranty and, therefore, could not get away with amateur behavior.  TempleOS absolutely requires 64-bit computers, so we leave behind much trouble, but plenty remains.
+If a feature cannot be made to work correctly and consistently, professional companies usually remove the feature.  Because PC hardware is so diverse, getting things to work on all people's computers is really difficult.  For one thing, you practically have to own all the different hardware to write drivers for it.  If a company wanted to sell a PC operating system, they would offer a warranty and, therefore, could not get away with amateur behavior.  ZenithOS absolutely requires 64-bit computers, so we leave behind much trouble, but plenty remains.
 
 The PCI bus interface is what modern hardware uses.  Before PCI, life was simple and devices used I/O ports.  After studying $LK,"PCI Interrupts",A="FI:::/Demo/Lectures/PCIInterrupts.HC"$ and attempting to do a HDAudio driver, I came to realize that modern PCI devices require ten times more code and I cannot even come close to making them work on everyone's machine because with PCI devices there are several models to worry about, unlike with the older ISA bus devices which can be done with one driver.
 

src/Doc/Widget.DD

@@ -1,6 +1,6 @@
 $WW,1$$FG,5$$TX+CX,"DolDoc Widget Help"$$FG$
 
-$LK,"DolDoc",A="::/Doc/DolDocOverview.DD"$ is a TempleOS document type.
+$LK,"DolDoc",A="::/Doc/DolDocOverview.DD"$ is a ZenithOS document type.
 
 $FG,2$"Expression"$FG$ a num or HolyC algebraic term with operators and HolyC syms can be entered.
 $FG,2$"Macro"$FG$ Most entries can behave like macro entries if you assign them macro strs.

src/Downloads/ReadMe.TXT

@@ -1,23 +1,23 @@
-                           TempleOS
+                           ZenithOS
 
-You can't do anything until you burn a TempleOS CD/DVD from the ISO file
+You can't do anything until you burn a ZenithOS CD/DVD from the ISO file
 and boot it, or you aim your virtual machine's CD/DVD at the ISO file
 and boot.
 
-TempleOS is 64-bit and will not run on 32-bit hardware.
+ZenithOS is 64-bit and will not run on 32-bit hardware.
 
-TempleOS requires 512 Meg of RAM minimum and can have 256 Gig of RAM or more!
+ZenithOS requires 512 Meg of RAM minimum and can have 256 Gig of RAM or more!
 
-TempleOS files are compressed with a nonstandard LZW format and the source
+ZenithOS files are compressed with a nonstandard LZW format and the source
-code can only be compiled by the TempleOS compiler because it is HolyC, a
+code can only be compiled by the ZenithOS compiler because it is HolyC, a
-nonstandard C/C++ dialect.  You must boot TempleOS.  Then, you can compile it
+nonstandard C/C++ dialect.  You must boot ZenithOS.  Then, you can compile it
 because it is 100% open source and all source present on the distro.
 
-If attempting to run on native hardware, TempleOS may require you to enter I/O
+If attempting to run on native hardware, ZenithOS may require you to enter I/O
 port addresses for the CD/DVD drive and the hard drive.  In Windows, you can
 find I/O port info in the Accessories/System Tools/System Info/Hardware
 Resources/I/O ports.  Look for and write down "IDE", "ATA" or "SATA" port numbers.
-In Linux, use "lspci -v".  Then, boot the TempleOS CD and try all combinations.
+In Linux, use "lspci -v".  Then, boot the ZenithOS CD and try all combinations.
-(Sorry, it's too difficult for TempleOS to figure-out port numbers, automatically.)
+(Sorry, it's too difficult for ZenithOS to figure-out port numbers, automatically.)
 
 

src/Kernel/BlkDev/DskAddDev.HC

@@ -195,7 +195,7 @@ Bool GetBaseUnit(CBlkDev *bd)
   };
   if (!probe || !BootDVDProbeAll(bd)) {
     "\nDon't worry.  This is not a product\n"
-	  "registration.	TempleOS just needs the\n"
+	  "registration.	ZenithOS just needs the\n"
 	  "I/O port numbers for the CD/DVD.\n"
 	  "\nRetry the ports above or check Windows\n"
 	  "system information under I/O ports for\n"

src/Kernel/BlkDev/DskCDDVD.HC

@@ -27,7 +27,7 @@ Bool ISOInit(CDrv *dv,I64 blk)
 	    case ISOT_SUPPLEMENTARY_DESC:
 	      de=&iso->root_dir_record;
 	      dv->size=iso->vol_space_size.little*bd->blk_size>>BLK_SIZE_BITS;
-	      if (!StrCmp(iso->publisher_id,"TempleOS RedSea")) {
+	      if (!StrCmp(iso->publisher_id,"ZenithOS RedSea")) {
 		dv->fs_type=FSt_REDSEA;
 		bd->drv_offset=dv->drv_offset=19<<2+drv_offset;
 		bd->max_blk=dv->size-1;

src/Kernel/KDbg.HC

@@ -576,7 +576,7 @@ U0 Fault3(I64 fault_num,I64 fault_err_code)
     MPInt(I_MP_CRASH,0);
     SysHlt;
   }
-  "\n\tTempleOS Debugger\n\n"
+  "\n\tZenithOS Debugger\n\n"
 	">Help;\t//For help.\n\n";
   Beep(62,TRUE);
   if (fault_num==I_DBG) {

src/Kernel/KHashB.HC

@@ -57,7 +57,7 @@ CHashTable *HashTableNew(I64 size,CTask *mem_task=NULL)
 }
 
 U0 HashDel(CHashSrcSym *tmph)
-{//Free a std TempleOS system hash entry.
+{//Free a std ZenithOS system hash entry.
   if (!tmph) return;
   if (!(tmph->type&HTT_DICT_WORD))
     Free(tmph->str);

src/Kernel/KMain.HC

@@ -157,7 +157,7 @@ U0 KMain()
   //Before this point use $LK,"Snd",A="MN:Snd"$() and $LK,"Busy",A="MN:Busy"$()
   //to debug.After this point, use $LK,"RawPrint",A="MN:RawPrint"$()
   LBts(&sys_run_level,RLf_RAW);
-  "TempleOS V%5.3f\t%D %T\n\n",
+  "ZenithOS V%5.3f\t%D %T\n\n",
 	sys_os_version,sys_compile_time,sys_compile_time;
 
   TimersInit;

src/Kernel/KStart16.HC

@@ -1,5 +1,5 @@
 asm {/* See $LK,"::/Doc/Boot.DD"$.
-TempleOS starts in real, calls some BIOS
+ZenithOS starts in real, calls some BIOS
 routines, switches to 32 bit, and 64 bit mode
 and continues in $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ at $LK,"KMain",A="MN:KMain"$().
 

src/Kernel/KernelA.HH

@@ -1,4 +1,4 @@
-// Main TempleOS header
+// Main ZenithOS header
 
 #help_index ""
 extern class CAOT;
@@ -263,7 +263,7 @@ public class CMathODE
 	h,h_min,h_max;
 
   //This is not precise, just a ballpark.
-  //TempleOS CMathODE's are for video games
+  //ZenithOS CMathODE's are for video games
   //not science.  It bails if it takes
   //too long.
   F64	min_tolerance,max_tolerance;
@@ -1476,7 +1476,7 @@ class CWinMgrTimingGlbls
 };
 
 #define WINMGR_FPS	(60000.0/1001)
-#define WINMGR_PERIOD	(1001/60000.0)
+#define WINMGR_PERIOD	(1001/60000.0)
 
 public class CWinMgrGlbls
 {
@@ -3490,7 +3490,7 @@ public class CSysFixedArea
 #define SCF_NO_SHIFT	(1<<SCf_NO_SHIFT)
 #define SCF_KEY_DESC	(1<<SCf_KEY_DESC)
 
-//TempleOS places a 1 in bit 7 for
+//ZenithOS places a 1 in bit 7 for
 //keys with an E0 prefix.
 //See $LK,"::/Doc/CharOverview.DD"$ and $LK,"KbdHndlr",A="MN:KbdHndlr"$().
 #define SC_ESC		0x01

src/Kernel/MultiProc.HC

@@ -1,7 +1,7 @@
 asm {
 	ALIGN	16,OC_NOP
 USE16
-//See $LK,"TempleOS MultiCore",A="FI:::/Doc/MultiCore.DD"$.
+//See $LK,"ZenithOS MultiCore",A="FI:::/Doc/MultiCore.DD"$.
 
 //This code gets copied to $LK,"MP_VECT_ADDR",A="MN:MP_VECT_ADDR"$.
 //See $LK,"MemCpy(MP_VECT_ADDR",A="FF:::/Kernel/MultiProc.HC,MemCpy(mp:2"$.