TempleOSCDV4.12.ISO

Doc/Welcome.DD

@@ -7,7 +7,7 @@ $ID,2$* Professionals doing hobby projects
 * Teenagers doing projects
 * Non-professional, older-persons 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,"81,125",D="DD_TEMPLEOS_LOC_OFFICIAL"$ 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 screen with a three line program!
+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,"81,223",D="DD_TEMPLEOS_LOC_OFFICIAL"$ 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"$.
 
@@ -81,9 +81,9 @@ TempleOS is geared toward reading and writing whole files.  Since whole files ar
 
 If a file is not found, "$FG,2$.Z$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 screen 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.
+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 screen.  Hardware graphics acceleration is not used, so this is possible.  See $LK,"TempleOS MultiCore",A="FI:::/Doc/MultiCore.DD"$.
+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"$.
 
 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.
 
@@ -124,12 +124,12 @@ Ideally, do not install applications such as games onto your hard drive because
 
 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.
 
-$MA-X+PU,"Take Tour",LM="User(\"Cd(\\\"::/Misc/Tour\\\");;AutoFile(\\\"Tour\\\");\n\");"$
+$MA-X+PU,"Take Tour",LM="User(\"Cd(\\\"::/Misc/Tour\\\");;InFile(\\\"Tour\\\");\n\");"$
 
 $FG,8$
 * "Linux" is a trademark owned by Linus Torvalds.
 * "Windows" is a trademark owned by MicroSoft Corp.
-* "Commodore 64" was a trademark owned by Commodore Business Machines.
+* "Commodore 64" is a trademark owned by Polabe Holding NV.
 * "QEMU" is a trademark owned by Fabrice Bellard.
 * "VMware" is a trademark owned by VMware, Inc.
 * "VirtualBox" is a trademark owned by Oracle.