$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$, 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,"DriveEnable",A="MN:DriveEnable"$(OFF), or they will generate error messages.	$FG,2$FAT32$FG$ involves a long and short name for each file.

* The stack does not grow because virtual mem is not used.	I recommend allocating large local vars from the heap.	You can change $LK,"MEM_DEFAULT_STACK",A="MN:MEM_DEFAULT_STACK"$ and recompile $FG,2$Kernel$FG$ or request more when doing a $LK,"Spawn",A="MN:Spawn"$().

* The syntax highlighting occassionally glitches.  The compiler doesn't.

* Call $LK,"DiskChange",A="MN:DiskChange"$() when you insert a new removable media.

* Accessing CD/DVD's is flacky.  Try $LK,"Drive",A="MN:Drive"$() or $LK,"DiskChange",A="MN:DiskChange"$() twice.

* You can only $FG,2$extern$FG$ something once.  There is a varient called $FG,2$_extern$FG$ which binds a CosmiC definition to a asm sym.	This, too, can only be done once.

* A terminal task has a $LK,"CDoc",A="MN:CDoc"$ document structure that remains active even when you change $FG,4$Fs->draw_it$FG$.	To prevent links in the $LK,"CDoc",A="MN:CDoc"$ from being activated when the user clicks in the window, do one of three things:
$ID,2$
A) $LK,"DocBottom",A="MN:DocBottom"$() followed by $LK,"DocClear",A="MN:DocClear"$() to clear the $LK,"CDoc",A="MN:CDoc"$ so it has no active widgets.

B) Disable window mgr bttn click checking with $FG,4$Fs->win_inhibit$FG$ set to mask $LK,"WIF_SELF_MS_L",A="MN:WIF_SELF_MS_L"$|$LK,"WIF_FOCUS_TASK_MS_L_D",A="MN:WIF_FOCUS_TASK_MS_L_D"$|$LK,"WIF_SELF_MS_R",A="MN:WIF_SELF_MS_R"$|$LK,"WIF_FOCUS_TASK_MS_R_D",A="MN:WIF_FOCUS_TASK_MS_R_D"$.  This inhibits window mgr operations but still generates messages from bttn clicks.
$ID,-2$
* $FG,2$switch/case$FG$ statements alloc a single jump table--do not use with wide, sparse ranges of case values.

* Don't do a $FG,2$goto$FG$ out of a $FG,2$try{}$FG$.

* A $FG,2$goto$FG$ label name must not match a global scope object's name.	(It's not worth slowing-down the compiler to handle this case.)

* $LK,"MemCopy",A="MN:MemCopy"$() only goes forward.

* A $LK,"Cd",A="MN:Cd"$() cmd must be followed by two semicolons if a $FG,2$#include$FG$ is after it.  This is because the preprocessor processes the next token ahead.

* The assembler's error messages are often off by a line and undefines are cryptic.

* The last semicolon on the cmd line is converted to a double semicolon because the compiler looks ahead before doing a cmd.	This normally has no negative effect, but when entering $FG,2$if$FG$ statements with $FG,2$else$FG$ clauses it presents problems.

* You can do a $FG,2$class$FG$ forward reference by using $FG,2$extern$FG$ on the first declaration, but you can only do ptr references to the $FG,2$class$FG$.

* When doing something like
$FG,2$$ID,2$$ID,2$U0 Main()
{
	U16 *_w = 0xA0000;
	*_w |= 0x8000;
}
$ID,-2$$FG$The $FG,2$|=$FG$ will be coded as a $FG,2$U32 Bts$FG$ inst resulting in a $FG,2$U32$FG$ access instead of a $FG,2$U16$FG$ access.	This affects some hardware operations.
$ID,-2$
* Compiler warning or error message line numbers will be off if you have a block of word-wrapped comments.	You might press $FG,2$<CTRL-t>$FG$ before doing an editor goto-line-number command.
