Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!ucdavis!lll-crg!burnard
From: burnard@lll-crg.ARpA (David Burnard)
Newsgroups: net.micro.mac
Subject: Re: Using the Macintosh Toolbox with C (the authors comment)
Message-ID: <1067@lll-crg.ARpA>
Date: Wed, 27-Nov-85 13:48:51 EST
Article-I.D.: lll-crg.1067
Posted: Wed Nov 27 13:48:51 1985
Date-Received: Fri, 29-Nov-85 00:10:43 EST
Organization: Lawrence Livermore Labs, CRG, Livermore Ca
Lines: 102
Keywords: foo bar baz

(-----Who's afraid of the big bad line-eater?-----)

   Thanks to Chuq for his initial review of our book, "Using the
Macintosh Toolbox with C". I think he does a reasonable job of
pointing out some of the strong (and weak) points of our book.
We really would have liked to include the topics he mentions (Sound,
DA's, printing, ..., devices, drivers, serial I/O) but the pressures
of getting back to school/work kept us from including these topics.
Still, we are considering another book covering these subjects, if
people are interested, let us know...

   In response to Chuq's review, was a question about what he meant by
the phrase "hiding parts of the system with the pascal function or
subroutine declaration" (or words to this effect). For those of you
who haven't compared the grundge-level features of the available C
compilers, let me summarize the situation...

   Lets begin with how the various systems generate "normal" Toolbox
calls. Two different approaches have emerged to the simple problem of
dealing with the Toolbox. The problem results from the fact that the
routines of the Toolbox have different calling conventions. Roughly
half of the routines expect their parameters to be passed on the stack
(most of the high level managers) while the other half expect their
parameters in registers (low-level managers like File and Memory). How
can the compiler deal with this?

   Approach 1: Smart Compiler - Consulair (and Aztec) have built the
   necessary smarts into their compilers to generate the correct
   linkage to each of the 400 or so traps. This of course leads to a
   larger somewhat slower compiler than the following...

   Approach 2: Glue - MegaMax and the SUmacc systems take the opposite
   approach of hiding all of the linkage routines in object libraries.
   So instead of calling the trap directly, the call is routed through
   a tiny routine which sets up the stack/registers appropriately for
   the Toolbox call. This makes for an ultrafast compiler but leads to
   long link times since the Glue must be attached by the Linker. (Now
   you know why MegaMax had a linker that removed unused subroutines long
   before Consulair did...)

   Either of these methods is OK by me. I'm not trying to compare
which is better or worse, just let people know whats going on. (I was a
little surprised when I fired up TMON the other day to look at some of
the code in MacKermit, and couldnt find any Traps anywhere...except
all smashed together at the end. Much less understandable when you're
debugging - no wonder people are screaming for symbolic debugging).


   Now lets look at the other situation, when one of the routines in
the Toolbox calls a routine supplied by the programmer. Some familiar
examples are TextEdit's TEClick (ClikLoop and WordBreak routines), the
action procs for TrackControl and the filter procs for the Standard
File Package. Again there are two different situations that arise: the
parameters can either be passed in registers or on the stack. 

   If the parameters are passed on the stack, then some compilers
   (soon, even Consulair) allow you to declare your action proc, or
   whatever, to have a pascal linkage:

        pascal MyActionProc(arg1, arg2,...,argn)
 
   this insures that the arguments are passed correctly to your
   procedure. In fact some compilers declare the Toolbox routines to
   be of type pascal.

   The nasty case, which prompted Chuq's original comment, occurs when
   the Toolbox routine passes the parameters to your routine in
   registers. Here, everyone is equal...you have no choice but to get out your
   Motorola assembly manuals and write the dreaded "Glue Routine" to
   take the parameters out of the registers and stuff them where your
   compiler wants to find them. (which again can be either on the
   stack, or in some other registers).

   So lets suppose that I write a book about using the Toolbox with C
(you'd have to be crazy!), how should I present these special cases?
Unfortunately there will be absolutely no chance of portability here.
Worse, if I use the pascal directive, readers using systems with no
pascal directive will be left in the dark. So we tried to explain a
little about what was going on, and included the glue routines needed
for Consulair. Then, at least we have shown the worst case, if you can
use the pascal directive then so much the better.

   Remember to take pity on Consulair users, until Andy Shebanow's
   IMLib came along we had to write glue just to use any of the
   packages!!! That reminds me, I should post a note about MDSMake...


   Does this answer anyone's questions? Or has everyone hit the 'n'
key to move on to the flammable "discussion" regarding how to make Mac
programs portable (about the most ridiculous thing I have ever heard).

                                               Until next time,

                                               Dave Burnard

                                     (also speaking on behalf of 
                                      Fred Huxham and Jim Takatsuka)

                                               burnard@lll-crg.ARPA


   The standard disclaimers...Hey wait a minute that's our book!