Path: utzoo!dciem!nrcaer!fts1!julie!mcr From: mcr@julie.UUCP (Michael Richardson) Newsgroups: comp.sys.amiga.tech Subject: RogueStart (was Re: Using PIP: ) Summary: You must be kidding! There isn't anywhere near a paragraph per thought. Keywords: environment workbench startup Message-ID: <1766.AA1766@julie> Date: 11 Jan 90 21:06:13 GMT References: <4689@sugar.hackercorp.com> <1610.AA1610@julie> <1718.AA1718@julie> <4778@sugar.hackercorp.com> Followup-To: comp.sys.amiga.tech Organization: Sandleman Software Works' Debugging Department, Ottawa, ON Lines: 171 [ 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:/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