Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!ames!pacbell!att!ihlpb!TSfR!usenet
From: usenet@TSfR.UUCP (usenet)
Newsgroups: comp.sys.atari.st
Subject: Re: Extended argument passing conventions in Pexec() [MWC]
Summary: Just being `there' is *no* reason to make a standard
Message-ID: <525@TSfR.UUCP>
Date: 18 Apr 89 20:07:42 GMT
References: <841@per2.UUCP> <1453@atari.UUCP> <546@bdt.UUCP>
Reply-To: orc@pell.UUCP (David L. Parsons)
Followup-To: comp.sys.atari.st
Organization: Department of Atomic Text Units
Lines: 69
Expires:

In article <546@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes:
>In article <1453@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes:
>>[ about the MWC ARGV method ]
>>It is simple, yes, and it simply won't work....
>
>Ken, it sure looks like you want to attack MWC here.  If the method is
>"standard", "good" programs won't mess with the environment in "bad" ways.

 Except old programs that don't follow that `standard' will still be stuck
 with large oddities in their environment.

>
>I think something that Allan Pratt (sp?) suggestted a long time ago where
>the parent places a variable like "PARENT=" or simething which contains the
>parents basepage address is a reasonable additional method of validation
>of the ARGV environment...

 By cluttering the environment with yet another variable?  Great.  That's
 just what's needed - even more flot.

>
>>That's very nice, but the other two methods of extended argument passing
>>don't require ANYBODY to be insulated from them.  In fact, all THREE
>>methods can peacefully coexist in one system, except that ARGV will
>>cause problems for programs which haven't been "innoculated" against it.
>
>Say what?  Are you saying that I won't have to upgrade any of my 500 or
>so utilities?

 If they know about the commandline in the basepage, why should they need
 upgrades?

> ... None of my 25,000 customers will need upgrades with the new
>Atari standard?...

 It cuts both ways.  Those of us who use the other ways to pass arguments
 around may end up having to modify our code to work properly with the
 new standard, whatever it may be. 

> ... You see all approaches are going
>to require lot's of binary patch programs and upgrades. ...

 Why?  I've got programs that don't use xArgs and they coexist just fine
 with xArgs.  I cannot imagine that the MWC `standard' works out any
 differently, except for the magical appearance of garbage in the
 environments of the (non-conformant) child processes.

>I think you're forgeting how many *commercial* programs use the ARGV
>"standard".  This will play a big role in the standardization phase.

 And you may be forgetting how many shareware programs use xArgs.
 Considering that dlibs and Sozobon C both use xArgs, the percentage
 of programs using that `standard' will grow.

 Your comment that real argc/argv should be a extention to Pexec() is
 correct, and I agree that it's what Atari should be doing.  But saying
 that the MWC style should be the second choice because it's `there' is
 like saying "we can't fix Malloc() because people take advantage of
 the broken code."

 At risk of sounding like a broken record, I'll note again that one of
 the reasons that Dalnefre', John Stanley and I made up the xArgs method
 is that we (well, *I* - I dunno about Dale and/or John) didn't think that
 the MWC method was worth it's weight in fetid dingos kidneys.  Cluttering
 up the environment with untracable arguments and iovector `stuff' is
 about as unaesthetic as you can get.

   -david parsons
   -orc@pell.uucp