🚀 go-pugleaf

In article <1766.AA1766@julie> mcr@julie.UUCP (Michael Richardson) writes:
>   Yes, but my getenv() command will look at the local one, and then
> arp/Manx, and finally 1.3.

This seems reasonable...

PUTENV should go into the 1.3 environment, though. You can always use the Manx
stuff for the Manx environment, and you can build your *own* RogueStart.

>   Hmm. Maybe I'm just a Unix weeny, but I like -option a LOT better than
> the silliness in AmigaDOS.

Both have advantages and disadvantages, but this is AmigaDOS, not UNIX. When
I write a program, I always stick to the syntax the machine uses, no matter
how silly it is:

	UNIX:	command -opts files
	Amiga:	command options files
	DOS:	command /opts files
	DEC:	command files/opts
	Sperry:	command,opts files

Eric Allman recently published an article in UNIX Review describing a common
interface that can handle all of these cases. It's called "parseargs" and will
(according to the publisher) soon come to a sources group near you.

>   That is why I put the `dummy' field in the same place as the number
> of workbench arguments went. Workbench doesn't ever pass zero arguments,
> (I hope.)

Well, you should also put a dummy in at sm_ArgList as well, then. Stick all your
flags at the end.

>   I'm not sure why I would want to?

Because a LOCK+name is the only unambiguous pointer to a file. Because you
need to remain consistent with Intuition. At the very least skip over all the
currently used fields.

Personally, I think you should have a magic number right after the current
startup message and put ALL your new fields there. And fill in all the gaps
in the existing message.

That way you can RogueStartup Workbench programs, and they work. It allows
for interoperability.

>   You see, part of my master-plan is to create ROOT:

I've thought of this one, too. It's a good idea. Go for it. But what does it
have to do with passing an array of file handles. You need to retain as much
interoperability as possible.

>   The whole point of the rs_dummy field is so that (if you like),
> you _can_ tell the difference between workbench and roguestart.

Yes, but you also want to be able to RogueStart workbench programs. If you
can do that then RogueStart can take over completely without hurting
anything. If not, it'll just become a third alternative...

> If
> anything, sm_ArgList[0] should contain a lock on the directory that
> the program came

Just like Workbench.

> peter>        Of course, you should probably not do this unless you know you
> peter>        have a Rogue program.
> 
>   I haven't decided how to recognise a Rogue program.

As you can see by some of my other comments, I've started to think that you
may be able to build RogueStart so it will safely start workbenchable
programs. In which case you don't need to recognise Rogue programs at all.

Have a regular WBStartup, a magic word (the 8 bytes 0xFEEDFACE 0xDEADBEEF
would make a fun one), and your extra fields. Then a Rogue program would
modify the magic word (say, to 0xDEADBABE). That way if you call a WB program
you know you may have more cleanup to do when you get the message back.

>   Hmm. I like the message passing concept. I'm not in love with the
> WBStartup.

It's better than Execute. More importantly, it's there.

>   My personal sanity depends somewhat on ConMan. I don't understand
> why ^S/^Q processing is such a strange concept to CA=. They had a
> chance to win me with NewCon:, but the ^S/^Q killed it.

Yes, but CONMAN isn't standard. Maximise interoperability and portability,
remember...

> I'll probably post to alt.sources.amiga (if that still exists,
> that is, I assume it was not a facsimile of Peter da Silva that created it)

alt.sources.amiga has been around for on the order of a year.
-- 
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"