Date:	Tue, 23 Sep 1997 13:02:57 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>
cc:	djgpp AT delorie DOT com, spector AT EnchantedLearning DOT com
Subject:	Re: DJGPP, interprocess communication, and DPMI
In-Reply-To:	<m0xD6Or-000S1kC@inti.edu.ar>
Message-ID:	<Pine.SUN.3.91.970923130231.14928I-100000@is>
MIME-Version:	1.0

On Mon, 22 Sep 1997, Salvador Eduardo Tropea (SET) wrote:

> It takes much more than a memcpy (I can see the time of the memcpy while 
> debugging, it seems to be instantaneouslly to the human eyes, but the time 
> needed to report the length of a 350Kb clipboard by the WindOldApp
> routine is very high because I can see the delay.

So what you see is that Int 2Fh/AX=1704h is what takes most of the
time, right?  If so, maybe this time could be slashed by not using
this service at all?  If the clipboard is used for communication
between two cooperative programs, you could put the size of the data
as the first element of the message.  Then the application that needs
to get the data would access the first word, then read that many bytes
from the clipboard.

> > > I think one solution could be a real mode TSR loaded before windows.
> > 
> > This might or might not work with Windows 95, because it catches
> > real-mode interrupts on different levels and not always lets them go
> > all the way down to your TSR.
> 
> Are you sure that Win95 will interfer a TSR loaded before the GUI
> and that only uses the multiplex?, I don't thing so. If Lose '95
> makes that it breaks a lot  of TSRs. 

Well, it is known that it breaks at least *some* of the TSRs.  For
example, TSRs that expect to intercept DOS file-related calls usually
don't work with Windows 95, because the 32-bit file access completely
bypasses DOS.

I don't know whether this is relevant to the multiplex interrupt.
But at least some of the functions of that interrupt are
used/generated by Windows.

- Raw text -