Date: Wed, 22 Jul 1998 17:40:17 +0300 (IDT) From: Eli Zaretskii To: "Salvador Eduardo Tropea (SET)" cc: djgpp-workers AT delorie DOT com, Charles Sandmann Subject: Re: Ispell and pipes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Wed, 22 Jul 1998, Salvador Eduardo Tropea (SET) wrote: > and all the popen family. Btw, I think `popen' is the wrong vehicle for this. We need to make a working version of `pipe', `fork', and `wait' functions. But that's details which can be worked out later. > I don't think we can solve it without recompiling > because it will need to hook things to the DOS routines and hence we > will have problems with the fact that DOS isn't re-entrant. In general, if you do manage to hook the DOS interrupt, you don't need to worry about DOS non-reentrancy, since you see the call *ahead* of DOS. This means that when your RMCB is called, DOS is not yet busy, and you can do anything you want befoire chaining to DOS. > Ok. But what I propose isn't a direct jump. Instead the RMCB jumps to > a djgpp function that sets all the stuff to make the longjmp. So this > routine will restore the original stack. Maybe I miss something, but I don't see the difference between a single jump and two jumps. It's probably easier to just try this in a small test program. I never actually tried, so I might be ``haunted by the shadow of a dwarf'' here. > My idea is to be very far from int 21h as possible because if we > use int 21h we must lock all the code and that's a nono. Hooking Int 21h, if possible, is a very attractive solution, since it will work for all programs, not only DJGPP ones, and doesn't require them to be recompiled. However, it seems like this is a dead end, given the limitations of DPMI 0.9. Too bad. > > If you think about using the usual DJGPP RMCBs, then I think they > > *must* be locked, or CWSDPMI will abort your program. Charles, am I > > right here? > > Sorry, I fail to catch the idea, what do you think we must lock and > why? Charles once told me that CWSDPMI imposes a limitation on RMCBs, for safety reasons, and the upshot is that you must lock every code and data that is called by an RMCB. But I'm not sure I got it right, so I will wait for Charles to give the definitive answer.