Mail Archives: djgpp-workers/1998/07/22/08:48:11
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> > (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.
Yes I mean that. Is very difficult to read the man pages with all the
deletes floating around.
> 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.
Yes I know, but a not a new user. You said in this list (twice one to
Gili and one to me) that info files are shipped in DOS format because
some DOS editors fails to break the lines in '\n'. Here is worst,
I don't know about even one DOS editor that parses the delete
characters ;-).
> > 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.
Yes I saw the 90Kb ELisp file.
> > 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.
Of course, I think the only way is replace the current libc functions
for console I/O (to use special routines if we are piped) and all the
popen family. I don't think we can solve it without recompiling
because it will need to hook things to the DOS routines and hence we
will have problems with the fact that DOS isn't re-entrant.
> 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.
Ok. But what I propose isn't a direct jump. Instead the RMCB jumps to
a djgpp function that sets all the stuff to make the longjmp. So this
routine will restore the original stack.
> 3) The current RMCBs are non-reentrant. This might not be a problem
> if we use an interrupt other than 21h, though.
Ok. My idea is to be very far from int 21h as possible because if we
use int 21h we must lock all the code and that's a nono.
> > 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.
Yes, I just expossed the things in one direction to show the idea.
But is true pipes are bidirectional in a lot of cases. Additionally
the system must be bidirectional because in the next read from A we
already started B and this time we must return to the point that
called A.
> > 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?
Sorry, I fail to catch the idea, what do you think we must lock and
why?
> > 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).
Ok, then is different. The idea is that the entry point in A will
restore the stack and jump to the line after the call to B. And
perhaps restore the registers or indicate the clobbering with a
macro.
> > 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.
Ok, I did the PSP stuff some years ago for a TSR that writes to disk
so I supposed it was needed here too.
> As to the DPMI host, I don't know what's involved in notifying it
> about the task switch. Charles?
Ok.
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
- Raw text -