Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!imagen!atari!kbad From: kbad@atari.UUCP (Ken Badertscher) Newsgroups: comp.sys.atari.st Subject: Re: GEMDOS Extended Argument Standard Summary: Round 2: a better proposal? Keywords: dlibs, xargs, argv, gemdos, argument passing Message-ID: <1424@atari.UUCP> Date: 2 Apr 89 14:46:44 GMT References: <1405@atari.UUCP> Reply-To: kbad@atari.UUCP (Ken Badertscher) Organization: Atari Corp., Sunnyvale, CA Lines: 154 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 Atari R&D | No pith, just a path: Software Engine | {portal,ames,imagen}!atari!kbad