Article View: comp.sys.amiga.tech
Article #13122Re: Using PIP:
From: Michael Richardson
Date: Sat, 16 Dec 1989 08:11
Date: Sat, 16 Dec 1989 08:11
202 lines
7387 bytes
7387 bytes
>In article <1610.AA1610@julie> mcr@julie.UUCP (Michael Richardson) writes:
>> alternate launching scheme, much more similar to the way the
>> workbench startup message works.
>
>Good for you.
>
>> I based it on Leo Shwab's wblaunch
>> code.
>
>Leo's? Not mine? What's Leo's look like?
I honestly don't remember. Rest assured that I refered to some code
that you posted at some point too.
>Where in the Startup message?
/* fast:exp/src/include/roguestar.h */
struct RogueStartup {
struct Message rs_Message;
struct MsgPort *rs_Process;
BPTR rs_Segment;
LONG rs_dummy; /* ALWAYS 0 -- would be NumArgs in WBStartup */
char *rs_ToolWindow; /* Usually NULL */
int rs_argc;
char **rs_argv;
int rs_fhc; /* Number of file handles to install */
long *rs_fhv;
int rs_exitcode;
BPTR rs_CurrentDir;
char **rs_environ; /* Arguments of environment space */
int rs_envcount; /* Number of variables */
char *rs_envspace; /* Buffer containing variables */
int rs_envsize; /* Size of buffer */
long rs_closebits[2]; /* Close this filehandle (major kludge) */
};
Hmm... Guess I put in 64 bits for FileHandles...
From boot:install/aztecc/include/workbench/startup.h:
struct WBStartup {
struct Message sm_Message;
struct MsgPort * sm_Process;
BPTR sm_Segment;
LONG sm_NumArgs;
char * sm_ToolWindow;
struct WBArg * sm_ArgList;
};
>What's the point of this? Workbench will pass variable numbers of arguments,
>and usually at least one (dirlock & name of the program itself).
I don't want the locks. I pass the full file names. A possible modification
would use exec List instead of an array to hold the arguments.
Note: the RogueLaunch program allocates memory for the argv and envp,
and copies. The child does own them. They are cleaned up by the cleanup
process. In order to provide the ability to invoke an synchronous task
and later decide to make it asynchronous (just don't close your window!)
I'll eventually turn this into rogue.library, and have it CreateProc()
an `init' process that will actually wait on the subprocesses, deallocate
storage and return error codes when you `RogueWait()' (or don't wait)
[who was it that was working on Edition 7 under AmigaDOS --- Doug Merrit
no? How is it going?]
>More details, please.
fast:exp/src/rogue/_main.c:
/* Copyright (C) 1986,1987 by Manx Software Systems, Inc. */
[ What I'm to do about that line, I'm not sure yet. ]
[blayh blah blah]
pp = _FindTask(0L);
if(alen) {
_cli_parse(pp, alen, aptr);
argc=_argc;
argv=_argv;
Enable_Abort = 1;
_devtab[0].mode |= O_STDIO; /* shouldn't close if CLI */
_devtab[1].mode |= O_STDIO;
goto normsetup;
}
else {
int i;
char *window;
long wind;
struct FileHandle *fhp;
_WaitPort(&pp->pr_MsgPort);
RogueStartMsg = (struct RogueStartup *)GetMsg(&pp->pr_MsgPort);
if(RogueStartMsg->rs_dummy==0) {
argv=RogueStartMsg->rs_argv;
argc=RogueStartMsg->rs_argc;
environ=RogueStartMsg->rs_environ;
pp->pr_CurrentDir=RogueStartMsg->rs_CurrentDir;
CurrentDir(RogueStartMsg->rs_CurrentDir);
if(window=RogueStartMsg->rs_ToolWindow) {
if(wind = _Open(window, MODE_OLDFILE)) {
fhp = (struct FileHandle *) (wind << 2);
pp->pr_ConsoleTask = (APTR) fhp->fh_Type;
pp->pr_CIS = (BPTR)wind;
pp->pr_COS = (BPTR)_Open("*", MODE_OLDFILE);
goto normsetup;
}
}
else if(RogueStartMsg->rs_fhc) {
for(i=0; i<RogueStartMsg->rs_fhc; i++) {
_devtab[i].fd=RogueStartMsg->rs_fhv[i];
if(i<32) {
if((RogueStartMsg->rs_closebits[0]&(1L << i))==0) {
_devtab[i].mode |= O_STDIO; /* shouldn't close if CLI */
}
}
}
pp->pr_CIS=_devtab[0].fd;
pp->pr_COS=_devtab[1].fd;
}
else {
normsetup:
_devtab[0].fd = _Input();
if(_devtab[1].fd = _Output())
_devtab[2].fd = _Open("*", MODE_OLDFILE);
}
}
else {
/* We'd do the normal Workbench thing here */
/* I suspect that this branch crashes. I don't run workbench and
draw icons often enough to have every tried it.*/
_exit(254);
}
}
_exit(main(argc, argv)); /* so much for `void main()' :-) */
}
> if((pin=AllocMem(sizeof(struct FileHandle),MEMF_PUBLIC|MEMF_CLEAR))==NULL) {
> return(NULL);
> }
> if((pout=Open("PIP:4096",2000L))==NULL) {
^^^^^
man:util/ConMan.doc:
ConMan V1.3
Copyright (c) 1987, 1988 by William S. Hawes
....
ConMan is also a pipe-handler responding to the name PIP:NNNN, where
NNNN is the "capacity" of the pipe. It must be opened using a private
packet called ACTION_DOUBLE (value 2000L), and the filehandle you get
from a call to Open("PIP:",2000) counts for two and so can be cloned
by your program. After allocating a filehandle structure (using the
AmigaDOS memory conventions), just copy the filehandle from Open()
into the new structure --- and don't forget to Close() both of them!
My WShell command shell uses the ConMan PIP: device as its pipe handler.
Does this follow better now?
>(too bad there's no DupFH call. Commodore? Are you there Commodore? How about
> for 1.4?)
YES. PLEASE.
I believe that Colin Plumb had some other things to peeves having to
do with getting path names from FileHandles. I think they deserve to be
repeated...
(Colin: remember that `message' you wrote me concerning CRCs? All 22k of it?
I posted it as crcinfo.zoo on 1:163/109 [aka atronx.UUCP, soon to be amiga.ottawa.on.ca].
The download count is quite respectable...)
>Sounds good. Where's the code?
Coming. I want a working popen() call and I have to write the environment
variable stuff...
>Why don't you do this?
>
> sprintf(PipeName, "%s:rogue%dpipe%d", PipeDevice, ProcessId, Sequence++);
> pin = Open(PipeName, MODE_NEWFILE);
> pout = Open(PipeName, MODE_OLDFILE);
My last resort. Pipe: doesn't like.
I've spent hours running dnet both here to school, and between myself and
other people, and I've _never_ gotten the scli server to work the DPIPE:,
or Matt's original pipe, or the 1.3 pipe...
It took me three days to run Markus Wandel's exec disassembly because I
couldn't get the pipes to work. They just don't like me.
--
:!mcr!:
Michael Richardson
Amiga
v--------+
HOME: mcr@julie.UUCP | SCHOOL: mcr@doe.carleton.ca
Fido: 1:163/109.10<--+ WORK: michael@fts1.UUCP
Technical Details
Message-ID:
<1718.AA1718@julie>Path:
arc1-ca.pugleaf.net!utzoo!dciem!nrcaer!fts1!julie!mcrReferences:
<4689@sugar.hackercorp.com> <1610.AA1610@julie>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!dciem!nrcaer!fts1!julie!mcr From: mcr@julie.UUCP (Michael Richardson) Newsgroups: comp.sys.amiga.tech Subject: Re: Using PIP: Keywords: dupping closing pipes Message-ID: <1718.AA1718@julie> Date: 16 Dec 89 08:11:38 GMT References: <4689@sugar.hackercorp.com> <1610.AA1610@julie> Followup-To: comp.sys.amiga.tech Organization: Sandleman Software Works' Debugging Department, Ottawa, ON Lines: 202