Date: Sat, 1 Nov 1997 09:43:12 +0000 (   )
From: "Gurunandan R. Bhat" <grbhat AT unigoa DOT ernet DOT in>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp AT delorie DOT com
Subject: Re: Tracing the path of Software Interrupts
In-Reply-To: <Pine.SUN.3.91.971102145701.11098c-100000@is>
Message-Id: <Pine.LNX.3.91.971101092517.412B-100000@aditya.unigoa.ernet.in>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk



On Sun, 2 Nov 1997, Eli Zaretskii wrote:
>
> On Fri, 31 Oct 1997, Gurunandan R. Bhat wrote:
> 
> > 	When I do this for the software interrupt (0x1c) I get a result
> > that to my **limited** understanding, is strange. It is always the real
> > mode interrupt that is called. My buffer is strewn with 'r's. This is the
> > same no matter which of the three DPMI hosts I use: cwsdpmi, cwsdpr0 or
> > pmode/dj.
> 
> In what order did you install the handlers?  Was the RM one installed
> before or after the PM one?

No. As the FAQ recommends, the PM handler is installed first. The RM 
handler (callback) is installed later.  

> Also, you need to make sure your system switches to real-mode with
> sufficient frequency, to see both handlers called.

The problem as I understand it is that it is the PM handler that is never 
called. If you check the code attached at the end of earlier post, you 
will see that I have a long loop where I do a series of pointless 
multiplies (which are not optimised as I checked) which take about two 
seconds so I should see at least 36 p's in my buffer. No such luck.

> > But when I run the same program in Windows 3.11, I get an
> > alternating string of 'p' and 'r' like: prprpr...., *even* when I do not
> > chain out of the protected mode handler.
> 
> That might be something special about Windows.  I'm not sure.

Yes, Indeed. Windows is known to virtualise *software* ints differently 
from CWSDPMI as many posts in the mail archives report. What I would like 
to know is why the exact sequence p-r-p-r-p... even when I do not chain 
to the default (RM ?) handler.

> > The DPMI specs say that int 0x1c is special in that, it is
> > always handled by the protected mode handler *even* when a real mode
> > handler is installed.
> 
> That is correct, AFAIK.  Int 1Ch is handled like a hardware
> interrupt in this sense.

With my very *limited* understanding of these issues the only way I can 
understand the sequence is by the follwoing logic:

      	Int 0x1c is called by the Int 0x8 handler during 
	its operation which requires a lot of RM operations.
	If the Int 0x8 handler is optimised to avoid an 
	expensive mode switch merely to iret (the default
	Int 0x1c operation) then Int 0x1c will be called
	when the CPU is in real mode. This explains the r's

Please correct me if I am wrong

Thanks for responding