Mail Archives: djgpp/1998/11/23/06:19:47
On Sun, 22 Nov 1998, jim crawford wrote:
> _go32_dpmi_allocate_iret_wrapper(&kb);
> _go32_dpmi_get_real_mode_interrupt_vector(0x09, &oldkbhandler);
> _go32_dpmi_set_protected_mode_interrupt_vector(0x09, &kb);
> }
>
> void deinstallkbhandler()
> {
> _go32_dpmi_set_real_mode_interrupt_vector(0x09, &oldkbhandler);
> }
This is incorrect usage. This program assumes that restoring a real-mode
interrupt vector also restores the protected-mode one (which is the one
that was hooked). This assumption only holds with some DPMI servers;
with others you will get a wedged machine once this program exits,
especially if it is invoked from another DJGPP program.
Also, the program doesn't lock code and data accessed by the interrupt
handler, so it will crash unless all memory is locked by the appropriate
bit in _crt0_startup_flags.
> (i wonder why this sort of low-level keyboard support wasn't coded
> into the bios or operating system. it would've taken maybe 20 bytes
> of code and 16 bytes of ram to do it)
It *is* coded into the BIOS: the BIOS installs a handler for Int 9, and
the handler calls a software interrupt (function 4Fh of Int 15h) for
every keystroke it gets. The problem is that hooking a software
interrupt from protected mode is even trickier than hooking a hardware
interrupt.
- Raw text -