Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!apple!portal!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Return codes & how to kill()
Message-ID: <2914@atari.UUCP>
Date: 25 Apr 91 20:54:42 GMT
References: <1991Apr19.164531.22350@mks.com>
Distribution: na
Organization: Atari Corp., Sunnyvale CA
Lines: 37

ant@mks.com (Anthony Howe) writes:
>I've been hunting high and low in the DevDocs for information on
>how a parent process finds the return code of the child process.
>Now I know Pexec() returns a value when it executes a program, but
>I only use Pexec() to load, and I initiate the program through
>separate means.

Sigh.  I guess there's nothing much to say about this...  Are you SURE you
can't use Pexec to execute the program, too?  Try mode 4, then Mfree the
environment and basepage (in that order) that were created when you used
Pexec mode 3 or 5 (whichever you used).  Starting with TOS 1.4, you can
use Pexec mode 6: mode 3 plus mode 6 equals mode zero.  The return code
from mode 6 will be the return code from the process.

>Q: What I want to know is the return code passed back in D0, on the 
>   stack, or in some global system location?  Is the return code
>   available at the time of the call to the Terminate Handler?
>   I'm trying to make mods to the Sozobon Debugger to handle printing 
>   the return values before it exits.

The return code is not available at the terminate handler.  The return
code is the argument to Pterm() or Ptermres(), or zero for Pterm0().
If you want, I guess you could catch those calls and squirrel away the
return code before passing the call on to GEMDOS.

>Q: If I've used Pexec() to load a program and I'm handling the 
>   execution of parts of that program.  How can I tell the system
>   to terminate that child process.  Basically I want a kill() or
>   a ptrace(PT_KILL_PID, child, 0, 0) so that I can add a restart
>   command.

You have to execute a Pterm() call while the process is the "current
process" as far as GEMDOS is concerned.

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt