Date:	Thu, 19 Dec 1996 17:55:59 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Peter Berdeklis <peter AT chinook DOT physics DOT utoronto DOT ca>
cc:	djgpp AT delorie DOT com
Subject:	Re: Question about hardware interrupts...
In-Reply-To:	<Pine.SGI.3.91.961219101926.9361A-100000@chinook.physics.utoronto.ca>
Message-ID:	<Pine.SUN.3.91.961219173840.25806F-100000@is>
MIME-Version:	1.0

On Thu, 19 Dec 1996, Peter Berdeklis wrote:

> Sorry if I'm being obtuse Eli, but here it goes...

You aren't; it's just tricky.

> I understand that the interrupt reflection is expensive.  Still the FAQ 
> says that "When your program runs under a DPMI host, hardware interrupts 
> are always passed to protected mode first, and only if unhandled are they 
> reflected to real mode."  Are you saying that if you are temporarily in 
> real mode that you are temporarily not running under a DPMI host, so the 
> real mode interrupt gets it first

Yes and no.  The reflection to protected mode happens because the DPMI
host hooks all the real-mode hardware interrupts.  If you install your own
PM handler, the DPMI host will call your PM handler after the reflection. 
But when you install a real-mode handler, the relevant entry of the
real-mode ISR table will point to your handler, so it will be called
*instead* of the DPMI host, and the reflection is effectively disabled. 
So the ``always'' of the FAQ should really be taken with a grain of salt. 
Thanks for making me realize this, I will see that it is more clear in the
next release. 

> So in a real mode handler you shouldn't be calling disable() and 
> enable(), but rather cli and sti, so that you don't have to make a switch 
> to and from prot. mode?

I think you can't call `disable' and `enable' from the DJGPP library at 
all from the real-mode handler, since you are in real mode and cannot 
call DPMI functions at all.  You must write the handler in all-assembly 
and not call any non-trivial library functions.

> P.S. While I've got your attention... I have the latest version of Info.  
> I've compressed the info files, but Info doesn't find them with the 
> extension changed, e.g. from info to inz.  I had to change all the 
> references in the directories.  I have LFN=y - is that the problem.

Probably.  Did you try to call the files like God intended: .info.gz, 
.info-1.gz, etc?  I think it should work; if it doesn't, please tell me.
Do you use info.exe from the latest txi390b.zip?  It should be dated 
29 October.

- Raw text -