From: "Anthony.Appleyard" <MCLSSAA2 AT fs2 DOT mt DOT umist DOT ac DOT uk>
Organization:  Materials Science Centre
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, DJGPP AT delorie DOT com
Date:          Tue, 17 Feb 1998 08:06:04 GMT
Subject:       Re: Hooking interrupt 9 clashing with new types of BIOS?
Reply-to: Anthony DOT Appleyard AT umist DOT ac DOT uk
Message-ID: <11FB51343AC@fs2.mt.umist.ac.uk>
Precedence: bulk

  Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:-
> Did you try to not unhook your handler, as I suggested?

  Last night I ran SPATRL with and without calling
_go32_dpmi_set_protected_mode_interrupt_vector(9, &old_I9handler);
 afterwards. The effect was the same, as I thought would be, since djgpp's
exit sequence is stated to re-unhook interrupt 9 afterwards anyway.

  Because of this `TSS=etc' error print nuisance, a few months ago I wrote a
TSR-dropper called AAKEYS.COM which hooks interrupt 9 to save the key events
in a buffer, and hooks interrupt 16 so that interrupt 16 with AH=6 reads from
that buffer. If I call AAKEYS.COM from DOS, the (version of SPATRL which uses
AAKEYS interrupts) works OK with never any `TSS=etc' error prints. But I get
odd occurences if I use AAKEYS with Windows, as if Windows on entry, when it
hooks interrupt 9 so it can send WM_KEYDOWN WM_KEYUP WM_SYSKEYDOWN WM_SYSKEYUP
messages, relies on finding interrupt 9's entry point where BIOS put it and
does not like finding it already hooked.