conn@stratus.UUCP (Avery Shealey) (02/10/88)
Does anyone have some example code / information on starting processes
that they could send me? I have seen the example in Peck's book.
What I want to do is to LoadSeg the process, CreateProc, set the input
and output streams, then detect the return value. I want the whole
procedure to be transparent to the process I am loading.
So far I have got the process to load and execute, but no I/O shows up.
I got the I/O to show by setting pr_CIS and pr_COS to my own processes
CIS and COS, but after the process exits, hello mister guru.
Any examples or information would be appreciated.
Thanks,
Avery
Avery Shealey
School of Information & Computer Science, Georgia Tech, Atlanta GA 30332
Internet: conn@stratus.gatech.edu CSNet: conn%stratus@gatech
UUCP: ...!{akgua,allegra,amd,hplabs,seismo,ihnp4}!gatech!stratus!connmike@ames.arpa (Mike Smithwick) (02/12/88)
In article <1029@stratus.UUCP> conn@stratus.UUCP (Avery Shealey) writes: >Does anyone have some example code / information on starting processes >that they could send me? I have seen the example in Peck's book. > >What I want to do is to LoadSeg the process, CreateProc, set the input >and output streams, then detect the return value. I want the whole >procedure to be transparent to the process I am loading. > >So far I have got the process to load and execute, but no I/O shows up. >I got the I/O to show by setting pr_CIS and pr_COS to my own processes >CIS and COS, but after the process exits, hello mister guru. > >Any examples or information would be appreciated. > >Thanks, >Avery > The following is not transparent, as it requires the childproc to be aware of it's heritage, but it may give you some ideas. I've been working with Rob's examples for the past few days, and came across similar problems (I gather that his was Lattice, which is why it doesn't work under Manx). I wanted to do what he did, that is to get the stdio redirected to the parent's CLI window, which is what I gather you're trying to do. I tried the pr_CIS/COS trick, and couldn't get it to work right. If you look at the Manx startup source, _main.c, you'll see what Aztec does to set up stdio. Using that I did the following: The parent proc sends the input and output filehandles to the child which it gets from the Input() and Output() calls. The child picks them up and simply stuffs them into its "_devtab". mymessage=GetMsg(port); _devtab[0]=mymessage->std_input; _devtab[1]=mymessage->std_output; Now printfs will work okey-dokey from your childproc. When you're done, make sure to reassign the orignal stdio pointers, otherwise you'll meet Mr. Guru. _devtab[0]=Input(); _devtab[1]=Output(); exit(0); Now I am still having some problems which has to do with the magic of AmigaDog vs. Manx IO. In variations of the above said childproc, I need to do some file IO. When standalone, the traditional C fopen(), fprintf() etc works fine. When launched as a childproc using LoadSeg() . . . All of that breaks. Rob Peck's book suggests that fprintf() will work with a FileHandle returned by Open(), but no-go on this end (another Lattice convention?). Even Open() was flakey. Another bit of strangness having to do with the way Aztec sets up it's stdio pointers. I did a printf in the childproc before I modified the devtab[] entries. Afterwards printf wouldn't work at all. I gather that the first time a printf is called, Manx initializes some stuff which needs to get tweaked along with devtab[]. Can anyone shed some light?? -- *** mike (Mr. Bug) smithwick *** "the only thing wrong with reality, it that it takes too much time" [discalimer : nope, I don't work for NASA, I take full blame for my ideas]
rap@ardent.UUCP (Rob Peck) (02/19/88)
In article <4680@ames.arpa>, mike@ames.arpa (Mike Smithwick) writes: > In article <1029@stratus.UUCP> conn@stratus.UUCP (Avery Shealey) writes: > >Does anyone have some example code / information on starting processes > >that they could send me? I have seen the example in Peck's book. > > > >What I want to do is to LoadSeg the process, CreateProc, set the input > >and output streams, then detect the return value. I want the whole > >procedure to be transparent to the process I am loading. > > > >So far I have got the process to load and execute, but no I/O shows up. > >I got the I/O to show by setting pr_CIS and pr_COS to my own processes > >CIS and COS, but after the process exits, hello mister guru. > > The following is not transparent, as it requires the childproc to be > aware of it's heritage, but it may give you some ideas. > > I've been working with Rob's examples for the past few days, and came > across similar problems (I gather that his was Lattice, which is why > it doesn't work under Manx). > > I wanted to do what he did, that is to get the stdio redirected to the > parent's CLI window, which is what I gather you're trying to do. > I tried the pr_CIS/COS trick, and couldn't get it to work right. If you > look at the Manx startup source, _main.c, you'll see what Aztec does to > set up stdio. Prelim errata-3 for the Programmers Guide To The Amiga ------------------------------------------------------ This is declared as prelim because I myself have not tried it. Quite some time ago, Steve Walton spent a lot of time going through the book and sent me several corrections, most of which I believe made it into errata2 that I posted. However, I had forgotten that I had received this mail message and am now posting it for those of you who might be working with Manx. (I have Manx and am using it more extensively also, so from now on, I will try both compilers before releasing something.) Here are Steve's comments, exactly as received: #begin QUOTATION mode: ============================================================== I have proctest/littleproc working under 1.2 and Aztec C 3.4. Rather than try to get Astartup.asm to work with Manx, I simply made the following changes to the Manx-supplied startup and cleanup routines, _main.c and _exit.c found on the second 3.4 distribution disk in the directory crt_src. These changes make them functionally equivalent to Astartup.asm. Both Files ---------- Remove all references to _devtab. Remove the #include of fcntl.h _main.c -------- 1. Add the line long stdin, stdout, stderr; to the beginning of the file to declare these external longs. 2. Just before the call to main(), add the lines: stdin = Input(); if((stdout = Output()) != NULL) stderr = Open("*",MODE_NEWFILE); This sets up the extern longs stdin, stdout and stderr to point to the AmigaDOS files in question. Astartup.asm sets stderr to be equal to stdout, but I prefer them to be separate, hence the Open(). _exit.c ------- 1. Add the declaration extern long stdin, stdout, stderr; to the top of the file. 2. Add to the beginning of the routine: if(stderr != NULL) Close(stderr); to close the stderr file that was opened. Finally, compile these two routines and littleproc.c and poroctest.c with the +L switch to the Manx cc, put the CBM amiga.lib (on the 1.2 native developers' kit) somewhere where ln can find it, and link with the commands: ln -o proctest _main.o _exit.o proctest.o +l amiga.lib +l -lc32 and similarly for littleproc. This will take a *long* time, and should be done with the amiga.lib in a RAM disk (or with Facc installed). Manx's library format is much more efficient than the Amiga's. I actually went through proctest.c and littleproc.c and fixed all the places where there was an int where there should have been a long or a pointer; declarations of FindTask() and AllocMem, declarations of mm_inputHandle and mm_OutputHandle and declarations of stdin, stdout, stderr and myOutput (or whatever littleproc called it). I also made sure the arguments to system calls were long, for instance by changing FindTask(0) to FindTask(0L) and casting the sizeof() arguments to AllocMem and FreeMem to long. This allowed them to work without the +L cc switch. Hope this all helps. I haven't tried the above _main and _exit with inittask, but it should work, provided a call to geta4() is added to the start of the child task. ================================================================= #begin ASIDE ------------------ In a separate mail message, 6 days prior to the above message, Steve also provided the following: ------------------ #end ASIDE ================================================================= There is no Manx equivalent of ASTARTUP.OBJ. stdin, stdout and stderr always point to Manx file descriptors rather than AmigaDOS file handles. Since the Manx functiosn printf/sprintf are a proper superset of the ones in amiga.lib, the examples in the book work fine without linking to amiga.lib. The original purpose of the Astartup.obj code was to make the programs smaller, but this is not a problem with Manx, nor I believe with the latest Lattice. The other itme, specific to proctest, is that new tasks should call the Manx-provided geta4() first. By default, Manx produces code in a "small model" in which all code references are done with a 16-bit offset from the value contained in A4. Since the value of A4 gets lost during a CreateTask() call, Manx's hook into Exec's CreateTask saves A4 in a global variable; getA4() places the contents of that global back into A4 for use by the new task. If this is too much trouble, the new +P (super-portability) switch to Manx's cc command might be used. However, you'll need to use cl32.lib (and ml32.lib, if need be) in this case, rather than c.lib. ================================================================= Hope it helps everyone. Thanks again, Steve! Rob Peck ...ihnp4!hplabs!ardent!rap