bruss@odin.ucsd.edu (Brian Russ) (01/03/89)
Here's what I want to do. Program X starts up, opens a custom screen and perhaps a window, and then Execute()'s another program Y. I wish for Y to write into the window opened by X (or, alternatively, Y can open a window and attach it to X's screen and "inherit" (for want of a better term) X's screen's info). Is this possible? Can Y find X's screen/window and use it? Is it dangerous? I suppose I could have Y open it's own screen but I prefer it this way ... oh, I'm using Manx C if that's any help. Apologies if this isn't techie enough for .tech. Thanks, Brian Russ Brian Russ CSE Department, UC San Diego ..!sdcsvax!bruss
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/05/89)
In <5715@sdcsvax.UUCP>, bruss@odin.ucsd.edu (Brian Russ) writes: > Here's what I want to do. Program X starts up, opens a > custom screen and perhaps a window, and then Execute()'s another > program Y. I wish for Y to write into the window opened by X > (or, alternatively, Y can open a window and attach it to X's screen > and "inherit" (for want of a better term) X's screen's info). > Is this possible? Can Y find X's screen/window and use it? Yes, it's possible. One method is to simply have program X pass the window address to program Y via a message, but ... > Is it dangerous? I suppose I could have Y open it's own screen but ... remember, you are accessing a common resource. If program X has responsibility for closing the window, you must make sure that program Y does not attempt to use it after program X closes it. Program X must not close the window unless it is sure that program Y is not going to try to acccess it again. Be especially careful of abnormal exits on the part of either program. This is an area that is often overlooked, the abnormally exiting program failing to properly check for some necessary condition, of failing to notify the other program of the situation. You can use bidirectional messaging to synchronize all aspects of operation, and perhaps semaphores will do it (not familiar with semaphore usage). > I prefer it this way ... oh, I'm using Manx C if that's any help. It doesn't matter. The underlying principle is the same in all languages. > Apologies if this isn't techie enough for .tech. Looks OK to me. -larry -- Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (01/06/89)
> Here's what I want to do. Program X starts up, opens a >custom screen and perhaps a window, and then Execute()'s another >program Y. I wish for Y to write into the window opened by X >(or, alternatively, Y can open a window and attach it to X's screen >and "inherit" (for want of a better term) X's screen's info). > Is this possible? Can Y find X's screen/window and use it? Is >it dangerous? I suppose I could have Y open it's own screen but >I prefer it this way ... oh, I'm using Manx C if that's any help. > Apologies if this isn't techie enough for .tech. > > Thanks, > Brian Russ Set X's process->pr_ConsoleTask to the console handler for the new window. This will also involved openning the console device for that window. In your Execute() call, redirect stdin and stdout to *: "program >* <* ..." That ought to do it. I haven't tested this. Dangerous? Make sure Y has a valid file-handle reference to the console device or you *will* be in big trouble! That is, setting the process->pr_ConsoleTask alone does not bump the reference count in any way, shape, or form. Better to have X make sure Y has died before closing the console device and window. Specifically, do not CloseWindow() the window unless you are sure nobody is using it! -Matt