Date: Sun, 15 Feb 1998 13:28:55 +0200 (IST) From: Eli Zaretskii To: Anthony DOT Appleyard AT umist DOT ac DOT uk cc: DJGPP AT delorie DOT com Subject: Re: Hooking interrupt 9 clashing with new types of BIOS? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 13 Feb 1998, Anthony.Appleyard wrote: > C:\LIT\DIV\SPATRL>Invalid TSS in RMCB at eip=107f; flags=3002 > eax=01fd0000 ebx=000020d4 ecx=00000000 edx=00022800 esi=00001c18 edi=0001cfe0 > ebp=00000000 esp=0000310c cs=2b ds=3b es=b7 fs=33 gs=0 ss=33 error=00b4 This usually means that you don't unhook the keyboard interrupt at exit, and it is left to point into the void. > I asked about this at a PC suppliers and he said that `interrupt 9 is > referred internally to interrupt 2' and suchlike. I don't think this is relevant. The redirection is totally transparent to a program. > What is happening? Is it some new misfeature that has been put into BIOSes? This seems highly improbable. > Has this bug/whatever been cured in Windows 95? I don't think Windows 95 changes anything about the way keyboard is handled by the low-level BIOS functions. > _go32_dpmi_chain_protected_mode_interrupt_vector(9,&new_I9handler);}; Where's the call that actually installs the handler? The `chain' function only creates a wrapper, it doesn't hook the interrupt. > _go32_dpmi_set_protected_mode_interrupt_vector(9, &old_I9handler);}; Did you try to skip the unhook code? The DJGPP exit code will restore the keyboard handler anyway (since the startup hooks it), so you can try to skip that part and see what happens.