Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!talcott!panda!genrad!decvax!wanginst!ulowell!page
From: page@ulowell.UUCP (Bob Page)
Newsgroups: net.micro.amiga
Subject: Re: Processes and return values
Message-ID: <286@ulowell.UUCP>
Date: Fri, 11-Apr-86 16:52:35 EST
Article-I.D.: ulowell.286
Posted: Fri Apr 11 16:52:35 1986
Date-Received: Mon, 14-Apr-86 01:54:11 EST
References: <11701@watnot.UUCP>
Reply-To: page@ulowell.UUCP (Bob Page)
Distribution: net
Organization: University of Lowell
Lines: 93

dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
> What I think we all need is the source to CLI.

I thought that too, but in talking to the developer of AmigaDOS, it
becomes apparent that it isn't true.  The CLI, NEWCLI, RUN, Execute()
are very closely tied together with the BCPL run environment.  What
we really need is to rewrite AmigaDOS in C :-).

>  The CLI seems to handle executing programs and getting
>return values with no problem at all.

True.  From what I can get out of the documentation and from my
talks with Metacomco (and months of crashing my machine), when CLI wants
to run a task, it does a LoadSeg() and attaches the segment header to
its (process->pr_CLI << 2)->cli_Module (questionable C, but you get the
picture.)  It then puts the command's name in cli_Command (I'm guessing,
I don't have any docs or code in front of me), fiddles with the
return address, mucks around with the stack and jumps to 
(long) (cli_Module << 2) + 4 (as described in one of RobP's recent
postings on getting retvals).

However, BCPL programs don't work that way!  They have a library of
code waiting for them when they start up, this saves about 10K per
file, through the use of dynamic run libraries (the Global Vector).
The BCPL programs (LIST, DELETE, etc) want an environment like
what John T. recently described in his article on port handlers.
Parameters, you ask?  Well, the CLI (as near as I can figure)
actually grabs the input file handle before the process starts up
and shoves the arguments into it!  Strange but true?

I/O is another problem.  Did you ever wonder why the CLI/Process
structures have CIS, COS, CurrentOut, StandardOut, CurrentIn, and
StandardIn?  Like, who uses each one, and for what?  I have wondered
myself.

And then there's pr_ConsoleTask, which is your message port to
receive Read and Write packets.  Make sure you set that up.  If
you're not doing your own console I/O (if you're using RAW: or
CON:, for example), pr_ConsoleTask is the filehandle you get
back when you open the device.

Oh, you must make an entry in the task table showing your allocated
task ID.  Set that number into your own task ID slot in your proc
structure.

> So how 'bout it, Amiga .....  Why are you putting us through hell when
> the answer is lying there in front of you.

Those folks at Amiga may be hard pressed to even explain what's going
on in the deep recesses of ADOS.  They did not write it, and from what
I've seen, do not enjoy dabbling in it.  Besides, graphics is more fun!

In article <11701@watnot.UUCP> rmariani@watnot.UUCP (Rico Mariani) writes:
> ...  However, since source hasn't already been
>provided I have this feeling that it's written in BCPL or something...

Exactly.  Have you ever read BCPL?  Besides, when I call West Chester,
they give me (a registered developer who signed a non-disclosure
agreement) the "it's Commodore's policy to never release source code"
routine.  Bah.

Now where'd that debugger go?

..Bob

I tried robp's suggestions about loadseg & runloadedcode.  I/O
doesn't work, and it seems to return twice!  Like:


Run();
printf("returned from routine, retval = %lx\n", retval);
UnloadSeg(seg);
printf("unloaded, leaving\n");
return(retval);

Actaually prints 'returned from ...' and 'unloaded ...' twice
(with the correct retval, BTW)
and then "Software Failure - Task Held" requester time.  Any hints?
Resulting guru numbers are 3, 4 and B (seems to be random).
I'm doing this from within my own environment (My own CLI, but my I/O
could be messed up - see above).  All the program that I LoadSeg does is:

printf("hello world\n");

and exits w/o a return statement.

Other than not being able to execute commands, my ZLI works fine :-)

..Bob
-- 
UUCP: wanginst!ulowell!page	Bob Page
ARPA: page@ulowell.CSNET 	U of Lowell CS Dept
VOX:  +1 617 452 5000 x2233	Lowell MA 01854 USA