Date: Mon, 23 Nov 1998 13:18:27 +0200 (IST) From: Eli Zaretskii 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.