🚀 go-pugleaf

I've got a truly great program underway, but I can't stand to let the
user break out of it with Ctrl-C or Ctrl-Break, and I need keyboard
input.  What's the trick(s)?
-- 
Dennis Ward    dennisw@tekigm2.MEN.TEK.COM    C1-820    (206)253-5428

In article <9627@tekigm2.MEN.TEK.COM> dennisw@tekigm2.MEN.TEK.COM (Dennis G
Ward) writes:

>I've got a truly great program underway, but I can't stand to let the
>user break out of it with Ctrl-C or Ctrl-Break, and I need keyboard
>input.  What's the trick(s)?
>-- 
>Dennis Ward    dennisw@tekigm2.MEN.TEK.COM    C1-820    (206)253-5428

The best method I know of, is to trap interrupt 09h. Write a little routine
that does the following:
   -checks if the scan code of a key corresponds to the break key or 
    the key with letter 'C'. The scan code, in case you don't know is
    the number that the keyboard processor sends, each time a key is pressed.
    These are listed in several books.
   -If that's not the case, jump to the adress of the interrupt 9h.
   -if it is, check the state of the Ctrl key (bit number 4 I think of byte
    0:40H, again you can find this info in Peter Norton's book or the
    Programmer's Solver etc.) If Ctrl is down, ignore the key and exist, if
    it's up pass it onto the old interrupt 09h.

Prefix interrupt 09 with this routine. That is set the address of interrupt 09h to the Segment:offset of
your routine. 

In C and Pascal there are various ways of replacing an interrupt.
You can also take a look at any resident utility in PC Mag. They do it all
the time.

Maybe C or Pascal has a simple function to do so, I don't remember.

Good Luck.

-- 
         ---------------+-------------------------------------------
        | Naji Mouawad  |       nmouawad@water.uwaterloo.edu        |
        |  University   |-------------------------------------------|
        | Of Waterloo   | "Thanks God, we cannot prove He Exists."  |

In article [abridged] gene@uokmax.uucp (Gene E. Johannsen) writes:
!>
!>	I am writing a program that I want to use the mouse with.  I don't
!>have a reference work to the mouse so I am using a list of interrupts.  Below
!>is a small program I writing to learn how to use the mouse.  All it will do is
!>set up and turn on the mouse and then print an '*' when I press the left
!>button.  It prints the '*' but freezes immediately afterwards:
!>
!>.MODEL	SMALL
!>
!>.CODE
!>
!>  [...]
!>
!>BUTTON		PROC	FAR
!>	push ax		;This is where the problem comes.  It prints 
!>	push dx		;the '*' okay, but then it freezes.
!>	mov ah,02h	
!>	mov dl,2ah
!>	int 21h
!>	pop dx
!>	pop ax
!>	ret
        ^^^
!>BUTTON		ENDP
!>
!>	END
>
I may be wrong here, but shouldn't this be an 'iret' instruction?  After
all, the routine *is* an interrupt service routine, called by a hardware
interrupt...If you return with a regular 'ret' call, none of the registers
are popped off the stack and restored to their state before the interrupt,
and the CPU doesn't know where to pick up, so it *should* freeze!

-Dave

In article <1990Jul31.023745.1116@water.waterloo.edu>, nmouawad@water.waterloo.edu (Naji Mouawad) writes:
> In article <9627@tekigm2.MEN.TEK.COM> dennisw@tekigm2.MEN.TEK.COM (Dennis G
> Ward) writes:
> 
> >input.  What's the trick(s)?
> >-- 
> >Dennis Ward    dennisw@tekigm2.MEN.TEK.COM    C1-820    (206)253-5428
> 
> The best method I know of, is to trap interrupt 09h. Write a little routine
> that does the following:
> ["little" deleted]

Hmm, with your suggestion, you have to do scancode processing yourself,
but why shouldn't MSDOS do the work for you ?

The following should work:
  Choose a global flag variable, say c_break
  Replace INT09h with the following (meta)code:
    call original int09h
    look if c_break is true
      if yes,
        get the next "keystroke" (getch() in C is ok here!), this overreads
        the break scancode
        reset the c_break flag
        if you want, set some other flag to signal c_break was hit
      else
        do nothing
    and complete
  When the original int09h runs and detects ctrl-break or ctrl-C was pressed,
  it calls one of the DOS ctrl-break handlers (int19h or int24h, but please
  do not beat me if that's wrong, I have no doc handy...) which normally
  set a DOS internal flag which causes DOS to terminate your program on
  thenext int21h.
  So the only thing which remains to do is to replace these two ctrl-break
  interrupts with your own handler, simply setting the c_break flag inspected
  by your own keyboard handler.
  It is important NOT to call the original ctrl-break handlers from your
  own, because otherwise DOS would show up with a nasty "^C" string later.

I hope I go it half right...

Bye
  Patrick

Of course it won't work  u r calling dos from inside an interrupt
routine.  Try using the bios calls or write directly to the screen.
U are not normally able to coll dos from inside an interrupt routine
with out playing a log to funny games.

John E. Kabat Jr.    <|> ...!uunet!telxon!johnk <|> johnk@telxon.uucp.uu.net
Telxon Corporation   <|> 
Akron, Ohio, 44313   <|> 
(216) 867-3700 (3554)<|> 



John E. Kabat Jr.    <|> ...!uunet!telxon!johnk <|> johnk@telxon.uucp.uu.net
Telxon Corporation   <|> 
Akron, Ohio, 44313   <|> 
(216) 867-3700 (3554)<|> 

In article <5717@sbsvax.cs.uni-sb.de> fs-info@sbsvax.cs.uni-sb.de (c/o Peter Gaal) writes:


   In article <1990Jul31.023745.1116@water.waterloo.edu>, nmouawad@water.waterloo.edu (Naji Mouawad) writes:
   > In article <9627@tekigm2.MEN.TEK.COM> dennisw@tekigm2.MEN.TEK.COM (Dennis G
   > Ward) writes:
   > 
   > >input.  What's the trick(s)?
   > >-- 
   > >Dennis Ward    dennisw@tekigm2.MEN.TEK.COM    C1-820    (206)253-5428
   > 
   > The best method I know of, is to trap interrupt 09h. Write a little routine
   > that does the following:
   > ["little" deleted]

   Hmm, with your suggestion, you have to do scancode processing yourself,
   but why shouldn't MSDOS do the work for you ?
   [Pseudocode Obliterated...  MS-DOS doesn't work for me.  Ptui!]

A quick solution in C that lets the runtime library do the dirty work:

-------------8<-----Trim Here------------------

	BOOL	break_flag = FALSE;

void ctrl_break( void )
{
	break_flag = TRUE;

	/* Do as little as possible in here...  DOS gets in a strange state
	   during interrupts and doesn't take kindly to I/O being done.*/

	signal( SIGINT, ctrl_break );
}

void ctrl_break_handler( void )	/* Or whatever you need... */
{
	signal( SIGINT, SIG_IGN );	/* Shut ^Break off completely...
					   Don't want recursive calls. */

	printf( "\n\nWHAM!  Ctrl-Break!\n\n" );
	break_flag = FALSE;

	/* Do your own thing in here */

	signal( SIGINT, ctrl_break );	/* Reset things */
}

main( int argc, char **argv )
{
	signal( SIGINT, ctrl_break );

	for ( ; ; ) {	/* forever */

		/* Your code here */

		if ( break_flag )
			handle_ctrl_break();

	}
}

-------------8<-----Trim Here------------------

A couple of suggestions:

1.  Implement the code to check on break_flag inside of something that
gets run very often.  For example, I have a routine that gets called
over and over while the system is waiting for a key.  This also means
that you can finish up critical operations and _then_ check for a
break.

2.  If you want to get rid of that nasty ^C on the screen, the only
way I can find is to freopen() stdout to NUL.  There's no other way as
far as I can see without horking the keyboard interrupt (messy) or
modifying your BIOS (out of the question).  If you're using some
screen I/O package, odds are it uses its own direct reads and writes
and stdout just sits idle anyway.


						- Mark

................................... ................................... 
: Mark A. Feit                     : feit@cs.odu.edu                  :
: Old Dominion University CS Dept. : feit@xanth.UUCP                  :
: Norfolk, Virginia, U.S.A., Earth : "So where's my lunch, anyway?"   :
................................... ................................... 
  Y
:)8 G-G-G-D-E-C

--

						- Mark

................................... ................................... 
: Mark A. Feit                     : feit@cs.odu.edu                  :
: Old Dominion University CS Dept. : feit@xanth.UUCP                  :
: Norfolk, Virginia, U.S.A., Earth : "So where's my lunch, anyway?"   :
................................... ................................... 
  Y
:)8 G-G-G-D-E-C

/ gene@uokmax.uucp (Gene E. Johannsen) writes...
>	I am writing a program that I want to use the mouse with.  I don't
>have a reference work to the mouse so I am using a list of interrupts.  Below
>is a small program I writing to learn how to use the mouse.  All it will do is
>set up and turn on the mouse and then print an '*' when I press the left
>button.  It prints the '*' but freezes immediately afterwards:

>BUTTON		PROC	FAR
>	push ax		;This is where the problem comes.  It prints 
>	push dx		;the '*' okay, but then it freezes.
>	mov ah,02h	
>	mov dl,2ah
>	int 21h
>	pop dx
>	pop ax
>	ret
>BUTTON		ENDP

I believe that your problem is the call to DOS (INT 21h) inside your mouse
event handler routine.  Since the mouse generates a hardware interrupt, which
controls CPU execution to be vectored to the mouse driver, which then calls
your routine, you cannot call DOS, only manipulate your own code/data space,
make calls to INT 33h (the mouse driver), directly manipulate the display
(dangerous), etc.  Since in your main program you've called DOS to get a key,
when you call DOS from the mouse event handler (which was called from a hard-
ware ISR), you're re-entering DOS.  DOS was not designed to be re-entrant and
you screw up their stacks and flags and stuff.

Everett Kaser                   Hewlett-Packard Company
...hplabs!hp-pcd!everett        work: (503) 750-3569   Corvallis, Oregon
everett%hpcvra@hplabs.hp.com    home: (503) 928-5259   Albany, Oregon

In article <34725@ut-emx.UUCP> readdm@walt.cc.utexas.edu (David M. Read) writes:
>In article [abridged] gene@uokmax.uucp (Gene E. Johannsen) writes:
>!>
>!>	I am writing a program that I want to use the mouse with.  I don't
>!>have a reference work to the mouse so I am using a list of interrupts.  Below
>!>is a small program I writing to learn how to use the mouse.  All it will do is
>!>set up and turn on the mouse and then print an '*' when I press the left
>!>button.  It prints the '*' but freezes immediately afterwards:
>!>
>!>.MODEL	SMALL
>!>
>!>.CODE
>!>
>!>  [...]
>!>
>!>BUTTON		PROC	FAR
>!>	push ax		;This is where the problem comes.  It prints 
>!>	push dx		;the '*' okay, but then it freezes.
>!>	mov ah,02h	
>!>	mov dl,2ah
>!>	int 21h
>!>	pop dx
>!>	pop ax
>!>	ret
>        ^^^
>!>BUTTON		ENDP
>!>
>!>	END
>>
>I may be wrong here, but shouldn't this be an 'iret' instruction?  After
>all, the routine *is* an interrupt service routine, called by a hardware
>interrupt...If you return with a regular 'ret' call, none of the registers
>are popped off the stack and restored to their state before the interrupt,
>and the CPU doesn't know where to pick up, so it *should* freeze!
>
>-Dave


I thought the same thing, but I tried 'iret' and it didn't work any better.
Anyway, I found my problem.  It is the 'int 21h' that freezes it.  I honestly
don't know why.

gene

In article <34725@ut-emx.UUCP> readdm@walt.cc.utexas.edu (David M. Read) writes:

   !>	ret
	^^^
   !>BUTTON		ENDP
   !>
   !>	END
   >
   I may be wrong here, but shouldn't this be an 'iret' instruction?  After
   all, the routine *is* an interrupt service routine, called by a hardware

No it isn't. Mouse event handlers are called by the the mouse driver.
The mouse driver uses far calls.

					Lloyd

--
------------------------------------------------------------------------
Lloyd Parkes		|	   Bix Licks Stick's Tricks
lloyd@comp.vuw.ac.nz	|    Bix Barton Master of the Rum and Uncanny
------------------------------------------------------------------------

>CRN@BYUVM.BITNET writes:

>>I am having a VERY weird problem in TurboC.  My code looks
>>something like this:

>>typedef struct{
>>   . . .
>>   char   *str;
>>int    type;
>>}FIELD;

>>int proc(FIELD *fld)
>>{
>>   . . .
>>   if(!valid_str(fld->str))
>>      return ERROR;
>>   . . .
>>}

Tom Wiencko responds:
>Turn off register optimization.  There must be some code around the
>function call which also uses the pointer - and with register optimizaton
>turned on the compiler sometimes "forgets" which registers he has used
>and which still have valid pointers in them.
>
>Took me two days of intense debugging to find this, and it was confirme
>by Borland tech support.  They also said that there is at this time no
>fix for the problem.
>
>I am not sure if Turbo C++ has the same bug - I have not tested it yet
>(but I have left the optimization off...).

>Tom


   Thanks Tom, I owe you dinner.  That was exactly the problem.  Once
I turned off register optimization ("-r-" on the command line that
invokes tcc, if anyone is interested), the pointers were no longer
getting destroyed and the code worked perfectly.
   Thanks also to everyone else who responded privately to me.  And
in response to the guy who (mildly) flamed me:  I put *alot* of
work into debugging that code segment before I placed the post.
I had worked through the code many times and could not find any
problem with my logic, that's why I speculated in the subject line
of the post that I may have found a bug in Turbo C.  I'll
be more careful next time to make sure my post reflects the work
I've done before I place it.
   By the way, I tested the code with Turbo C++ and the same thing
happened, so it looks like it has the same bug.
   One quick question:  Have you noticed a great speed difference
between your code that was compiled using register optimization as
opposed to your code compiled without such optimization?


  P.S.  Tom, I'm serious about that dinner invitation.  If you're ever
in Provo (I know there's not a very high probability of that happening
but I can't afford to fly you here -- I am just a poor grad student
after all), look me up.  I'm in the phone book.


Thanks again,
--Cory R. Newey
(crn@byuvm.bitnet)

In article <1990Jul31.193800.18227@uokmax.uucp> gene@uokmax.uucp (Gene E. Johannsen) writes:
>Anyway, I found my problem.  It is the 'int 21h' that freezes it.  I honestly
>don't know why.

It's because DOS is not re-entrant.  You may be in the midst of a DOS call
when a mouse interrupt comes along; you call DOS again from your handler,
and since DOS has only one internal stack you overwrite what was there
previously.  Your call completes, you get your *, then the handler returns
to a clobbered stack and your system goes to Sudbury.
-- 
	Bernie Roehl, University of Waterloo Electrical Engineering Dept
	Mail: broehl@watserv1.waterloo.edu OR broehl@watserv1.UWaterloo.ca
	BangPath: {allegra,decvax,utzoo,clyde}!watmath!watserv1!broehl
	Voice:  (519) 885-1211 x 2607 [work]

In article <9627@tekigm2.MEN.TEK.COM> dennisw@tekigm2.MEN.TEK.COM (Dennis G Ward) writes:
>I've got a truly great program underway, but I can't stand to let the
>user break out of it with Ctrl-C or Ctrl-Break, and I need keyboard
>input.  What's the trick(s)?

The most PORTABLE way to do it (and it works well too) is to use the
signal() function in the standard library, like so:

---------------------------------------
#include <signal.h>

void ctrlctrap(i)
int i;
{
signal(SIGINT, ctrlctrap);  /* make sure next ctrl-break comes back here */
}


void main()
{
signal(SIGINT, ctrlctrap);  /* activate ctrl-c/ctrl-break trap handler */

etc....
--------------------------------------

Every time ctrl-c or ctrl break is pressed, the funtion ctrlctrap() will
be invoked, and will reset the pointer for the next ctrl-c to call
ctrlctrap() again.

This has worked on every ANSI compiler I have tried it on (Lattice,
Microsoft, unix compilers, etc.)


-- 
     ///  Alex Matulich
    ///  Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817
\\\///  alex@bilver.UUCP    ...uunet!tarpit!bilver!alex
 \XX/  From BitNet try: IN%"bilver!alex@uunet.uu.net"