Mail Archives: djgpp-workers/1998/07/23/11:00:19
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.
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. 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).
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.
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.
- Raw text -