BJ> Probably becase the code hooks another interupt to allow sharing CPU 
 BJ> time with other programs, and is probably called 
 BJ> every time in the loop sometime after the keyboard 
 BJ> is check.....  And this varied depending on which 
 BJ> multi-tasker was in use.....  That's why there are 
 BJ> key words for Desqview, OS/2 and some others.
 
Thank you! I was wondering what the hell that code was for -- now it gives
me some options to persue when I have the chance. :)
 
 BJ> I've seen this one character issue / bug in other 
 BJ> software.  I think it gets back to how the C 
 BJ> compiler libraries handle pointers on character 
 BJ> devices..... 
 
To be clear, under UNIX there are C compiler libraries (the annoying
exception being the C++ compiler libraries for gcc 3 onward) --
technically, these are OS-level libraries which compiled C code calls.
Subtle difference, but important -- it means that you can't depend on the
compiler for 'bug compatible' (etc) behaviour, because the underlying OS is
really what matters. This is actually similar to the way Windows works if
you're calling, say, winsock code from either Borland or VC, the compiler
matters not, the version of winsock.dll does.
 
Anyhow, when I fixed that bug under Maximus, what I found was that the
ncurses library didn't behave the way I thought it would -- I was asking
for a 0-second timeout on my reads with the timeout() call. This is
supposed to be equivalent to a non-blocked read, but seems to cause buggy
behaviour observed. Asking for notimeout() seems to fix it. Stupid, stupid,
stupid. Either seems to work under real curses.
 
 
Wes

--- Maximus/2 3.01