Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!amdahl!meccts!viper!john
From: john@viper.UUCP
Newsgroups: comp.sys.atari.st
Subject: Re: Pexec (the correct format)
Message-ID: <507@viper.UUCP>
Date: Mon, 9-Feb-87 05:46:06 EST
Article-I.D.: viper.507
Posted: Mon Feb  9 05:46:06 1987
Date-Received: Tue, 10-Feb-87 05:26:18 EST
References: <870205190608.886416@DOCKMASTER.ARPA>
Reply-To: john@viper.UUCP (John Stanley)
Organization: Lynx Data Systems, Minneapolis, MN
Lines: 65

Organization:

I am also more than a bit irritated with the current state of technical docs
available (or not-available) for the ST.  The people responsible for marketing
must be living in another universe.  How do they expect people to develop
code for a machine where the only documentation available either costs far
too much or is grossly(!!) inadequate???!  The correct, factual information
for -ALL- the system calls, all known bugs, and all data structures used
should have been made available more than a year ago at a reasonable ( < $35 )
cost in a cleanly written reference manual with a decent index(!!).  Come on
Atari...  This isn't someone asking for a freebe.  I'm just asking Atari to
sell a concise updated(!) reference so I'll have an even chance at
writing the kind of programs that will sell more ST's!
  Please don't get me wrong, I really like the machine and it's capabilities,
but I'm sick and tired of beating my head against the wall trying to get
information about even simple things that don't work as-advertised....  There
is -NO- reason a developer should have to waste literaly days looking thru
hundreds of pages of contradictory information, trying this and that, to
get something to work...!  (Mind you, -most- of the system functions do
exactly what they're suppost to and you don't have to dig to find out what
you need to know about them.  It's that last 5-10% that's causing needless
frustration that's driving programmers crazy...)


----------------------------

The following is the correct (to the best of my knowledge anyway) EXEC call:

In assembly language:
	move.l	#env,-(sp)	* environment string
	move.l	#tag,-(sp)	* command tag
	move.l	#file,-(sp)	* full program name.ext
	move.w	#0,-(sp)	* load and go subfunction
	move.w	#4b,-(sp)	* EXEC (Pexec) function
	trap	#1		* Trap-call GEMDOS to do the work
	add.l	#14,sp		* clean-up stack afterwards


In C:
	Pexec(0,file,tag,env);
    or  gemdos(0x4b,0,file,tag,env);

	char file[] = "EMACS.PRG";
	char tag[] = "\008FILE.TXT";
	char env[] = "\0";	/* yes, the \0 -is- intentional... */
 
  This assumes you have either assembly language access, or access to a C
compiler.  In the instance Bill gave, he's using a language where I'm not
familiar with the constructs used to access GEMDOS calls, but it looks like
the order of parameters as well as the sizes of some of the parameters may
be incorrect.
  The problem most peole have is with the tag parameter.  This is the rest
of the command line after you've subtracted the leading program file name.
The thing not mentioned in 90% of the documentation is that the tag string
is a -PASCAL- style string, not C...!  In the example I've given, you can
see I've added a single byte giving the number of characters to the start
of the string.
  Unless you really need to, ignore the environment (env) string.  There
are currently two distinctly incompatable formats being used for that
string.  As long as you don't need them and you have a double-null
terminated string, it will work with programs written to either standard.
  The file name itself must be the full filename plus extension.  If you
want to run a program from another directory/folder or drive, you have
to include the drive and/or path designation because GEM doesn't support
search PATHs.
 
  Hope this helps, please let me know if you have additional questions...