Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: Eli Zaretskii , Charles Sandmann , Morten Welinder , djgpp-workers AT delorie DOT com Date: Thu, 23 Jul 1998 14:38:51 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Ispell and pipes References: <9807231333 DOT AA16334 AT clio DOT rice DOT edu> In-reply-to: Precedence: bulk Eli Zaretskii 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