Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!ctrsol!srcsip!tcnet!pwcs!stag!daemon
From: dal@syntel.UUCP (Dale Schumacher)
Newsgroups: comp.sys.atari.st
Subject: Re: Sozobon C in MT C-Shell
Message-ID: <1989Sep4.202911.7766@stag.UUCP>
Date: 4 Sep 89 20:29:11 GMT
Sender: daemon@stag.UUCP (The devil himself)
Organization: Mindtools ST Access Group
Lines: 87

Hey Ken <kbad@atari>, when are we going to see this promised extended
argument passing standard.  All the submissions have certainly been in
for quite some time now and we're waiting for the "official" decision.

[jlf@a.cs.wvu.wvnet.edu (Jack L Forester) writes...]
> Recently I was having problems using Sozobon C with Beckemeyer's MT C-shell.
> The information I am going to present here should help anyone with similar
> problems correct them.
> 
> The problem:  Running the Sozobon programs caused a bus error.
> 
> Background:  The Initargs function in dLibs is called very early in the
>   execution of the program to set up the values passed to main().  This 
>   function works fine when programs are run from the desktop, but causes the
>   bus error when run from MT C-shell.  Specifically, the bus error occurs
>   when Initargs tries to get a pointer to the program name for argv[0].

Ahh... someone who "used the source, Luke".  The above explaination is
correct.  I've run into this kind of problem myself.  The relevent code
fragment from the _initargs() function is the following:

1	if((_argv[0] == NULL) || (_argv[0][0] == '\0'))
2		{
3		/*
4		 * argv[0] not set, extract value from parent's dta
5		 */
6		p = (char *) _base->p_parent;	/* get parent's basepage */
7		if(p == NULL)
8			_argv[0] = "";		/* for sid... */
9		else
10			{
11			p = *(char **)(p+0x7C);	/* get parent's saved usp */
12			p = *(char **)(p+0x36);	/* get Pexec'd filename */
13			_argv[0] = _sbrk(strlen(p) + 1);
14			strcpy(_argv[0], p);	/* copy filename */
15			}
16		}

The idea here is, if by this point in the processing (after checking for
xArgs or parsing the command line image), we still don't know the name
of the program, we look into the basepage of our parent process for the
filename which was passed to the Pexec() GEMDOS call.  This apparently
doesn't work with RTX (the basis for MT C-shell) probably due to it taking
over the Pexec() vector (among others) such that the information I'm looking
for is no longer there.  The debugger, SID, has a similar problem in that
when it executes the program to be debugged, it sets the parent pointer
to NULL.  This is checked for specifically in line 7 above.  There should
probably be similar checks after lines 11 and 12.  I suspect that the
bus error is coming from blindly following one of the pointers in lines
12 and 13.

> The fix:  In the environment variables passed to the program, there are two
>   of concern here:  ARGC and ARGV.  The ARGC variable will always contain the
>   number of arguments passed to the program, and ARGV contains the starting
>   address of an array of pointers to the arguments.  You will have to replace
>   the Initargs function in dLibs with one of your own that searches the
>   environment for these two variables and puts their values into _argc and
>   _argv.

[david@bdt.UUCP (David Beckemeyer) writes...]
| Be careful!   This is the old way that MT C-Shell used to pass arguments.
| This was changed in version 1.10 and later to use the MWC ARGV envioronment
| format "standard"!

I would suggest changing _initargs() as described above to check for bad
pointers.  You won't be able to get the program name in argv[0], but then
most programs don't count on that anyway.  Another alternative would be
to add support for the MWC ARGV argument passing standard to _initargs().
If you do, I would hope you'd leave in support for xArgs as there are
many programs (Sozobon tools as well as lots of European stuff, I've heard)
which use xArgs.

This is why I started my message with a plea to Ken to make some kind of
official statement about argument passing standards.  There are a few
mostly incompatible methods in use today, and though one could write a
startup module which understood all of them (or all the major ones),
that would be a lot of baggage to carry around when you shouldn't need it.
WE NEED A FINAL OFFICIAL WORD FROM ATARI TO SET THE RECORD STRAIGHT.

PS. dLibs v2.0 is in the works and will use xArgs unless there is an
    official standard by the time it's ready to release.

\\   /  Dale Schumacher                         399 Beacon Ave.
 \\ /   (alias: Dalnefre')                      St. Paul, MN  55104-3527
  ><    ...umn-cs!midgard.mn.org!syntel!dal     United States of America
 / \\   "What is wanted is not the will to believe, but the will to find out,
/   \\  which is the exact opposite." -Bertrand Russell