[net.micro.amiga] Bug in Manx fexec functions?

gclark@utcsri.UUCP (Graeme Clark) (09/23/86)

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?

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.
If I had the commercial version of Manx, I'd just look at the source.
However I don't.  Of course posting the source for fexecv() would 
be a copyright infringement, but I'd think posting a summary of the operations
performed by fexecv() would be OK; after all, you can't copyright algorithms,
right?

Thanks for any help you can provide.

Graeme Clark -- Dept. of Computer Science, Univ. of Toronto, Canada M5S 1A4
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsri!gclark

higgin@cbmvax.cbm.UUCP (Paul Higginbottom) (09/23/86)

In article <3393@utcsri.UUCP> gclark@utcsri.UUCP (Graeme Clark) writes:
>Has anyone successfully used the functions fexecl() and fexecv()
>in the Manx (3.20a) library?

Yes! (I use fexecv())

>When I use them, fexecl() gurus whenever
>I call it, and fexecv() does so occasionally.  Is it me?

Might be, might be not.  I have gone through the fexec() code with a
microscope trying to find out why it blows up SOMETIMES.

Here's what I've come up with.  SOME AmigaDOS commands (TYPE does this FOR
SURE) change the INPUT file handle of the CLI they're attached to.  This
can be disastrous of course.  This caused my no end of grief in a shell
I have written.

Anyway, I have a feeling that these @#$* BCPL programs for the Amiga
do something very weird.  Executing other normal C programs has never
caused me a problem.  3.20a documentation does warn of future
probable incompatibilities with fexec() functions, but in 3.30 (I'm a beta
tester) fexec has been fixed up somewhat, but is still not perfect, although
my guess is still that BCPL programs are the culprit.

>Can anyone tell me the sequence of operations performed by these
>functions so I can write my own version?

If you don't want to see amazing ugliness, don't look at these routines.
I STILL don't understand what a lot of does.

>It's not sufficient to
>just call Execute();

Not to mention that Execute() loses 56 odd bytes on EVERY call!!!!

>...fexec[l|v] allows the child program to be interrupted
>with ^C and to inherit the parent's Input() and Output() file handles.
>If I had the commercial version of Manx, I'd just look at the source.
>However I don't.  Of course posting the source for fexecv() would 
>be a copyright infringement, but I'd think posting a summary of the operations
>performed by fexecv() would be OK; after all, you can't copyright algorithms,
>right?

Sorry, I'm not going to irritate the legal eagles.
>
>Thanks for any help you can provide.
>
>Graeme Clark -- Dept. of Computer Science, Univ. of Toronto, Canada M5S 1A4
>{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsri!gclark

Hope I helped a bit.

	Paul Higginbottom

Disclaimer: I do not work for Commodore or Manx, and my opinions are my own.

drew@cgfsv1.dec.com (Steve Drew) (09/25/86)

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    

streeter@ingr.UUCP (09/26/86)

> Has anyone successfully used the functions fexecl() and fexecv()
> in the Manx (3.20a) library?

I have used fexecv() with no problem. Simple cases, though

> Can anyone tell me the sequence of operations performed by these
> functions so I can write my own version?
> Graeme Clark

Without giving it extensive thought (how's that for a dislaimer?),
it seems to me that you just need to LoadSeg() the image that you
want to run, and then call that image's entry point.  fexecv()
probably stores the returned value (D0?) someplace so wait() can get
it and give it back to you.  This may be a little simplistic, but it
couldn't be all that tricky to do.

Guy Streeter
akgua!ingr!streeter

"It's over now, and I'm a little tired" -- Antonius Block