tm@laidbak.UUCP (02/16/87)
I really hate how Lattice C documents if at all the ST interface!! Lately, I have been trying to exec programs from within other programs. I suspect that the Lattice C equivalent of pexec is the ridiculously named shel_write, however, if I am right, the description is really ambiguous. I claim: rc = shel_write( exec, graf, gem, command, tail ) Start another application when this one terminates. Now, I don't want to exit the current application, only run another program and come back. Is this indeed the equivalent of pexec, and if not which one is it? Has anybody succesfully done using Lattice C anything like I am trying? Can somebody please email or post a small sample program with comments? Also, I looked in some usenet code (I think stmake) and the author seemed to be encoding the length of the tail in its first byte. However, this is not documented neither in my Lattice C manual (of course), nor in the Abacus internals. Finally, is the Abacus function number $4B for exec correct? Any sample program, clue, hint will be greatly appreciated. P.S. Please don't bother telling me to look in the LIB18.ASM compiler files, I have.
turner@imagen.UUCP (02/16/87)
in article <852@laidbak.UUCP>, tm@laidbak.UUCP (Takis Mercouris) says: > > Also, I looked in some usenet code (I think stmake) and the author seemed to > be encoding the length of the tail in its first byte. However, this is not > documented neither in my Lattice C manual (of course), nor in the Abacus > internals. undocumented as it may be, it's correct. the length of the tail must be the first byte of the tail `string`, also the max length of the tail is 127 bytes (0x7f) for example char command[128],env[128],tail[128]; /* these could be pointers and */ /* the exact amount of storage */ /* malloc'd */ strcpy(command,"d:\\bin\\emacs"); /* command */ env = NULL; /* inherit the parent's env */ strcpy(tail," @d:emacs.rc myfile.txt"); /* note the leading blank */ tail[0] = 22; /* length of tail */ ierr = Pexec(0,command,tail,env); /* 0 mode - load and go */ . . . > > Finally, is the Abacus function number $4B for exec correct? > Yes it is > Any sample program, clue, hint will be greatly appreciated see above, just for the heck of it here's the mode table: --------------------------------------------------------- | | |______mode_________ptr1________ptr2__________ptr3______| | 0 = load and go | file | command | environment | | | to exec | tail | string | --------------------------------------------------------- | 3 = load, no go | file | command | environment | | | to load | tail | string | --------------------------------------------------------- | 4 = just go | basepage| (unused) | (unused) | | | address | | | --------------------------------------------------------- | 5 = create | (unused)| command | environment | | basepage | | tail | string | --------------------------------------------------------- the environment string is either NULL or a pointer to series of NULL terminated strings of the form: string1\0 string2\0 . . stringn\0 \0 if you need any more info, i suggest you get the dev kit.. (quick, duck! incoming flames) -- --------------- C'est la vie, C'est la guerre, C'est la pomme de terre Mail: Imagen Corp. 2650 San Tomas Expressway Santa Clara, CA 95052-8101 UUCP: ...{decvax,ucbvax}!decwrl!imagen!turner AT&T: (408) 986-9400
ericr@hpvcla.UUCP (02/17/87)
shel_write is an AES call. Pexec is a GEMDOS call. The AES shell calls are more or less intended to allow multiple applications to share data via a "clipboard" file. If you can use calls such as Cconin and Cconout then you should be able to call Pexec. Note: these calls may be defined in an include file. Eric Ross ihnp4!hpfcla!hpvcla!ericr CIS: 72347,2664 GEnie: E.ROSS
john@viper.UUCP (02/17/87)
In article <852@laidbak.UUCP> tm@laidbak.UUCP (Takis Mercouris) writes: >I suspect that the Lattice C equivalent of pexec is the ridiculously >named shel_write, ... ............................ >Is this indeed the equivalent of pexec, and if not which one is it? No, it isn't. Not having Lattice for the ST, I can't tell you which function to use, but I'm sure that one isn't it. shel_write is an odd GEM function which sets up an alternate program (other than the desk-top or your current command shell) that will run on exit. The function number $48 listed in the Abacus "internals" book is correct. > >Also, I looked in some usenet code (I think stmake) and the author seemed to >be encoding the length of the tail in its first byte. However, this is not >documented neither in my Lattice C manual (of course), nor in the Abacus >internals. > No, it isn't documented anyplace I've looked, but that -is- the correct way to call pexec. The first byte of the command tail string must contain the number of bytes in that string. Some people have been passing a pointer to the first byte after the program name which is normaly a space. This is fine as long as the programmer never uses a command tail longer than 32 bytes, but most people don't type command lines longer than that. When they finaly do try something that takes lots of typing, they (or some poor unsuspecting user) gets fried when the system stops noticing anything after the 32nd character... Hope this helps.... --- John L. Stanley (john@viper.UUCP) Software Development Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
rh@paisley.UUCP (02/18/87)
In article <878@imagen.UUCP> turner@imagen.UUCP (D'arc Angel) writes: > >if you need any more info, i suggest you get the dev kit.. > >(quick, duck! incoming flames) Duck ... you must be joking . I've got lattice and the dev kit. The only good thing about the dev kit is the info and most of that is irrelevant and some of it wrong including the info on pexec() . The dri compiler is bug ridden, the F.P. library unusable etc. My copy even had ctype.h and setjmp.h missing (tho' the code/table is in gemlib). Mmm.. I do like sid though, and the dri C puts in a symbol table! Adb it's not but its better than nothing. Your info on pexec() is faultless. One other thing to say is to remember to free some memory as described in the LAttice manual. Anybody out there using another Metacomco product called Cambridge Lisp ? -- JANET: rh@uk.ac.paisley.cs EMAIL: rh@cs.paisley.ac.uk | Post: Systems manager. UUCP: ...!seismo!mcvax!ukc!paisley!rh | Department of Computing, Phone: +44 41 887 1241 Ext. 219 | Paisley College | High St. Paisley. | Scotland. | PA1 2BE