Hello David!

Another problem has arisen as a result of your reply...


Replying to a message of David Nugent to Simeon Cran:

 >> I have a multi-threaded serial terminal program that uses
 >> VIO for screen writes, DosRead and DosWrite for the
 >> serial port and KbdCharIn to read the keyboard. It works
 >> great, but I can't stop it from exitting when I press
 >> ctrl-c!

 DN> Enable 'binary' mode on the keyboard. When in binary mode, ^C is just
 DN> like any other key with no specific meaning or translation applied.
 DN> Just remember to return it to ASCII mode before returning from the
 DN> program - while CMD.EXE effectively masks such a problem by forcing
 DN> it to ascii mode again, some shells such as 4OS2 don't.

OK, I discovered the binary thing before your reply, and was pleased to
learn that it solved my problem. But I wasn't restoring it as I figured
that was something that should happen automatically. I was wrong obviously.

Now the problem is this: The keyboard thread is not the main thread. The
main thread does some set up, starts most of the threads, then waits on a
semaphore which signals it to exit. It then signs off to the user and
returns. Simple. However I added a deinitialise function to it so that it
could restore the keyboard to its original mode (which I had stored).

Unfortunately, KbdSetStatus never returns, and I figure it is because
KbdCharIn is sitting waiting for a character, which disallows KbdSetStatus
from working!! So everything continues to work as it used to, and the only
way to kill the program is to reboot the machine!!!!

It's a great way to make an uncloseable session, but it is causing me a
headache. The solution for now is to not restore the keyboard.

I use _beginthread to start the thread, so there is no way of killing the
thread first (as far as I know) from another thread. 


I'm tempted to describe the behaviour of DosSetStatus as a bug in the
operating system. What do you think?


Bye, Simeon!

--- FleetStreet 1.04 NR