Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!uunet!portal!atari!kbad
From: kbad@atari.UUCP (Ken Badertscher)
Newsgroups: comp.sys.atari.st
Subject: GEMDOS Extended Argument Standard
Keywords: dlibs, xargs, argv, gemdos, argument passing
Message-ID: <1405@atari.UUCP>
Date: 26 Mar 89 23:14:07 GMT
Organization: Atari Corp., Sunnyvale, CA
Lines: 92


Please excuse the length of this message (nearly a hundred lines -
sheesh!) but I consider Atari's role in setting software standards
fairly important...
 
  Since I'm taking over the mantle (or is it a yoke? <yuk yuk>) of
maintaining GEMDOS, I will be intimately involved in the pending
(admittedly belated) adoption of a standard for extended argument
passing in TOS.  It is a major concern of mine, for a couple of
reasons:
  - Two (or more) de facto standards exist
  - The proponents of these standards seem to have some emotional
	involvement in whose standard is best:
	"Since they (MWC) are bigger than I am..." Mr. Beckemeyer ;-)
	"Oh, I wish I had known about this conclave!" Mr. Schumacher ;-)
	"<expletive deleted>!" David Parsons ;-) ;-)
  - GEMDOS enhancements are coming that will require a robust means of
	passing lots of information between parent and child processes
 
  In fact, we have discussed this recently at Atari.  It came up because
of a bug in Gulam, which does something strange with the command line
length byte.  The MWC extended argument scheme not only puts extended
arguments in the ARGV environment variable; it also puts a length byte
of 127 into the command line.  Normally, this is no big deal, because a
command line string is null terminated anyways.  Even if a Pexec caller
passes a command tail that is not null terminated, GEMDOS makes sure
that the trailing null is there in the command line part of the basepage
of any process that it creates.  If, however, a program uses a command
line length byte that is unreasonable (like 127), that program is going
to have problems.  GEMDOS does nothing at all with the length byte
passed in a Pexec command tail except copy it along with the rest of the
command tail into the child's basepage. 
 
  To quote the Pexec Cookbook (yes Virginia, there is a Pexec Cookbook),
the command tail string is a "null-terminated Pascal-style string." 
This means that the maximum theoretical length of a GEMDOS command line
is 126 bytes (128 bytes in the basepage minus length byte minus null
terminator).  In fact, the *actual* maximum length of a GEMDOS command
line is 125 bytes, because that's the maximum number of bytes that
GEMDOS will copy into a command line when it creates a process during
Pexec.  Unfortunately, I didn't get that little tidbit into the Pexec
Cookbook before it went out. 
 
  The upshot of all this is that it is* possible for a process to know
if the ARGV in its environment is meant for it and not left over from
one of its MWC/Manx/MT-C Shell spawned ancestors.  If its command line
length is something unreasonable, a program can take that as a clue that
it should go sniffing around in its environment for more information. 
One can only imagine the multitude of meanings that could be assigned to
bytewise-negative command line lengths... 
 
  HOWEVER...
 
  I still have problems with both ARGV and xArg command line extenders. 
This whole iovector thing bothers me.  David Parsons came up with a
nice, clean isatty() that works just fine without cluttering up ones
environment with ???????'s.  As far as I can see, the iovector is not
necessary, nor does it belong in a scheme for passing arguments.  And as
Dale et. al. said in the xArg proposal, it "makes a mess of the
already confused environment string."  XARG also bothers me, because it
means that a child has to muck with its parent's address space.  Can you
say "virtual nightmare"?  Not only that, but XARG.xparent (pointer to
parent's basepage) is a needless duplication of information that a
process can get from its own basepage (although I guess it could be
useful for an extra level of verification).  And again, needless support
for the iovector string.  And both methods *require* the startup code to
search the environment for extra commands that may not even be there.
 
  Currently, I'm leaning towards the ARGV method with the iovector
yanked, a negative byte value for the command line length to flag it,
and a different name for the environment variable.  This saves
applications from needlessly hunting through their environments (if the
length byte isn't negative), and applications that don't understand the
significance of the negative length byte will get what they can from the
125 bytes that GEMDOS gives them.  Since the dLibs don't use the
iovector anyways, it only entails a small startup code change for them. 
If the name of the environment variable is different, library code which
uses the iovector from ARGV can still do it, but I STRONGLY recommend
that people who are using iovector strings fix their libraries to use a
safer isatty(). 
 
  I am not formulating a standard on a Sunday afternoon, though.
I'll let this percolate through the net for a week or three, and see
what bounces back.  From here and other sources, we'll come up with
something that everyone can at least live with.  And to those of you who
have been bemoaning the lack of "strong Atari involvement" in matters
like this, I have but one thing to say:
	Be careful what you wish for, you just might get it!
-- 
 Ken Badertscher                 | #include <disclaimer>
 Atari R&D Software Engine       | GEMDOS LIVES! ...or is that Frodo?
 {portal,ames,imagen}!atari!kbad | I can never remember these things...