From: steve@thelake.mn.org (Steve Yelvington)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: help with sozobon getenv()
Date: 10 Apr 92 18:14:56 GMT

[In article <18420017@hpsad.HP.COM>,
     randyh@hpsad.HP.COM (Randy Hosler) writes ... ]

 >    I have the source for the MiNT library but have not had the time, nor
 >    the know-how to build it.  It would be nice if someone could upload
 >    a heat-n-serve MiNT lib for sozobon.  

It's not hard to make one. You need the current collections of source
code and include-files from atari.archive.umich.edu. There is a makefile
in there that works with Heat and Serve's MAKE. 

Be sure that you have the LIB and INCLUDE environment variables set
to point at the directories in which you have stored the MiNT stuff,
not the Sozobon stuff.

I ran across two fairly minor problems:

  -- in termcap.c, tgetent is declared as returning a char*, but it
     really returns and int and it's declared as such in termcap.h.
     The compiler notices the inconsistency and chokes. Fix the source
     code.

  -- doprnt.c simply overwhelms TOP, the optimizer. Just compile this
     module separately before running MAKE. Use the command cc -c doprnt.c.

Then run MAKE and go eat a sandwich or something, because it'll take
awhile.

You'll wind up with a libc.a and a crt0.o that can replace dlibs.a and
dstart.o.

 >    On another point...
 >    Why doesn't sozobon put the name of the program in argv[0]?  Everytime
 >    I try to reference argv[0] all I get is "".  

This is interesting; I hadn't noticed it, and I don't know what Ian
has done to the argument-parsing code, since I don't have sources.

I'll record this as an apparent bug, with reservations (see below).

It does not appear when I run a test program from a shell, but it
shows up from the Desktop. Programs compiled with other versions of
dLibs (available from a.a) can find argv[0] under both circumstances.

The whole issue of args is a can of worms, but since you've opened
it, let's drag a couple out and examine them.

There are several ``standards'' for passing arguments under GEMDOS.
The most basic is the GEMDOS Pexec function, but it is deficient in
two ways: it provides only a short ``command tail'' and does not tell
the child program its own name.

Various solutions to these problems have been implemented by C
compiler writers. Most involve tinkering with the environment,
mucking around in address space that doesn't belong to the program,
or both.

dLibs argument-processing code implements one such solution, called
XARGS. If you run your program from a shell that supports that
standard, then you'll have something sensible in argv[0]. 

The original dLibs code tried to use XARGS first, and if that failed,
it retrieved argv[0] by using some black magic. The Heat and Serve
package apparently has abandoned that attempt, and I suspect one of
my own bug reports may have prompted that change. The black magic
method was known to occasionally produce problems with Micro RTX and
older versions of MiNT, and that's why I took note of your report as
a bug ``with reservations.'' 

Atari Corp. officially endorses a newer standard for passing extended
arguments, called ARGV. The MiNT library supports ARGV. If you
compile your program with the MiNT library AND execute it from a
shell or other program that supports ARGV, then you'll get something
sensible in argv[0].

Unfortunately, Atari does not support ARGV in its own Desktop, at
least not in versions up to TOS 1.4.  Since the GEM Desktop does not
provide a mechanism for creating long command tails, it might seem at
first glance that ARGV isn't important, but ARGV also provides a
dependable method of obtaining argv[0]. A program compiled with the
MiNT library, using Atari's officially supported protocol, still
can't find its own name when run from the Desktop.

I don't know whether this is still true with the Mega STE's and TT's
NewDesk. Maybe someone who's used them can comment.

If you're interested in the innards of the ARGV specification, send
me a note and I'll mail you a text file explaining it in detail.

 ---
 Steve Yelvington              Marine on St. Croix, Minnesota, USA 
 steve@thelake.mn.org          umn-cs!thelake!steve