From toddpw@cco.caltech.edu Mon Nov 30 02:18:27 1992
Received: from calvin.sfasu.edu by umaxc.weeg.uiowa.edu (5.61.jnf/920629)
	  on Mon, 30 Nov 92 02:18:07 -0600 id AA04531 with SMTP 
Received: from punisher.caltech.edu (punisher.cco.caltech.edu) by calvin.sfasu.EDU with SMTP (5.59/25-eef)
	id AA01038; Mon, 30 Nov 92 02:10:44 CST
Return-Path: <toddpw@cco.caltech.edu>
Received: from sandman.caltech.edu (sandman.cco.caltech.edu) by punisher.caltech.edu 
	(4.1/DEI:4.41) id AA21928; Mon, 30 Nov 92 00:08:30 PST
From: toddpw@cco.caltech.edu (Todd P. Whitesel)
Received: by sandman.caltech.edu 
	(4.1/UGCS:4.41) id AA01708; Mon, 30 Nov 92 00:10:09 PST
Message-Id: <9211300810.AA01708@sandman.caltech.edu>
Subject: Let's break away from BRK.
To: hyperc-l@calvin.sfasu.edu
Date: Mon, 30 Nov 92 0:10:09 PST
X-Mailer: ELM [version 2.3 PL11]
Status: R

Some of you may have wondered what my interest in HyperC is, since I don't
seem to do anything except lurk around and offer sage advice every so often.

I have lots of small, useful thingies written with Orca/C on the IIgs. I would
like to port these with HyperC and make "all Apples" versions of the programs.
However, two things about HyperC have been preventing me from really getting
into this (forgive me if some of this sounds harsh, it's late and I'm tired):

	1. this requirement for the BRK vector to enter the interpreter.
	2. the lack of command line and standard main() argument support.

The first, and worst, is BRK. I do not like the idea of SYS files grabbing
the BRK vector for things that don't really need it. Woz's original Sweet-16
interpreter used a JSR to an entry point to start up the interpreter, and
I think the SYS file incarnation of a HyperC program should use this method
rather than the BRK method -- it always works on any Apple with no special
checks, and does not interfere with legitimate use of the BRK vector. Real
system crashes that BRK should drop you into a real debugger or at least the
monitor, so you know a crash has occurred and the interpreter doesn't spew
meaty chunks all over the place and making things worse, possibly dangerous.

I don't have a problem with the HyperC environment itself using BRK
(especially for backwards compatibility with existing executables!), but
standalone SYS programs really should not be using BRK for purposes other
than debugging support. If necessary, I am willing to help rewrite whatever
is needed to implement this, but it seems to me that it should be pretty
easy for people like Andy who have pretty much rewritten things themselves.

The second thing is command line arguments. Command line arguments are the
easiest way to feed test strings and file names to your program, since no
effort is required on the part of the program. Some effort is required in
the shell, but that's the best place to put it because you can make the
shell's ability to prepare command lines very powerful (like doing automatic
pattern-match-searches for file names) and every program benefits from it.
There is a lot more than that, but the point I'm trying to make is that there
are _good_ reasons why "unix programs are so fixated on the idea of command
line arguments."

The scheme that is used on the IIgs is not ideal (it has to be to avoid being
too language specific) but is very workable: every program is passed a pointer
to a command line buffer, the first eight bytes of which are a unique shell
identifier and the rest of which are a null-terminated string that is the
command line (or processed command line, depending on how smart the shell is).
Programs launched by the system instead of a shell are passed a null pointer
instead.

The C language startup code on the IIgs has to go through and construct the
argv pointer list before calling main(). Under HyperC it would make far more
sense to have the shell put all that at the top of the stack and call main()
using the standard C method, just like every unix shell in existence does.
The SYS file code would do what the IIgs C setup does when there is no shell:
execute code equivalent to
	exit(main(0, NULL, NULL));
Although this is not covered in the C standard, it does distinguish between
running standalone and running from a shell. This could be made more standard,
and environment variables could be used to distinguish between the shell and
prodos, but this would take more work on the part of the code that does SYS
file setup so it may not be worth it. The above technique works quite well;
I've used it before to write programs that run from either environment and
"do the right thing" regardless.

Todd Whitesel
toddpw @ cco.caltech.edu