🚀 go-pugleaf

  [ I was away for Christmas, so I'll respond to a whole bunch of
 stuff in one article. Please excuse any errors in attribution, I'm doing this in dme.]

In article <11223@thorin.cs.unc.edu> tell@oscar.cs.unc.edu (Stephen Tell)
responded to article <4778@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva),
both of whom were quoting this code:

     char **rs_environ;         /* Arguments of environment space */
     int  rs_envcount;          /* Number of variables */

peter>     Not a good idea. You want to co-operate with AmigaDOS, and that means
peter>     using env:.

tell> But env: is deficient in that its "global" and therefore you can't have
tell> more than one environment.

  Yes, but my getenv() command will look at the local one, and then
arp/Manx, and finally 1.3. putenv() may just do arp/Manx (since there
is little point in changing your own environment unless you want
to pass that on to a child, in which case I think I may implement something
like addenv() or something. I don't know yet.)

peter>I understand this. However you should retain compatibility with the system
peter>as it exists. Similarly, your programs should use AmigaDOS keyword argument
peter>handling rather than UNIX -option style, and they should work properly under
peter>the Workbench and CLI as well as RogueStartup.

  Hmm. Maybe I'm just a Unix weeny, but I like -option a LOT better than
the silliness in AmigaDOS. [Try getting a listing of a directory called
'DIRS'] Depending on how soon the 2630 comes out (and drops in price) how
cheaply I can get disk (and tape backup!) and SVR4, I may just find myself
a 32332 VME card and use the Amiga as my terminal. [I might even consider a
386.] That isn't the issue though, I like the Amiga, and I am a starving
part time student (well, actually, I eat rather than buy ram. I know where
my priorities lie.) so considering new equipement isn't really an option.

peter>If Getenv returns a different value depending on whether the program is
peter>started from RogueStartup and CLI that's a bad thing.

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

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

  [Drat, I saved these articles in the wrong order...]

mcr>    BPTR rs_Segment;
mcr>    LONG rs_dummy;             /* ALWAYS 0 -- would be NumArgs in WBStartup */
peter>        Probably should be OK.

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

  I'm not sure why I would want to?

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

  Yes, no.
  You see, part of my master-plan is to create ROOT: (I've already started
playing. I've got a simple file system with 26 possible single letter
filename. Coincidentally, they correspond to the letters of the alphabet. I
haven't got ExNext working yet though, I haven't figured out what (if
anything...) remains constant. I also haven't looked at NET: yet.)
  ROOT: will allow one to mount other file systems in its namespace, and do
packet forwarding -- well actually, it will be more of `packet translation'
--- I'd like to kludge a DupHandle() call. [I saw the '89 DevCon notes
yesterday, I'm quite upset over LockFromFH(), NameFromFH(), etc.. But, then
I'd already heard rumours of them on the net, from Colin Plumb, I believe]
  Before I go much further --- I should say: I doubt I will ever
get this working well, if at all. However, it will keep me busy when I
get tired of dealing with other people's problems...

mcr>    int  rs_exitcode;
peter>        Good.

  This was the main reason I started this. Execute() (the most
reliable way I could see to launch a program, wouldn't give me
the exit code. I knew of SyncRun(), but wasn't sure I wanted to get
into Arp at the time.)

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

  The whole point of the rs_dummy field is so that (if you like),
you _can_ tell the difference between workbench and roguestart. If
anything, sm_ArgList[0] should contain a lock on the directory that
the program came (quite usefull in many respects when it comes to
finding your binary. However, I don't necessarily believe in doing
things like modifing one's binary. I've stored data files [under SunOS]
with my binary, but that was a Lisp interpreter, and the data file
was in fact built from the symbol table of the binary, and was therefore
very intimitely related.)

mcr>    long rs_closebits[2];      /* Close this filehandle (major kludge) */
peter>    Why is this a kludge? It fits in well with rs_fhc/rs_fhv.

  The fact that it exists at all is the kludge. See debate over
DupHandle().

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. I may rely on
the user doing things correctly, I may build in (in my shell) a `ROGUEPATH' that
only holds Rogue binaries and just SyncRun() the other stuff (a Rogue
program can still be run at the CLI), or I may steal one of the
higher protection bits...

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

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

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

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

  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.

mcr>   My last resort. Pipe: doesn't like.

peter> I can't parse this statement. PIPE: doesn't like what?

  Pipe: doesn't like me. :-)

  In article <11223@thorin.cs.unc.edu>, tell@oscar.cs.unc.edu (Stephen Tell) wrote:
tell> Now if we were all to use env:<process-id>/variable, and use links where only
tell> a small part of the environment (or none at all) changed between a parent

  I can't say I like that. Yes, we need a global environment, but
an inherited environment is also a really neat idea.

tell> and its child...   (What? no links? aren't they "in there" too?)

  Not in 1.4 we were told (I can't argue), but never if the
lock -> file handle function is made bijective, and one can go from
a file handle to a lock.


  Umm... I hope I haven't stepped on any toes. :-)
  For those who hung in there this long (the 'n' key suspiciously close to
the home row...) and are curious what has happened to (rogue)
popen(av,ac,pp): it now uses CA= PIPE: and seems to function well. I
haven't done much more than run a couple of tests of it, so I not yet
certain. 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)
providing that fts1's feed (nrcaer, now on the internet) had in fact
created it, etc... I've never seen anything come through, but I haven't
exactly been watching. I let my roomate do that type of thing.




--

  :!mcr!:
  Michael Richardson
                    Amiga
             v--------+
 HOME: mcr@julie.UUCP | SCHOOL: mcr@doe.carleton.ca
 Fido: 1:163/109.10<--+ WORK: michael@fts1.UUCP