Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!amdcad!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Another proposal for passing argv[]
Message-ID: <811@atari.UUCP>
Date: Tue, 11-Aug-87 17:22:54 EDT
Article-I.D.: atari.811
Posted: Tue Aug 11 17:22:54 1987
Date-Received: Fri, 14-Aug-87 01:32:06 EDT
References: <4659@felix.UUCP>
Distribution: world
Organization: Atari Corp., Sunnyvale CA
Lines: 66

in article <4659@felix.UUCP>, preston@felix.UUCP (Preston Bannister) says:
> 	<sequence of normal null-terminated strings>
> 	\0				; two nulls end the environment
> 	\1				; indicates argv argument
> 	\0				;   list follows...
> 	CCCPA???????????????\0	; exact sequence of C|P|A|F|? varies
> 	<arg[0] string>\0
> 	<arg[1] string>\0
> 	  :        :
> 	<arg[argc-1] string>\0
> 	\0				; two nulls end argument list
> 
> Programs that were oblivious to the extended argument passing scheme 
> would stop copying the environment list when the first two consecutive
> nulls were found.  The extended argument list would not be copied.
> 

THIS DOESN'T WORK.

You pass a pointer to an environment string to Pexec, and Pexec COPIES
this environment into a Malloc'ed region.  Then Pexec Malloc's the
TPA, loads the program, and launches it.  Naturally, Pexec detects the
end of the environment from the double-null, and won't copy the
rest as suggested above.

The reason it happens like this is to pave the way for ownership of
memory, or for virtual memory, or something: a given process's
environment is in its own address space, not in its parent's address
space. 

But let's look at the problem in some new terms: what you need to do is
establish that the ARGV string in the environment actually came from
your own parent -- that is, the process which Pexec'ed you.  My proposal
is to add an environment variable PARENTBP (or something) and set that
to the basepage address of the parent.  Then the child can check the
parent-basepage address in its own basepage against this environment
variable, and if they match, the ARGV string is valid.  If they don't
match, the child looks in the command line area for its args. 

To formalize the proposal, I submit that the MWC/Beckmeyer trick of
placing arguments in the environment be amended as follows:

1.  Place an environment variable PARENTBP=xxxxxxxx in the environment,
where xxxxxxxx is the basepage address (in 8 hex digits) of the process
doing the Pexec.

2.  When the runtime startup code builds argv[], it should check the
PARENTBP variable value against the parent pointer in its own basepage.
If they don't match, the 127-byte command-line argument area should be
parsed for arguments.

The advantages of this are twofold: it solves the problem unambiguously
with no change to ROMs, and it is tolerant of old shells and old
programs.  New programs started from an old shell will not find PARENTBP,
and will blindly assume that the ARGV string is for them (as they do now),
and old programs started from new shells will not check for PARENTBP,
with the same result.

How about it, gang? Are the shell-writers out there interested in
adopting this standard?  If you can poke any holes in it, please do
so and we'll try to get it right.

/----------------------------------------------\
| Opinions expressed above do not necessarily  |  -- Allan Pratt, Atari Corp.
| reflect those of Atari Corp. or anyone else. |     ...lll-lcc!atari!apratt
\----------------------------------------------/	(APRATT on GEnie)