Date:	Wed, 22 Jul 1998 17:40:17 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
cc:	djgpp-workers AT delorie DOT com, Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject:	Re: Ispell and pipes
In-Reply-To:	<m0yyyFb-000S4bC@inti.gov.ar>
Message-ID:	<Pine.SUN.3.91.980722172913.12232F-100000@is>
MIME-Version:	1.0

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.

- Raw text -