Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!udel!princeton!rutgers!iuvax!bkliewer
From: bkliewer@iuvax.cs.indiana.edu (Bradley Dyck Kliewer)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Windows 2.0.3 bug (feature?)
Message-ID: <7581@iuvax.cs.indiana.edu>
Date: 9 Apr 88 20:02:59 GMT
References: <8494@agate.BERKELEY.EDU>
Reply-To: bkliewer@iuvax.UUCP (Bradley Dyck Kliewer)
Organization: Indiana University CSCI, Bloomington
Lines: 21

In article <8494@agate.BERKELEY.EDU> laba-5ac@widow.berkeley.edu () writes:
>
>...  a little C program that just infinite looped around printing a 
>message.  The trouble was when we tried to stop Windows.  When we tried
>to exit, Windows said that the program was still active and that we
>couldn't exit.  OK - then we tried to close it, but we couldn't, because
>it was still active.  We tried issuing Ctrl-Breaks and Ctrl-C's to the
>program, but it didn't work.  Eventually, we just rebooted out of Windows.

This is a problem inherent to Windows, and it is the programmer's
responsibility to avoid these situations.  The program which is currently
executing processes all keystrokes and mouse commands, ignoring those which
are not its own.  There are supposed to be ways for the programmer to work
around this.  Interestingly enough, the Presentation Manager under OS/2 will
have the same problem -- the foreground application can completely lock out
the keyboard and mouse (see the March 1988 issue of Microsoft Systems Journal).

Bradley Dyck Kliewer                Hacking...
bkliewer@iuvax.cs.indiana.edu       It's not just an adventure
                                    It's my job!
Author of EGA/VGA A Programmer's Reference Guide