Path: utzoo!attcan!uunet!lll-winken!xanth!nic.MR.NET!shamash!com50!pwcs!stag!daemon From: to_stdnet@stag.UUCP Newsgroups: comp.sys.atari.st Subject: Re: argv[0] and Sozobon C Message-ID: <748@stag.UUCP> Date: 19 Mar 89 08:14:25 GMT Sender: news@stag.UUCP Lines: 201 From: dal@syntel.UUCP (Dale Schumacher) [david@bdt.UUCP (David Beckemeyer) writes...] > I've seen enough un-truths about this subject already so here is > the story behind argv[0] and MT C-Shell. This is a bit long, but it is an important issue that has lay dormant for quite some time now. David doesn't tell the WHOLE story... > First the history that got us here: Way back in 1986 I developed > and released the first version of MT C-Shell V1.0. This was > before MWC, back when the only C compilers were the DRI/Alcyon > package from Atari and Megamax. neither of these implemented > argv[0] handling at the time (they just full it it with some > static string). > > MT C-Shell needed more than the 128 bytes that Pexec gives you > for arguments, so I invented a method for passing a larger > number of arguments, using the enviroment space. This was > the first method of extended arguement passing and argv[0] > handling. This much is true. > Along comes Mark Williams Co. and MWC. They implement another > (incompatible) method for passing argv[0] and extended arguments > also using the enviroment space. Since they're bigger than I > am (and because they're way was probably better than mine anyway) > I adopt MT C-Shell and all my utilities to be compatible with this > newly established argument passing method. Here a bit of history is left out. When the MWC arg-passing method was explored, it was soundly denounced by Allan Pratt for a number of very good reasons and he proposed an alternative. His alternative had some problems of it's own, so David Parsons and I proposed our own solution. Alas, this also had it's drawbacks. The conversation was then taken to mail to work out a compromise. During the next couple of months a well-designed robust arg-passing method was hammered out, including input from David Beckemeyer. Do you remember this David? It was before you had decided to convert to MWC's format, in fact you where going to use the new compromise, if it gained acceptance. This is the proposal AS POSTED BY ALLAN PRATT. Please note the arguments against the MWC method. | From: apratt@atari.UUCP (Allan Pratt) | Newsgroups: comp.sys.atari.st | Subject: Extended Argument Passing Proposal | Keywords: dlibs, xargs, argument passing | Message-ID: <891@atari.UUCP> | Date: 20 Nov 87 21:59:24 GMT | Reply-To: syntel!dal@stag | Organization: Atari Corp., Sunnyvale CA | | Dale Schumacher et al. have been working on an improved | argument-passing protocol for GEMDOS. This is their manifesto. They | consulted me (and, I confess, bent to my will) about which of many | methods to use. The one below gets the job done cleanly and is easy to | understand and implement. It doesn't do anything with interrupts, and | doesn't use Pexec(load/nogo), because that doesn't work. The only | "rule" this idea breaks is that it has the child reading from the | parent's data space, and on the ST that is no big deal. | | This is an important topic because the Mark Williams trick of passing | ARGV in the environment is incomplete and messy. It is incomplete | because you can't tell if the ARGV came from your parent or from a | higher ancestor with intervening shells that don't know about ARGV. | It is messy because it hauls all the command line arguments around | in the environment, involving lots of copying. | | Here is the proposal. I recommend discussion and eventual adoption of | it. Note that mail should go to ...stag!syntel!dal, not to me. I'm | afraid I don't have time to follow up on this as closely as I might | like. Note that this is not Atari Official anything: I am posting this | because I am interested in developing a better standard, and to lend an | air of importance to the whole affair. | | | | ------------------------------- | | A STANDARD FOR EXTENDED ARGUMENT PASSING IN 'C'. | by | David Parsons | Dale Schumacher | John Stanley | | ------------------------------- | | 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 command-line | arguments, (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, and lacks validation that the ARGV | string did, in fact, come from a process's parent. 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. | | We would prefer the following approach. An environment variable | called "xArg" is placed in the environment. The value of this variable | is 8 hexadecimal digits (0-9 and capital letters A-F). This value | defines the address of the XARG structure in the parent's data space. | The XARG structure is defined as: | | typedef struct | { | char xarg_magic[4]; /* verification value "xArg" */ | int xargc; /* argc */ | char **xargv; /* argv */ | char *xiovector; /* i/o handle status */ | char *xparent; /* pointer to parent's basepage */ | } | XARG; | | value is the constant "xArg" ($78417267), and serves to | validate the extended argument format. | holds the normal value. | is a pointer into the parent's data space where the list of | argv[] argument pointers is stored. Even though is available, | argv[argc] should be set to NULL to tie off the argument list. Obviously, | the values would also reside in the parent's data space, and should | be copied by the child process as part of the startup procedure. | points to a '\0' terminated string which describes the | state of the i/o handles. Only the characters [CAPF?] are valid in the | string. These represent [C]onsole, [A]ux port, [P]rinter, | [F]ile and [?]unknown. This feature is used to allow easy implmentation | of an isatty() function. To support this feature, creat(), open(), close(), | dup() and dup2() [aka: Fdup()/Fforce()] must maintain the values in the | iovector[] string. | points to the basepage of the process which set up this | XARG structure. If this value is not the same as the pointer | in the current (child process) basepage, then the extended arguments are | not for the current process, but were passed along by a shell/program | which was ignorant of this argument passing scheme. This is the method used in dLibs v1.1 and above (from December of 1987) and as you can see, it was PERSONALLY endorsed by Allan, though NOT made an OFFICIAL ATARI STANDARD. > At this time Mark > Williams Co., myself, and representatives from Manx and Megamax > approach Atari with the idea of defining a "standard" method for > extended arguments. Since Atari basically said "we don't care > what you do," we simply agreed that the MWC method would be the > de-facto "standard". MT C-Shell Versions 1.10 and above and > Micro C-Shell Versions 2.70 and above use this MWC "standard" > method of argv[0] and extendend argument passing. Oh, I wish I had known about this conclave! I tried numerous times to reach the appropriate individuals at Mark Williams Co., but always with no success. The dLibs/XARGS code was and is fully public domain, and I wouldn't have the slightest objection to its use by ANY of the other C compiler vendors. [[ stuff above "conversion" progams deleted ]] > > After all this, many new compilers and libraries have arisen for the > ST. It seems that along with them came some more techniques for > argument passing. MT C-Shell does not support any methods other than > that adopted in 1986 (the MWC format). I do *not* have plans to > implement other methods of argument passing, unless one is *finally* > adopted as the "official" standard. As I've already shown, the MT C-Shell adoption of MWC format occured, at the earliest, in early 1988 and the dLibs/XARGS standard has been around for at least that long. It's too bad that ATARI has not taken a firm stand on this issue. I'd like to see them take a stand NOW! Consider the options carefully and MAKE ONE OF THEM STANDARD! > The method used by MT C-Shell and MWC starts with an environment variable > ARGV, whose value is a "iovector" describing the standard handles. > After this the arguments are appended (each null terminated) starting > with argv[0]. The list of arguments is terminated with a empty > string (a double null), which marks the end of the enviromnent. The > basepage "tail" is also filled with the first 127 bytes of the arguments > in standard TOS Pexec format, without argv[0]. The ARGV variable is > placed after the "real" environment variables and is always followed > by the command arguments. One side issue is this "iovector" concept. This is provided to allow the isatty() function to be implemented in MWC, and was allowed-for in XARGS although it is not used by dLibs. There have since been several postings showing how to implement isatty() strictly with legal TOS calls, as dLibs does. > I do not know if Sozobon C is compatible with this method or not. Since Sozobon C is using unmodified dLibs v1.2, all argument processing and passing is done with XARGS. -- Dale Schumacher 399 Beacon Ave. (alias: Dalnefre') St. Paul, MN 55104 ...bungia!cctb!syntel!dal United States of America "I may be competitive, but I'm never ruthless"