🚀 go-pugleaf

Here is a summary of some of the mail & messages I've seen in the past
week regarding the proposed GEMDOS Extended Argument Standard:
 
 
David Beckemeyer writes:
------------------------ 
What about the transition period?  There are a whole bunch of programs
that use the current MWC style ARGV.  MWC programs, and anything
compiled with their libraries use iovector and they don't always work
right when it's not there.  Also I bet even if MWC does implement the
new standard, it will take a while and many users won't change over for
a long time.  This leaves an ever increasing number of programs that
won't understand the new format (and probably won't work right). 
 
The next issue is the idea of the "negative" command tail count.  I wonder
if some startup code might just take the value as 8-bit unsigned and attempt
to grab, say 254 bytes from the tail without checking and maybe bomb out in
attempting it (I've seen programs that do worse).
 
I don't see how [leaving just the iovector after ARGV] can work, since
the old MWC ARGV is *always* followed by the list of arguments.  If the
the new name has the arguments, you can't put them after ARGV too. 
 
 
John Dunning writes: 
-------------------- 
I think the scheme you outlined (use the magic env var "ARGV=..." as a
sentinel, and use a negative byte length in the command string) is sort
of ok, but but I'd advocate taking it one step further.  The thing I'd
worry about is old programs (or new programs using startup code that's
not quite 'right' etc) getting their caller's args, if they were spawned
with Pexec(0, foo, bar, 0). 
 
I propose the following extension to your scheme:  When Pexec'ing, and
there's no environment passed to Pexec, instead of simply cloning the
current env, clone selectively, ie copy only up til the magic sentinel.
Do everything else the same, and I think you get all the same benefits,
with less risk of confusing programs that, for whatever reason, aren't
adhering to your new protocol.  You also don't even NEED to assign
meanings for oddball values of the command line length byte if you do
that.
 
Part of why I suggest this scheme is that I just re-wrote the system()
function for the GNU C lib to do just what I described.
 
 
David Parsons writes:
--------------------- 
  What if the program uses the length byte to figure out length of command
  line tail like so:

    for (length = *(tail)++; length-- > && ....

  ????

  It would be nice to be able to have the extended arguments code also
  be able to handle talking to processes that don't grok extended arguments
  and which don't clear sign-extension on the length byte (which is not
  an unreasonable thing to ignore, because the tail can't be >127 chars.)
 
 [...] at least xArgs doesn't carry the argument list to all the
 descendants of the process, which is what the Mark Williams `standard'
 does.  [...] The big problem with this is that you will get those
 strings propagated all over the universe, anyway, and if a process
 modifies the environment with putenv(), the ARGV= stuff will be
 scrambled around. 
 
 [and he proceeds to describe just how ugly the argument propagation gets]
 
 If you're planning to do enhancements to TOS for extended argument passing,
 perhaps it's time to consider the basepage & additional gemdos traps for
 extended argument pexecing?
 
 
Pekka Sarnila writes:
--------------------- 
 if length is say FF the last long (after null) would contain
the pointer to unix like parameter structure. In that case
Pexec would count the length of that structure and allocate
that much more space and copy (and reloc pointers) it to the
new processes memory area.
 
================================================================
 
  The transition period is going to be ugly.  No two ways about it.  No
matter what new standard we adopt, we're going to break some software. 
If the new scheme is sufficiently different from the old ones, however,
software which uses an older method will continue to work with other
software which agrees with that old method. 
 
  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. 
 
  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.
 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.
 It's just going to have to be the responsibility of library startup
code to comply with the new standard.  Period.
 
  Using the basepage, or additional GEMDOS traps, won't fly either, for
the reasons stated above. 
 
  Finally, let's consider the sticky problem of environment-based
argument strings being propagated all over creation.  There are two
things that GEMDOS copies from a parent when it creates a process.  The
basepage (process descriptor) information, and the environment.  GEMDOS
allocates memory for these, then fills them in.  It would be nice if it
allocated an argv[] area as well, but it doesn't.  The only clean way
that I see to get around that problem is to put the extra args in the
environment.  This causes problems if the args take the form of a
standard argv[] array.
  BUT...
  If the extended argument string is not itself a series of null
terminated strings, the problem solves itself neatly.  getenv() and
putenv() will not confuse the environment, and can in fact be easily
used to pass a lot of args to a child.  The environment arguments should
consist of a regular command-tail style string, with arguments separated
by white space.  That way, arguments can even contain `='!
 
  So... here's GEMDOS Extended Argument Standard proposal #2:
---------------------------------------------------------------- 
  If a program wants to pass more than 125 bytes of arguments to a
child, it should create a command tail of (at most) the first 125 bytes
of the "real" arguments, and give it a length byte of 126.  This will
satisfy children which don't understand the extended argument standard. 
The program should also place an environment variable called ARGS in the
environment it intends to pass to the child (its own, or a specially
created environment, per the Pexec spec).  The ARGS variable should
consist of the name of the child (argv[0]) followed by a space, followed
by the rest of the arguments (argv[1..n]), separated by spaces. 
  The startup code of ARGS-aware programs is responsible for checking
the command line for the magic length byte, then searching the
environment for the ARGS environment variable command line.  It must
copy the ARGS command line somewhere so that it can be parsed into an
argv[] string.  IT MUST NOT BE PARSED IN PLACE, OR THE ENVIRONMENT WILL
BE CORRUPTED.  The startup code can then set the argument count and
argv[] array pointers, and do whatever else it needs to do before
starting up the mainline code. 
---------------------------------------------------------------- 
 
  Hopefully, some time this week, I will be able to get in touch with
most of the compiler vendors to discuss this plan with them.  In the
mean time, please keep the e-mail coming!

-- 
 Ken Badertscher                 | #include <disclaimer>
 Atari R&D                       | No pith, just a path:
 Software Engine                 |   {portal,ames,imagen}!atari!kbad