Quirks
* You run a risk of problems if you do file operations on the same files simultaneously because there is . Generally, the last write wins.
* When using FAT32, ZealOS does not generate unique short-entry names, the ones with the ~s. Not all FAT32 filenames are
valid ZealOS names and it will complain. Do not access FAT32 drives not dedicated to ZealOS. Disable them with
DriveEnable(OFF), or they will generate error messages. FAT32 involves a long and short name for each file.
* The stack does not grow because virtual mem is not used. It is recommended that you allocate large local variables from the
heap. You can change MEM_DEFAULT_STACK and recompile Kernel or request more when doing a Spawn().
* The syntax highlighting occassionally glitches. The compiler doesn't.
* Call DiskChange() when you insert a new removable media.
* Accessing CD/DVD's is flaky. Try Drive() or DiskChange() twice.
* You can only extern something once. There is a varient called _extern which binds a ZealC definition to a asm symbol. Th
is, too, can only be done once.
* A terminal task has a CDoc document structure that remains active even when you change Fs->draw_it. To prevent links in
the CDoc from being activated when the user clicks in the window, do one of three things:
A) DocBottom() followed by DocClear() to clear the CDoc so it has no active widgets.
B) Disable window mgr button click checking with Fs->win_inhibit set to mask WIF_SELF_MS_L|WIF_FOCUS_TASK_MS_L_D|
WIF_SELF_MS_R|WIF_FOCUS_TASK_MS_R_D. This inhibits window mgr operations but still generates messages from bttn clicks.
* switch/case statements alloc a single jump table--do not use with wide, sparse ranges of case values.
* 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.)
* MemCopy() only goes forward.
* 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 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 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 pointer references to the
class.
* When doing something like
U0 Main()
{
U16 *_w = 0xA0000;
*_w |= 0x8000;
}
The |= will be coded as a U32 Bts instruction resulting in a U32 access instead of a U16 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 <C
TRL-t> before doing an editor goto-line-number command.