Mail Archives: djgpp-workers/1998/07/22/04:11:06
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?
- Raw text -