🚀 go-pugleaf

Most of my comments have been sent directly to Atari, but just to make
my position known to the rest of the world, I'll make a brief statement.

I think it's great that Atari wants to get involved.

I agree with most of the problems stated by others regarding both the
MWC ARGV= format and the new format lightly proposed by Atari.

I think the best thing I've heard is the idea of GEMDOS Pexec enhancements
as opposed to some more convoluted environment hacking.   This could be
done with complete downward compatibility.   The details must be worked
out very carefully.   One rough idea I have is along the lines of a new
Pexec option [e.g. Pexec(10, ...)] or possibly, as proposed by others, a
special interpretation of the tail Pexec argument (I think this is a little
more dangerous, personally).   I propose a new GEMDOS trap function code
which requests the extended arguments.  This way new programs must explicitly
ask for the extended arguments, so there will be no confusion about whether
the program knows what it's doing or not.   I prefer this to a new definition
of the basepage header; let GEMDOS decide where to keep the new arguments.
This has the most chance for downward compatibility and also it will be easier
to support in the future becuase it is all handled internally to GEMDOS,
anyway it wants (no future worries about protected memory and children
accessing the parents memory space).

Programs that don't know anything about the new GEMDOS extendend arguments
will not be affectted directly.   If they want to pass around ARGV= or
Xarg formats, fine.  If they don't, the children will just look for the
"old-style" command tail, which will contain valid info.  Programs that
don't understand the new GEMDOS standard will not get extended arguments
from shells that don't use any of the "old" formats but they will at least
run. They can be updated as needed and perhaps special utilitiies provided
with new shells will allow passing arguments in some "old" style.

Whatever is finally "officially" decided, you can be sure that new versions
of MT C-Shell and other BDT programs will support it.
-- 
David Beckemeyer (david@bdt.UUCP)	| "Adios amigos.  And, as they say when 
Beckemeyer Development Tools		| the boys are scratching the bad ones,
478 Santa Clara Ave. Oakland, CA 94610	| 'Stay a long time, Cowboy!'"
UUCP: {uunet,ucbvax}!unisoft!bdt!david	|                  - Jo Mora