Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: djgpp-workers AT delorie DOT com Date: Tue, 21 Jul 1998 11:51:24 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Ispell and pipes Precedence: bulk Hi All: Context: My english is pretty bad so I was thinking about using some spell checking program. I don't like M$ products so forget about Word. I think ispell must be ok. But ispell have a not so cue user interface, so I taked a look to the man pages (BTW why the man pages are in the native format? isn't better just plain text, that's better for DOS). The problem: 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. Solution? is that even possible?: So I was thinking about it: Suppose you have a djgpp program A running and a djgpp program B on disk. Program A opens a pipe to read the output of B. Popen just fills a structure and does nothing. Program A call to read from the pipe. The read function detects that the pipe wasn't started so checks if B is a djgpp program (if not the old methode is used). As B is a djgpp program A setups a RMCB somewhere and starts B passing some magic information that will inform B that your output is redirected to another djgpp program. Now B is running, and writes to the output, the routines for stdout currently checks if the output is redirected additionally here the routines must check if the redirections is to another djgpp program. 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). 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. Now my doubts about it are: 1) Looks like no code needs to be locked because DOS isn't involved in the change. Is that correct? 2) The longjmp seems to be possible because is very similar to the technique used by the current djgpp task switchers, no? 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? What about sbrk(), will it enlarge the heap without problems? 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