bryan@geo-works.UUCP (Bryan Ford) (07/14/89)
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?
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!)
Before you go and say 'DON'T DO IT!', consider that SysBase is used by many
programs to find out what type of processor and display is used, and
ThisTask should always be implemented. It is a *public* structure. 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.
Discussion, anybody?
Bryan
--
____________________________________________
_/ Bryan Ford - bryan@geo-works.geo-works.com \_
_/ ..!utah-cs!caeco!i-core!geo-works!bryan \_
/ ..!uunet!iconsys!caeco!i-core!geo-works!bryan \jesup@cbmvax.UUCP (Randell Jesup) (07/18/89)
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!"