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