<a name="l3"></a>* You run a risk of problems if you do file operations on the same files
<a name="l4"></a>simultaneously because there is <blink>no file sharing/locking mechanism</blink>. Generally,
<a name="l5"></a>the last write wins.
<a name="l6"></a>
<a name="l7"></a>* When using </span><span class=cF2>FAT32</span><span class=cF0>, TempleOS does not generate unique short-entry names, the
<a name="l8"></a>ones with the </span><span class=cF2>~</span><span class=cF0>s. Not all </span><span class=cF2>FAT32</span><span class=cF0> filenames are valid TempleOS names and it will
<a name="l9"></a>complain. Do not access </span><span class=cF2>FAT32</span><span class=cF0> drives not dedicated to TempleOS. Disable them
<a name="l10"></a>with </span><a href="/Wb/Kernel/BlkDev/DskAddDev.HC.HTML#l170"><span class=cF4>DrvEnable</span></a><span class=cF0>(OFF), or they will generate error messages. </span><span class=cF2>FAT32</span><span class=cF0> involves a
<a name="l14"></a>large local vars from the heap. You can change </span><a href="/Wb/Kernel/KernelA.HH.HTML#l2843"><span class=cF4>MEM_DFT_STK</span></a><span class=cF0> and recompile </span><span class=cF2>Kernel</span><span class=cF0>
<a name="l15"></a>or request more when doing a </span><a href="/Wb/Kernel/KTask.HC.HTML#l242"><span class=cF4>Spawn</span></a><span class=cF0>().
<a name="l19"></a>* Call </span><a href="/Wb/Kernel/BlkDev/DskDrv.HC.HTML#l237"><span class=cF4>DskChg</span></a><span class=cF0>() when you insert a new removable media.
<a name="l23"></a>* You can only </span><span class=cF2>extern</span><span class=cF0> something once. There is a varient called </span><span class=cF2>_extern</span><span class=cF0> which
<a name="l24"></a>binds a HolyC definition to a asm sym. This, too, can only be done once.
<a name="l26"></a>* A terminal task has a </span><a href="/Wb/Kernel/KernelA.HH.HTML#l1367"><span class=cF4>CDoc</span></a><span class=cF0> document structure that remains active even when
<a name="l27"></a>you change </span><span class=cF4>Fs->draw_it</span><span class=cF0>. To prevent links in the </span><a href="/Wb/Kernel/KernelA.HH.HTML#l1367"><span class=cF4>CDoc</span></a><span class=cF0> from being activated when
<a name="l30"></a> A) </span><a href="/Wb/Adam/DolDoc/DocRecalcLib.HC.HTML#l107"><span class=cF4>DocBottom</span></a><span class=cF0>() followed by </span><a href="/Wb/Adam/DolDoc/DocRecalcLib.HC.HTML#l120"><span class=cF4>DocClear</span></a><span class=cF0>() to clear the </span><a href="/Wb/Kernel/KernelA.HH.HTML#l1367"><span class=cF4>CDoc</span></a><span class=cF0> so it has no active
<a name="l33"></a> B) Disable window mgr bttn click checking with </span><span class=cF4>Fs->win_inhibit</span><span class=cF0> set to mask </span><span class=cF4>
<a name="l47"></a>* A </span><a href="/Wb/Kernel/BlkDev/DskDirB.HC.HTML#l9"><span class=cF4>Cd</span></a><span class=cF0>() cmd must be followed by two semicolons if a </span><span class=cF2>#include</span><span class=cF0> is after it. This
<a name="l48"></a>is because the preprocessor processes the next token ahead.
<a name="l49"></a>
<a name="l50"></a>* The assembler's error msgs are often off by a line and undefines are cryptic.
<a name="l51"></a>
<a name="l52"></a>* The last semicolon on the cmd line is converted to a dbl semicolon because the
<a name="l53"></a>compiler looks ahead before doing a cmd. This normally has no negative effect,
<a name="l54"></a>but when entering </span><span class=cF2>if</span><span class=cF0> stmts with </span><span class=cF2>else</span><span class=cF0> clauses it presents problems.
<a name="l55"></a>
<a name="l56"></a>* You can do a </span><span class=cF2>class</span><span class=cF0> fwd reference by using </span><span class=cF2>extern</span><span class=cF0> on the first declaration, but
<a name="l57"></a>you can only do ptr references to the </span><span class=cF2>class</span><span class=cF0>.
<a name="l65"></a> </span><span class=cF0>The </span><span class=cF2>|=</span><span class=cF0> will be coded as a </span><span class=cF2>U32 Bts</span><span class=cF0> inst resulting in a </span><span class=cF2>U32</span><span class=cF0> access instead of a </span><span class=cF2>
<a name="l66"></a> U16</span><span class=cF0> access. This affects some hardware operations.
<a name="l67"></a>
<a name="l68"></a>* Compiler warning or error message line numbers will be off if you have a block
<a name="l69"></a>of word-wrapped comments. You might press </span><span class=cF2><CTRL-t></span><span class=cF0> before doing an editor