LoseThos Quirks

* You run a risk of problems if you do file operations on the same files 
simultaneously because there is no file sharing/locking mechanism.  Generally, 
the last write wins.

* When using FAT32, LoseThos does not generate unique short-entry names.  Not 
all FAT32 filenames are valid LoseThos names and it will complain.  Do not 
access FAT32 drives not dedicated to LoseThos.  Disable them with DriveEnable(OF
F), or they will generate error messages.  FAT32 involves a long and short name 
for each file.  LoseThos isn't so good at making distinct short names, so don't 
make files with same 11 characters, or you're asking for trouble when accessing 
from Windows.

* The stack does not grow because virtual mem is not used.  I recommend 
allocating large local variables from the heap.  You can change DEFAULT_STK and 
recompile OSMain or request more when doing a Spawn().

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

* Call ChangeDisk() when you insert a new removable media.

* Accessing CD-ROM's is flacky.  Try Drive() or ChangeDisk() twice.

* You can only extern something once.  There is a varient called LTextern which 
binds a C+ definition to a asm symbol.  This, too, can only be done once.

* You must call TaskLocalInit() in a task you Spawn() before you can do file 
I/O.  And, preemption is off by default, so use Preempt(ON) if you wish.

* A terminal task has a Ltf document structure that remains active even when you 
change Fs->update_win.  See ::/LT/Demo/Ltf/Quirk1.CPZ.  To prevent links in the 
Ltf from being activated when the user clicks in the window, do one of three 
things:

  A) LtfBottom() followed by LtfClear() to clear the Ltf so it has no active 
  widgets.

  B) Disable window manager button click checking with win_inhibit set to mask 
  WIF_IP_L and WIF_IP_R.  This inhibits window manager operations but still 
  generates messages from button clicks.

  C) Enter this code:
  Ltf *l=LtfCur;
  LtfRemQue(l);
  ...
  LtfInsQue(l,Fs->last_ltf);

  D) Hope the user just uses keyboard, not clicking the mouse in the window.

* switch/case statements allocate a single jump table--do not use with wide, 
sparse ranges of case values.

* If you use a typedef as a function return class, you might have problems 
dereferrencing it.  This might be or get fixed.

* Don't do a goto out of a try{}.

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

* MemCpy() only goes forward.

* Don't attempt to use Fs->ignore_except with CTRL-ALT-C.

* A Cd() cmd must be followed by two semicolons if a #include is after it.  This 
is because the preprocessor processes the next token ahead.

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

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

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

* When doing something like
    U2 *ww=0xF0000000;
    *ww|=0x8000;
  The |= will be coded as a U4 Bts instruction resulting in a U4 access instead 
  of a U2 access.  This affects some hardware operations.

* Compiler warning or error message line numbers will be off if you have a block 
of word-wrapped comments.  You might press CTRL-T before doing an editor 
goto-line-number command.