Date:	Tue, 23 Sep 1997 13:32:14 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Mitchell Spector <spector AT EnchantedLearning DOT com>
cc:	djgpp AT delorie DOT com,
	"Salvador Eduardo Tropea (SET)" <salvador AT natacha DOT inti DOT edu DOT 2alpha DOT com>
Subject:	Re: Clipboard timing, strange results, Rhide (Was: DJGPP, interprocess communication, and DPMI)
In-Reply-To:	<3427709F.1212@EnchantedLearning.com>
Message-ID:	<Pine.SUN.3.91.970923132243.14928R-100000@is>
MIME-Version:	1.0

On Tue, 23 Sep 1997, Mitchell Spector wrote:

>    I ran it in a DOS box under Windows95, and found that I got
> 40-50 iterations per second.  That's slow, but that's not the
> surprising part.  The surprising part came when I launched
> Rhide, spawned a DOS shell from within Rhide (using the DOS shell
> menu item), and found that I got between 700 and 850 iterations per
> second!

Doesn't RHIDE hook the timer interrupt?

It might also matter that it hooks other hardware interrupts, such as the 
keyboard, because Windows then might change the scheduling of that DOS 
box.  Try changing the Idle Sensitivity property and see if that matters.

>    Does anybody know what difference there is between a DOS box
> spawned directly by Win95 and a DOS shell spawned by Rhide that
> could account for a 15-fold speed improvement when running
> under Rhide's DOS shell?  Are interrupts handled differently
> in some way?

What happens if you spawn a DOS shell from a trivial DJGPP program, not
from RHIDE? 

>    I checked the various PIF's, but I don't see any differences
> between them (the PIF memory settings for DPMI memory, etc.,
> are all Win95's stock "Auto" setting).

"Auto" means that you are at Windows' mercy.  Try setting 65535 (or any 
other constant number) in both and see whether the difference still 
persists.

>    When I remove the interrupts from the program entirely,
> leaving just the overhead (loop, timing, and counting), the
> difference disappears, and I get around 3 million iterations
> per second, whether via Rhide or not.  (Incidentally, this shows
> that the overhead is insignificant and that the interrupts
> themselves are very, very slow.)

Try to leave the call to __dpmi_int, but replace the interrupt and the 
function by something else.  E.g., let it return the BIOS clock tick, or 
something else that should be almost a no-op.  It might be that the 
actual mechanism of issuing a real-mode interrupt is the slow part, not 
the specific WINOLDAP interrupt that you are testing.

- Raw text -