Mail Archives: djgpp-workers/1998/07/22/11:15:47
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
>
> 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.
Ok, I don't know enough about these functions.
> > 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 one technique I saw was hooking Int 0x29 (or similar) that
seems to be a DOS hook for capturing the output of a program and I
think that's called from inside DOS. I must check it.
> > 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.
What I say:
The RMCB jumps to one fixed function. It restores the program state
(PSP, some PID for the DPMI (?), stack, registers (?)) and jumps to
the point where we called B, it isn't a fixed place.
> 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.
Ok.
> > 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.
Ok.
SET
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -