🚀 go-pugleaf

I have noticed discrepancies when using KbdCharIn between my program running
in a text window or when it runs full screen.

In both cases the keyboard is in binary mode and the calls to KbdCharIn have
the IO_WAIT parameter set and the keyboard handle is 0.

Discrepancy #1:  When I type control-q, the KbdCharIn function returns with the
proper ascii and scan codes when running full-screen, but the character is 
ignored when running in a text window.

Discrepancy #2:  I set up a signal handler for control-c and control-break.
The signal handler simply sets a flag, acknowledges the signal and returns.
Then, when I type either control-c or control-break, when the program is
running full screen the KbdCharIn call returns with error code 0x5f, which
is "System call interrupted".  When the program is in a text window the
flag is set, but the call does not return until after I type the next key.

Question:  Is this the correct behavior or is there a bug in the text window
software?

I am really more concerned with #2 than with #1.  My goal is to restart my 
program's main loop when control-c or control-break is typed.  I realize
that my signal handler could longjmp back to my main loop but I was worried
about leaving the Kbd system in an inconsistent state.  Is it OK to do this?

-Paul