www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/02/15/06:31:08

Date: Sun, 15 Feb 1998 13:28:55 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
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: <C5E3A253E3@fs2.mt.umist.ac.uk>
Message-ID: <Pine.SUN.3.91.980215132837.27889O-100000@is>
MIME-Version: 1.0

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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019