[comp.sys.atari.st] Sozobon C in MT C-Shell

jlf@a.cs.wvu.wvnet.edu (Jack L Forester) (08/31/89)

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].

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.

I hope this helps.

Jack Forester, Jr.
jlf@a.cs.wvu.wvnet.edu

david@bdt.UUCP (David Beckemeyer) (09/02/89)

In article <428@h.cs.wvu.wvnet.edu> jlf@a.cs.wvu.wvnet.edu (Jack L Forester) writes:
[ description of problem with dlibs/MT C shel causing Sozobon C to bus err
  deleted ]
>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.
>

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"!

Jack if you have version 1.0 of MT C-Shell, you are due for an upgrade.
That version is *very* old and the newer versions are *much* *much* improved.
The current version of MT C-Shell is 1.20.

If you don't know what the MWC ARGV format is, let me know and I can
give you the info.   I'm not posting it here now because it's been 
gone over many times before.   There is a file on the BDT BBS called
NEWENV.ARC in the MT file area (BBS number 415-452-4792).

>I hope this helps.
>
>Jack Forester, Jr.
>jlf@a.cs.wvu.wvnet.edu

I hope this also helps.
-- 
David Beckemeyer (david@bdt.UUCP)	| "I'll forgive you Dad...  If you have
Beckemeyer Development Tools		| a breath mint."
478 Santa Clara Ave. Oakland, CA 94610	|    Bart - "The Simpsons"
UUCP: {uunet,ucbvax}!unisoft!bdt!david	|

jlf@a.cs.wvu.wvnet.edu (Jack L Forester) (09/02/89)

I'm really sorry about posting this here, but I am still relatively new
to UNIX and the net and I couldn't figure out how to send this through
mail.

If 1.20 is the current version, then I *definitely* need an upgrade.
My version is 1.00.  About a year and a half ago I received some information
about upgrades and new products, but I couldn't afford it then.  I am a
registered owner of the product - my disks have the number 12227 - so if you
could send me some information about upgrades and other products, I would
really appreciate it (EMAIL or otherwise).

Your records may have my address as

Jack Forester, Jr.
439 Rebecca Ave
Wilkinsburg, PA 15221

this address is no longer correct.  My new address is

Jack Forester, Jr.
PO Box 169
Paden City, WV  26159

I would call your BBS, but I am a college student who can't really afford
the long distance call from WV to CA.  I check the net every day, so email
would be the best way to get information to me.

Up until now, I have never talked to the developer of any software I have
ever owned.  It's great being able to get information "direct from the
horse's mouth!"  Many thanks in advance for whatever you can do.

Jack Forester, Jr.
jlf@a.cs.wvu.wvnet.edu

dal@syntel.UUCP (Dale Schumacher) (09/05/89)

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