🚀 go-pugleaf

In article <1718.AA1718@julie> mcr@julie.UUCP (Michael Richardson) writes:
>   /* 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 */
	Probably should be OK.

>    char *rs_ToolWindow;       /* Usually NULL */
	I'd leave in sm_ArgList as well.

>    int  rs_argc;
>    char **rs_argv;
	So far so good.

>    int  rs_fhc;               /* Number of file handles to install */
>    long *rs_fhv;
	Not sure about this part. UNIXY, to be sure. But is it useful to
	get that far ahead of AmigaDOS?

>    int  rs_exitcode;
	Good.

>    BPTR rs_CurrentDir;
	Good. But I'd put this in sm_ArgList[0]. And put in the real program
	name in there too. Keep compatability with WB stuff.

>    char **rs_environ;         /* Arguments of environment space */
>    int  rs_envcount;          /* Number of variables */
	Not a good idea. You want to co-operate with AmigaDOS, and that means
	using env:.

>    char *rs_envspace;         /* Buffer containing variables */
>    int  rs_envsize;           /* Size of buffer */
>    long rs_closebits[2];      /* Close this filehandle (major kludge) */
	Why is this a kludge? It fits in well with rs_fhc/rs_fhv.

	Of course, you should probably not do this unless you know you
	have a Rogue program.

>   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.

There's a point to both. It'd be cooler to make RogueStartup a full superset
of WBStartup. Using some magic token to distinguish them.

>    ConMan is also a pipe-handler responding to the name PIP:NNNN...

Please don't make it depend on CONMAN, anyway.

> >        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 can't parse this statement. PIPE: doesn't like what?

>   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...

You can make "PipeDevice" "PIP:" if you know you need that. I don't use
ConMan (irrational prejudice... it just feels icky to REPLACE con:), so I
could use P:, PIPE:, whatever...

What order are you opening the pipes in?
-- 
Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com>
`-_-'
 'U`  "I haven't lost my mind, it's backed up on tape somewhere"