to_stdnet@stag.UUCP (03/10/89)
From: thelake!steve@stag.UUCP (Steve Yelvington) John Clark writes... > I have had your MT C-shell as well as the Micro C-shell for sometime > now. I have recently downloaded the Sozobon C stuff. The *.TTP > programs work under the Micro C-shell but not under MT C-shell. > Atfer some investigation it appears that the Sozobon startup uses > some interresting methods to find the name of the program that was > 'pexec-ed'. I would like to know if this code uses standard things > 'everyone knows' in the atari world or do I have an old version of > MT C-Shell or this is what I get for using 'free' stuff. > > Thank You > John Clark > Internet: pa2183@sdcc15.ucsd.edu The argv[0] work is done by dLibs, not by Sozobon's compiler. They are not standard things that everybody knows; Dale Schumacher and John Stanley had to do some detective work to get the argv[0] information correctly filled out. Mark Williams C apparently leaves argv[0] empty; some other compilers on the ST fill in a bogus word such as ya.out. Try: #include <stdio.h> main(argc, argv) int argc; char **argv; { printf("argv[0] = %s\n", argv[0]); } ... and you'll get some interesting answers, depending on who wrote your C libraries. If you use dLibs, you get the real current name of the program, including the path (c:\cstuff\argv.tos, for example). Problems with MT C-Shell are not peculiar to Sozobon C and/or dLibs; Mark Williams provides a conversion program to get MWC-compiled software running under the Beckemeyer product. /* * UUCP: {uunet!rosevax,amdahl!bungia,chinet,killer}!orbit!thelake!steve * ARPA: crash!orbit!thelake!steve@nosc.mil * #member <STdNET> The ST Developers Network */ From MAILER-DAEMON Thu Mar 9 14:16:50 1989 remote from stag Received: by stag.UUCP (5.9/smail2.5/03-21-87) id AB17658; Thu, 9 Mar 89 14:10:15 CST Date: Thu Mar 9 13:25:56 1989 CST From: MAILER-DAEMON@stag.UUCP (Mail Delivery Subsystem) Subject: Returned mail: User unknown Message-Id: <8903092010.AB17658@stag.UUCP> To: thelake!steve ----- Transcript of session follows ----- 550 atari.st... User unknown ----- Unsent message follows ----- Received: by stag.UUCP (5.9/smail2.5/03-21-87) id AA17658; Thu, 9 Mar 89 14:10:15 CST Path: thelake!steve Date: Thu Mar 9 13:25:56 1989 CST To: atari.st@stag From: thelake!steve@stag.UUCP (Steve Yelvington) Message-Id: <0209891325560632@thelake.UUCP> Reply-To: thelake!steve@stag.UUCP X-Member-Of: STdNet, the ST Developers' Network Organization: Otter Lake Leisure Society > I have had your MT C-shell as well as the Micro C-shell for sometime > now. I have recently downloaded the Sozobon C stuff. The *.TTP > programs work under the Micro C-shell but not under MT C-shell. > Atfer some investigation it appears that the Sozobon startup uses > some interresting methods to find the name of the program that was > 'pexec-ed'. I would like to know if this code uses standard things > 'everyone knows' in the atari world or do I have an old version of > MT C-Shell or this is what I get for using 'free' stuff. > > Thank You > John Clark > Internet: pa2183@sdcc15.ucsd.edu The argv[0] work is done by dLibs, not by Sozobon's compiler. They are not standard things that everybody knows; Dale Schumacher and John Stanley had to do some detective work to get the argv[0] information correctly filled out. Mark Williams C apparently leaves argv[0] empty; some other compilers on the ST fill in a bogus word such as ya.out. Try: #include <stdio.h> main(argc, argv) int argc; char **argv; { printf("argv[0] = %s\n", argv[0]); } ... and you'll get some interesting answers, depending on who wrote your C libraries. If you use dLibs, you get the real current name of the program, including the path (c:\cstuff\argv.tos, for example). David Brooks suggests that you may have been bitten by a bug in memcpy(). His replacement for the function appears in the next message. By the way, problems with MT C-Shell are not peculiar to Sozobon C and/or dLibs; Mark Williams provides a conversion program to get MWC-compiled software running under the Beckemeyer product. /* * UUCP: {uunet!rosevax,amdahl!bungia,chinet,killer}!orbit!thelake!steve * ARPA: crash!orbit!thelake!steve@nosc.mil * #member <STdNET> The ST Developers Network */
david@bdt.UUCP (David Beckemeyer) (03/16/89)
I've seen enough un-truths about this subject already so here is
the story behind argv[0] and MT C-Shell.
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.
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. 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.
The "conversion" programs that are often talked about only apply
to *very* old versions of MT C-Shell and Micro C-Shell (prior to
V1.10 MT and V2.70 Micro C-Shell, or about Fall 1986). Probably
nobody needs these conversion programs anymore; they cloud the
issue.
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.
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.
I do not know if Sozobon C is compatible with this method or not.
--
David Beckemeyer (david@bdt.UUCP) | "Lester Moore - Four slugs from a .44
Beckemeyer Development Tools | no Les, no more."
478 Santa Clara Ave. Oakland, CA 94610 | - Headstone at Boot Hill
UUCP: {uunet,ucbvax}!unisoft!bdt!david | Tombstone, AZto_stdnet@stag.UUCP (03/19/89)
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; | | <xarg_magic> value is the constant "xArg" ($78417267), and serves to | validate the extended argument format. | <xargc> holds the normal <argc> value. | <xargv> is a pointer into the parent's data space where the list of | argv[] argument pointers is stored. Even though <argc> is available, | argv[argc] should be set to NULL to tie off the argument list. Obviously, | the <argv> values would also reside in the parent's data space, and should | be copied by the child process as part of the startup procedure. | <xiovector> points to a '\0' terminated string which describes the | state of the i/o handles. 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 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. | <xparent> points to the basepage of the process which set up this | XARG structure. If this value is not the same as the <p_parent> 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"
david@bdt.UUCP (David Beckemeyer) (03/22/89)
In article <748@stag.UUCP> to_stdnet@stag.UUCP writes: >From: dal@syntel.UUCP (Dale Schumacher) >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... > I still hold to my original article. All the things Dale talks about happended *after* the history I spelled out. I received my first copy of MWC in the Fall of 1986, prior to the 1986 Comdex. The only other compilers available at that time were Alcyon and Megamax. I was working with people from Manx (Aztec C) and I had a Beta release of that compiler *at that time* in the fall of 1986. Dale shows an article by Allan Pratt where Allan points out some problems with the MWC method; here's the header to that message: >| 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 This is long *after* version 1.10 of MT C-Shell and Version 2.70 of Micro C-Shell were released, nearly a year after the MWC ARGV format had been chosen. Again I repeat that I chose the MWC ARGV method for the following reasons: 1) Alcyon didn't have any method for argv[0] or > 128 bytes 2) ditto for Megamax 3) Mark Williams C existed and had an extended format. 4) Manx agreed to support the MWC method 5) Atari didn't say anything (yet) Hence the MWC method was adopted in late 1986/early 1987. >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! As I stated above, the MWC method was adopted well before 1988 and Atari didn't make a fuss about it until it had been in use for at least one year. I agree with the complaints about it, but it's all there was at the time. I'm still not *changing* it until *everyone* agrees on something becuase what's to say somebody won't change their mind again next week. And I agree that Atari should take a much stronger leadership role on such issues - but it may be a little late for that now. No matter what they decide now, I expect there will still be a lot of programs that "do it their way" and a full conversion could take quite a while, especially since many vendors are no longer supportting their ST products. > >-- > 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" > -- David Beckemeyer (david@bdt.UUCP) | "Lester Moore - Four slugs from a .44 Beckemeyer Development Tools | no Les, no more." 478 Santa Clara Ave. Oakland, CA 94610 | - Headstone at Boot Hill UUCP: {uunet,ucbvax}!unisoft!bdt!david | Tombstone, AZ