Date:	Mon, 23 Nov 1998 13:18:27 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp AT delorie DOT com
Subject:	Re: keyboard handler
In-Reply-To:	<36575282.6814796@news2.cts.com>
Message-ID:	<Pine.SUN.3.91.981123130948.23503B-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com

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 -