Date: Mon, 29 Sep 1997 10:31:54 +0200 (IST)
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, Robert Hoehne <Robert DOT Hoehne AT Mathematik DOT TU-Chemnitz DOT DE>,
        "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT 2alpha DOT com>
Subject: Re: Clipboard timing, strange results, Rhide (Was: DJGPP, 
In-Reply-To: <342F4975.40CE@EnchantedLearning.com>
Message-ID: <Pine.SUN.3.91.970929102402.1917M-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Sun, 28 Sep 1997, Mitchell Spector wrote:

> that apparently just checks a version number!).  But the interrupt
> which gets the current video mode took about 1/40,000 sec.  Also, the
> Windows interrupt which gets the current Windows enhanced mode
> version took about 1/40,000 sec.

I'd suggest trying other interrupts as well, such as BIOS-related ones.  
For example, how about Int 16h, the keyboard interface?

The reason for the difference in performance might be that different 
interrupts are handled by different layers in Windows, and the thunking 
between the layers might induce serious overhead.  Both of the interrupts 
that you tested (apart of WINOLDAP) are likely to be handled by Windows 
efficiently: video BIOS interrupt is display-related, and 
GetWindowsVersion is probably the most used function on Windows.

Btw, which Windows is that?  I don't recall you telling this.

>    I'm not sure it's worth much more time trying to figure out
> exactly what is happening here; the bottom line is that the
> WINOLDAP interrupts are simply too slow to be useful in any
> performance-sensitive situation.

This depends on how performance-sensitive it is.  Passing data between an 
editor and a compiler that had been launched by that editor might not be 
too sensitive, even to the dreadfully slow performance that you found.