Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!hao!ames!amdahl!dlb!ardent!rap From: rap@ardent.UUCP (Rob Peck) Newsgroups: comp.sys.amiga Subject: Re: Processes Message-ID: <315@ardent.UUCP> Date: 18 Feb 88 18:36:59 GMT References: <405@boole.acc.virginia.edu> <932@ur-tut.UUCP> <1029@stratus.UUCP> <4680@ames.arpa> Organization: Dana Computer, Inc., Sunnyvale, CA Lines: 146 Keywords: processes Summary: info as received --- 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