Date:	Sun, 2 Nov 1997 15:28:26 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Gurunandan R. Bhat" <grbhat AT unigoa DOT ernet DOT in>
cc:	djgpp AT delorie DOT com
Subject:	Re: Tracing the path of Software Interrupts
In-Reply-To:	<Pine.LNX.3.91.971101092517.412B-100000@aditya.unigoa.ernet.in>
Message-ID:	<Pine.SUN.3.91.971102152438.11098p@is>
MIME-Version:	1.0

On Sat, 1 Nov 1997, Gurunandan R. Bhat wrote:

> 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.

I didn't have time to look carefully at your code, sorry.

> 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.

Well, quite simply, it seems that Windows calls both handlers, just in
case. 

>       	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

I'm not sure.  What do you get when you hook 1Ch in PM only?  Do you 
indeed get all the ticks in your PM handler, or do some of them get lost?
(You need to do som DOS I/O, or call some BIOS services, to see the 
effect.)

- Raw text -