🚀 go-pugleaf

In article <1424@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes:
>  The negative command tail count has been received negatively.  That's
>OK, because there's still an "unreasonable" positive command tail
>length that isn't in use: 126 bytes.  Remember that GEMDOS only ever
>copies 125 bytes from the command tail passed to it in Pexec. 

  Unless you run into mixed-mode conflicts with processes that don't
  know about this limit and assume that 127 bytes of command tail means
  127 bytes of command tail.  The Pexec cookbook has not made it into
  the hands of all of the developers out there.

>  The various suggestions that deal with changing the behavior of Pexec
>are unacceptable for two reasons:
> 1) Folks with an older version of TOS would lose big.

  Whyso?  It should be possible for Atari, of all people, to figure out
  code that will correctly insert the values into old-style TOS basepages.
  And if that turns out not to be possible, it provides incentive for
  people to upgrade to the newer and hopefully better working ROMS.

> 2) We have just finished a TOS revision, and the next one won't be
>    complete for quite some time.  I would prefer for this standard
>    to be in place before that, so that the Desktop, et. al. can take
>    advantage of it.

  If the Desktop is wired into the ROMS, I fail to see how the desktop
  can take advantage of the new argument passing scheme before the rest
  of the OS does.

> It's just going to have to be the responsibility of library startup
>code to comply with the new standard.  Period.

  And if you have object-code-only modules that you can't get recompiled
  under the new libraries, you're out of luck? (What's the chance, for
  example, that Atari will recompile the Alcyon C compiler to take
  advantage of the new scheme?)

>  Using the basepage, or additional GEMDOS traps, won't fly either, for
>the reasons stated above. 

   You are Atari.  You can create a TSR a'la FOLDRXXX or CACHEXXX or ...
   to handle that.  I fail to see the moral difficulty of writing patch
   code to do the dirty work of loading in a real argc/argv space.

> 
>  So... here's GEMDOS Extended Argument Standard proposal #2:
> [omitted]

  And you're still cluttering up the environment with stuff that's
  not supposed to be there, but this time it's one *huge* string
  (which would look *awful from a printenv or any other command to
  print out the environment) and it relys on a "can't happen" value
  in the command tail that does* happen (it happened to me today, twice,
  while recompiling STadel - if I'd have been running the proposed
  standard I'd be getting _really_ lovely failures as cc tried to eat
  the command-line fed to make.  Lovely, and almost impossible to track
  down, because cc gives a usage message if the arguments are incorrect,
  but does not echo the arguments back at you) as well as using up an
  environment value that is may be used from inside other programs for
  other usages.

  If you're insistant on installing an environment kludge, at least give
  the damn thing some improbable name ("cLuTtEr=" comes to mind) and have
  it contain the address of its parents basepage for validation.  You're
  still filling the environment with cr*p that doesn't belong there, but
  then you eliminate the possibility of having the wrong child eat the
  environment and you drastically cut down on the chances of overwriting
  valid environment variable names.

  Xargs, at least, had the advantage of a minimal load on the environment,
  as well as a name (xArg) that will probably not conflict with anything
  that a user wants to stuff into the environment.


   -david parsons
   -orc@pell.uucp