Mail Archives: djgpp-workers/1998/07/27/10:10:36
DJ Delorie <dj AT delorie DOT com> wrote:
> * gdb traps the program exit. Do the same thing as it does.
>
> * In fact, gdb traps int 0x31. Maybe your shell could somehow trap
> that *before* it gets to the DPMI server, so that longjump is still an
> option?
Hmmm.... but I want a djgpp shell because in this way we can try to add it to
bash.
> * Why not add a FSEXT that implements named pipes via your shell?
Don't know what's it. Please explain me a little.
> * Has anyone tried longjumping from one djgpp program to another
> (parent/child) program? If this works, the fsext can longjump
> to the shell, which can longjump to the other programs.
I tried both:
1) longjmps between 2 djgpp programs loaded in RAM.
2) longjmps through the shell (3 djgpp programs).
And yes it works but I'm having big troubles with spawn re-entrancy. I
explain it with details in the mail "Pipes".
I think the only way to do all with djgpp stuff is to have just 1 djgpp task
running from the DPMI point of view. And then make longjmps inside this "big
djgpp task". With it we won't have DPMI problems. But the exit clean up must
be done in the shell and not in __exit. That can be done just making a hook
in __exit to longjmp to the shell passing all the needed information in the
transfer buffer. Then the shell just makes the needed clean up.
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 -