Mail Archives: djgpp-workers/1998/01/21/03:20:08
sandmann AT clio DOT rice DOT edu (Charles Sandmann) wrote:-
> If you are going to this much trouble, don't bother with the user handler as
> implemented, since just chaining the interrupt is about the same amount of
> code.
One of my reasons for writing this version is that I found that chaining
interrupt 9 with _go32_dpmi_chain_protected_mode_interrupt_vector() etc works
fine on a desktop, but on laptops system and Windows malfunctions often occur
after the program has exited, as if something extra in laptops (perhaps the
extra system program matter to translate Fn key combinations into imitations
of the keys that laptops don't have) has fouled up with the djgpp program's
interrupt 9 hook chain.
I wrote in assembler a program called AAKEYS.COM which drops a TSR which
hooks interrupt 9 to save the raw keyboard events in a buffer and provides
extra interrupt functions to read and handle that buffer; AAKEYS.COM is called
before the djgpp program instead of re-hooking interrupt 9 during the djgpp
program. That works OK from DOS on a laptop, but causes malfunctions if I call
AAKEYS.COM from DOS, then enter Windows (in this case Windows 3.1.1), then
call from Windows a djgpp program that calls AAKEYS.COM's extra interrupt
functions, then exit to DOS. I suspect that something in Windows (at least in
Windows 3.1.1) expects interrupt 9 to be completely unhooked and at its
default value on entering Windows.
Getting into DOS to call a program from DOS is nothing like as easy under
that fancy new Windows 95 than it is under DOS 6.22.
P.S. to systems experts: Laptops must have extra system program matter to
translate Fn key combinations into imitations of the keys that laptops don't
have. How can a djgpp program look for this extra matter as part of a function
to tell the program whether or not it is running on a laptop?
- Raw text -