Mail Archives: djgpp/1998/02/17/03:07:49
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.
- Raw text -