Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!uwmacc!uwvax!umn-d-ub!umn-cs!ems!nis!stag!trb
From: trb@stag.UUCP ( Todd Burkey )
Newsgroups: comp.sys.atari.st
Subject: A proposal for extended ARG passing
Message-ID: <242@stag.UUCP>
Date: Wed, 14-Oct-87 21:41:06 EDT
Article-I.D.: stag.242
Posted: Wed Oct 14 21:41:06 1987
Date-Received: Sun, 18-Oct-87 09:38:16 EDT
Organization: Mindtools ST Access Group, Plymouth, MN
Lines: 70
Keywords: C ARGs


 remote from syntel
Date: Tue, 13 Oct 87 02:00:10 CDT
To: trb
From: syntel!dal@stag.UUCP (Dale Schumacher)
Subject: Extended Argument Passing Proposal
Message-Id: <1013870200100132@syntel.UUCP>

			-------------------------------

		A PROPOSAL FOR EXTENDED ARGUMENT PASSING IN C.
		  by David (orc) Parsons and Dale Schumacher

			-------------------------------

    Why change argc/argv in the first place?  Well, there are times where
(a) it would be nice to have more than 128 bytes of commandline, (b) it
would be nice to pass arguments to a child process without having the
startup code in the child process retokenize (spaces inside of an argument,
tokens containing `>', `<', `*', and `?', etc.) and (c) it's nice to have
a more Un*x-like interface for argc/argv.

    The method employed by Mark Williams involves making a mess of the
already confused environment string.  We would like to suggest a cleaner
way of handling extended arguments.  Of course, the normal command line
image will have to be supported for programs which don't understand the
extended format, and the extended format must be validated in some way,
but these are fairly trivial problems.

    What we'd like to do is this.  Take an unused/reserved location in the
process basepage (aka TPA), perhaps the "reserved" pointer field located
at offset 0x28, as a pointer to an argument structure (Any problems with
using this location, Atari?  More information about what's really in the
rest of the basepage would be very helpful).  The structure would be:

	struct {
		char	xarg_magic[4];		/* verification value */
		int	xargc;			/* argc */
		char	**xargv;		/* argv */
		char	*xiovector;		/* i/o stream status */
	}

    The <xarg_magic> value in some preset constant like "xArg", and serves
to validate the extended argument format.  <xargc> holds the normal <argc>
value.  <xargv> is a pointer into the parent's dataspace where the list of
<argv> argument pointers is stored.  Obviously, the <argv> values would also
reside in the parent, and should be copied by the child process as part of
the startup procedure.  <xiovector> is either NULL, indicating that this
feature is not supported, or points to a '\0' terminated string which
describes the state of the i/o streams.  Only the characters [CAPF?] are
valid in the <xiovector> string.  These represent <C>onsole, <A>ux port,
<P>rinter, <F>ile and <?>unknown.  This feature is present mostly to
allow operation similiar Mark Williams, if desired.

    To support this convention, a custom set of exec()-like functions
are created.  They basically create both the command line image and the
extended parameter structure, then "load no go" the process, modify the
basepage accordingly and then "just go" to execute the process.  The next
version of the dLibs public domain C libraries (and also the next release
of the STadel BBS) are planned to support this extended argument format.
If there is interest, the sources for these routines could be posted to
this newsgroup.

    Please direct all flames (or even nice comments) to:
	..ihnp4!meccts!stag!syntel!dal	-or-  syntel!dal@stag.UUCP
	..ihnp4!meccts!stag!pell!orc	-or-  pell!orc@stag.UUCP

                Dale Schumacher
                ..ihnp4!meccts!stag!syntel!dal
                (alias: Dalnefre')