Date: Tue, 23 Sep 1997 13:02:57 +0300 (IDT) From: Eli Zaretskii To: "Salvador Eduardo Tropea (SET)" cc: djgpp AT delorie DOT com, spector AT EnchantedLearning DOT com Subject: Re: DJGPP, interprocess communication, and DPMI In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.