Date: Wed, 22 Jul 1998 11:10:43 +0300 (IDT) From: Eli Zaretskii To: "Salvador Eduardo Tropea (SET)" cc: djgpp-workers AT delorie DOT com, Charles Sandmann Subject: Re: Ispell and pipes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 21 Jul 1998, Salvador Eduardo Tropea (SET) wrote: > I don't like M$ products so forget about Word. ^^^^^^^^^^^^^^^^^ Ha! That must be the understatement of the decade! > (BTW why the man pages are in the native format? isn't better just > plain text, that's better for DOS). What do you mean by ``native format''? The man pages are distributed after formatting by Groff, so they *are* plain text, except that some words are highlighted by overstriking. If you use Less to browse them, you will see those words stand out in colors, and the Emacs man-page command highlights these words with colors as well. If you use info.exe to browse them, then it shows them as simple text. > I saw ispell have a mode to interact with a program and in this way > you can use another user interface. That's cool but .... it looks > like we need much more than what the djgpp pipes support. As ispell > interacts with the other program both tasks must be loaded at the > same time and the pipes acts like a comunication channel. Our pipes > aren't suitable for it. Yes, this requires asynchronous processes. Emacs has a nice interface for Ispell that uses this mode, which doesn't work in the DJGPP-compiled version of Emacs. > Solution? is that even possible? It's probably possible, but it seems to be hard. I was thinking about different possibilities to implement asynchronous subprocesses in such a way for the past year ;-). This would allow e.g. to run a compiler from an editor and allow the editor both to catch the messages and continue editing. Unfortunately, I didn't have enough free time lately to accomplish this myself, but I'd be thrilled to participate in such a project. > As B detects it B doesn't write to screen and doesn't call DOS, > instead calls the RMCB that A created. The RMCB can be an interrupt > vector and perhaps the parameters could be the same used for a DOS > write. Anyways B calls to it passing the data in the TB. > DPMI switchs to real mode and goes back to pmode through the RMCB. > Now we are back in A but in a different point. The routine stores the > parameters in a global variable (or better in a structure pointed by > a global variable) and makes a longjmp to the line after the call to > B (of course we must store the needed information before running B). You don't tell, but I'm guessing that what you have in mind is either to establish a special software interrupt, or to use the simulate far call DPMI function, to be used by DJGPP programs for this kind of multi-programming. Even if we can live with the limitation that only DJGPP programs can be run that way, there are still several nasty problems to overcome: 1) Since the interrupt used is not Int 21h, Ispell itself will need to be recompiled, to support this. In general, any DJGPP program that needs to be run as a child process in such a way, needs to be recompiled. 2) The current RMCB support probably needs to be reimplemented, as it has some disturbing limitations. For example, it allocates its own stack, so longjmp'ing from an RMCB to the line after the one which launches program B is not trivial, since that code used the usual DJGPP stack. 3) The current RMCBs are non-reentrant. This might not be a problem if we use an interrupt other than 21h, though. > So now we are back in A just like if B made a return. > A takes a look to the structure above mentioned and detects that B > filled it with information about a write, so transfers it to the > pmode memory and returns to the calling function. You also need that B creates such an RMCB as well, so A could talk to it in turn. The pipes are usually bidirectional. > 1) Looks like no code needs to be locked because DOS isn't involved > in the change. Is that correct? If you think about using the usual DJGPP RMCBs, then I think they *must* be locked, or CWSDPMI will abort your program. Charles, am I right here? > 2) The longjmp seems to be possible because is very similar to the > technique used by the current djgpp task switchers, no? I think the multi-taskers do a different thing, since they share the same stack (albeit subdivided into several parts). > 3) And here comes the real: Is this program switch possible. I mean: > is possible to inform to the DPMI host that now A is running and not > B? Or the host will know it? The host won't know, there's no magic here. There's actually more than just DPMI host that's involved here. You must also notify the OS that another program is running, otherwise it will use the wrong file handle table to service I/O calls which refer to handles. This means you need to call the DOS SetPSP function in the RMCB as one of the first things it does. As to the DPMI host, I don't know what's involved in notifying it about the task switch. Charles?