Mail Archives: djgpp-workers/1998/07/23/13:31:25
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> There is another way to accomplish this, I think. It's close to what
> Charles suggested, but it looks like there would be less trouble with
> making it happen.
Yes, last night I was experimenting and I finally did a similar
thing, but it makes longjmps from one program to the other. I have a
program that sends information from the child to the parent, but
needs some adjust to avoid problems when the child returns.
> The idea is for the parent program to load the child program as if it was
> a debuggee, using a variant of `v2loadimage' from
> src/debug/common/v2load.c.
I think that's good. I tried the experiment using system but there
are various complex things involved.
> Then you need to hook int 31h (dbgcom.c
> already does that, but for this purpose we need to handle additional
> functions of int 31h). Assuming the child program uses __dpmi_int for all
> its DOS I/O, the int 31h handler will be called for each such request. It
> will then filter only the calls to int 21h functions which are
> ``interesting'' (which read and write to files or devices), satisfy the
> requests by moving data along the simulated ``pipe'', and ``multi-task''
> by ljmping between the parent and the child according to the
> circumstances (e.g., if program A reads from an empty pipe, ljmp to
> program B).
I think is possible.
> If this approach makes sense, it has a tremendous advantage of being
> based on the DJGPP debug support which is well-tested and
> well-understood.
>
> No doubt, there are some problems that need to be solved for this to work
> reasonably (some of them are listed below), but I don't see any
> show-stoppers, and if it has to work on DOS, this is the starting point
> that I would recommend.
>
> Comments? Charles, Morten, can you see any serious pitfalls that I
> overlooked?
>
> Here are some problems with the above approach that came to my mind:
>
> Problem 1: The parent and the child share file handles (since as far as
> DOS is concerned, there's only one process running). This means that if
> you hook int 31h and monitor calls to __dpmi_int that invoke I/O on
> handles 0-2, you don't know whether the call comes from the parent or
> from the child.
>
> Solution: The parent should install a hook (via the Filesystem
> Extensions) for its own I/O on handles 0-2, dup2 these handles to other
> handles, and when the hook is invoked, it will redirect the call to those
> other handles. This way, the int 31h handler will only see calls that
> reference handles 0-2 from the child program.
What about a flag that in the parent that indicates we are running
the parent? Then if we catch a request while we are running the
parent we pass it to int 21h.
> Problem 2: Signals support. We need to provide some minimal possibility
> to control which one of the two programs gets the signals, at least
> SIGINT. I'm not sure, but I think that the current debug support doesn't
> solve this. If so, some trickery with hooking the hardware keyboard
> interrupt will be needed at the point where we ``task-switch''.
>
> Problem 3: Many programs need to be duped into thinking that their
> stdin/stdout is redirected to something other than the console device, in
> order to behave correctly. For example Ispell will only work in this
> ``slave'' mode if its stdin is not the console; otherwise it will use
> conio functions.
>
> Solution: In the int 31h handler installed by the parent, monitor the
> IOCTL function issued by `isatty' and feed the child with a required
> result.
When I played with the longjmp stuff I saw the following things:
* Normally you don't need to save/restore ALL the registers because
is better to indicate a memory clobber inserted at the point we are
jumping.
* What happends with a program using floating point?
I was able to create an example using RMCBs and almost finished one
that uses direct longjmps from one program to the other (Currently
breaks at the end because a stack problem). But the interrupt hooking
looks less complex.
Eli: Are you planning an implementation or test for it?
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 -