Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!decwrl!cgfsv1.dec.com!drew
From: drew@cgfsv1.dec.com (Steve Drew)
Newsgroups: net.micro.amiga
Subject: Re: Bug in manx fexec functions?
Message-ID: <5521@decwrl.DEC.COM>
Date: Wed, 24-Sep-86 18:30:28 EDT
Article-I.D.: decwrl.5521
Posted: Wed Sep 24 18:30:28 1986
Date-Received: Thu, 25-Sep-86 07:24:57 EDT
Sender: daemon@decwrl.DEC.COM
Organization: Digital Equipment Corporation
Lines: 78


In reply to Graeme Clark -- Dept. of Computer Science, Univ. of Toronto.

>  Has anyone successfully used the functions fexecl() and fexecv()
>  in the Manx (3.20a) library?  When I use them, fexecl() gurus whenever
>  I call it, and fexecv() does so occasionally.  Is it me?

I have successfully used the fexecv function (alot) and so far no problems.
I have only used it with 32 bit int's but that should'nt matter.

Make sure you call it somewhat like this:

	char array *[3];
	int retcode, success; 	
	:
	:		/* array gets set up    */
	:		/*  by program          */
	:		/* say array now has    */
	:		/* eg. array[0] = DIR   */
			/*     array[1] = DF0:  */
			/*     array[2] = '\0'; */

	success = fexecv(array[0], &array[0]);
	if (success = 0) retcode = wait();

			/* note that array[0] contains the command
			   that gets past as the *name of the program
			   to load and also as argv[0]. */


>  Can anyone tell me the sequence of operations performed by these
>  functions so I can write my own version?  It's not sufficient to
>  just call Execute(); fexec[l|v] allows the child program to be interrupted
>  with ^C and to inherit the parent's Input() and Output() file handles.
 
Basically looking at the sources this is what it does:

	1. Finds our task.
	2. sets up a pointer to our cli structure to get a pointer to
	   cli_Module. It saves the pointer to the current cli_Module.
	3. Does a LoadSeg(name) from array[0] above. 
	4. if that fails it does a LoadSeg of c: + name.
	5. once Loaded it puts the pointer returned by LoadSeg into
	   cli_Module.
	6. It then looks like it AllocMem's a stack and sets up a pointer
	   for the return addr.
	7. Then is copys the entire array passed into a string of
	   Alloc'd memory and saves a pointer to it.
	8. It finds the current input stream file handle from our
	   process structure (pr_CIS) and copy's into the file buffer
	   the command line that it formed and Alloc'd in step 7.
	9. This is were I get left behind since It calls a 20 line
	   assembly routine that gets passed the pointer to the arg
	   line the length of arg, pointer << 2 that was returned by
   	   LoadSeg and the stack we alloc'd. The asm routine saves
  	   the regs', sp, and jsr's to the new code and then cleans up.
 	 
	That's about the best I can do. Hope it helps.

On another note. This function is great for things line Matt's Shell 
since it does allow for ^C capability on external commands.
I spent quite a number of hours converting matt's shell to run on Manx.
Rewrote run.c to use fexecv  and poked my task's CIS/COS file ptr's to 
allow for redirection on external command's as well. I also changed all
the i/o commands to use stdio commands or manx equivalent, added a few
more command (date/time on directorys, optional breif/full directory's,
copy command[with minimal head seek's]), boy it's nice to be able to
do a 'copy df1:*.c ram:' instead of all that p=#?|#? stuff.
And it does'nt need MY.LIB. , and is still only 28,000 bytes small.

Don't worry Matt your name is still all over my hacked up version,
and thanx for a super program.
		
	Steve Drew.

    			ENET:    CGFSV1::DREW
    			ARPA:    drew%cfgsv1.dec.com@decwrl.dec.com
    			USENET:  {decvax!decwrl}!cgfsv1.dec.com!drew