Date: Thu, 23 Jul 1998 17:59:49 +0300 (IDT) From: Eli Zaretskii To: salvador AT inti DOT gov DOT ar cc: Charles Sandmann , Morten Welinder , djgpp-workers AT delorie DOT com Subject: Re: Ispell and pipes In-Reply-To: <9807231333.AA16334@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.