🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #508

Re: Finding task and stdin/stdout handle pointers

#508
From: Randell Jesup
Date: Mon, 17 Jul 1989 19:55
52 lines
2994 bytes
In article <1727.AA1727@geo-works> bryan@geo-works.UUCP (Bryan Ford) writes:
>Is it naughty to get your task/process structure pointer by using
>'SysBase->ThisTask' instead of 'FindTask(0L)'?  I know for a fact that this
>will work fine for the current version of the OS, but how about future
>versions?

	This should be fine, though Bryce is the keeper of Exec, not me.

>Also, is it naughty to get the current input/output streams for your
>process by using 'ProcPtr->pr_CIS' and 'ProcPtr->pr_COS' instead of
>'Input()' and 'Output()', respectively?  How about 'ProcPtr->pr_Result2'
>and 'IoErr()'?  The direct methods are much better the function-calling
>methods, especially seeing how the dos.library handles its calls.  (Try
>stepping through a dos.library call with a debugger.  Uhgg!)

	PLEASE go through the calls.  I know that currently it works the way
you specify, but we may wish to add extra functionality in the future.  The
calls are there for a reason (admittedly unspecified).

	In fact, we're moving farther in the direction of accessing all the
process fields through dos library calls.

	As far as dos.library being ugly to step through, that will change
soon. :-)

>And
>the pr_CIS and pr_COS handles and pr_Result2 are part of *your* *private*
>process structure, which many programs access in many different ways
>anyway, so I don't think either of these structures can change too much,
>besides possibly being extended.

	Perhaps.  However, the structure is one of the few structures in the
system that no one call allocate: only the system makes processes.  (If they
try, I have a nice torture devised for them... ;-)  There are calls to access
those fields: use them.  It won't cost you space, and the time is costs you
is negligible considering the frequency of such calls.

	At some point we may bite the bullet and break people who don't go
through documented interfaces.  Don't be the bullet we bite down on.

	As a good example of how to program well on the Amiga, look at
MindWalker.  It worked under 1.0, 1.1, 1.2, 1.3, and I think it works under
1.4.  Fast ram doesn't break it, etc, etc.  The guy who programmed it says
he took the manuals at their word: he didn't make assumptions about things
the manuals weren't specific on.

	*End lecture* :-)

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"
Technical Details
Message-ID: <7337@cbmvax.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!apple!oliveb!amiga!cbmvax!jesup
References: <1727.AA1727@geo-works>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!apple!oliveb!amiga!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Finding task and stdin/stdout handle pointers
Message-ID: <7337@cbmvax.UUCP>
Date: 17 Jul 89 19:55:04 GMT
References: <1727.AA1727@geo-works>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 52