Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!sri-spam!ames!amdahl!nsc!voder!apple!lsr
From: lsr@apple.UUCP (Larry Rosenstein)
Newsgroups: comp.sys.mac
Subject: Re: What makes programming the Mac difficult?
Message-ID: <981@apple.UUCP>
Date: Wed, 10-Jun-87 13:19:48 EDT
Article-I.D.: apple.981
Posted: Wed Jun 10 13:19:48 1987
Date-Received: Sat, 20-Jun-87 04:39:35 EDT
References: <869@apple.UUCP> <1499@midas.TEK.COM>
Reply-To: lsr@apple.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 69

In article <1499@midas.TEK.COM> herbw@midas.UUCP (Herb Weiner) writes:
>
>2.  I want to do a CopyBits of more than 3K bytes.  I must write a loop to
>do this.  Why couldn't the toolbox routine include a check for the 3K
>limit and  automatically copy the picture in 3K chunks?  (Or better yet,
>check how  much stack space is available, and optimize the copy for the
>size of the  stack.)
> 

I don't think the problem is with the CopyBits itself.  I have done large
CopyBits with no problems (although this was using srcCopy mode, which
might be a special case).  The only reference to a 3K limit I can recall is
in the Tech Note about MacDraw's picture format.

The problem there is that if you create a QD picture that contains a
CopyBits call, QuickDraw will pack the bitmap in order to save space.  When
an application tries to draw the picture, QuickDraw will allocate a handle
into which it can unpack the bitmap.

So a courteous application will create the picture using small CopyBits, so
that the receiving application doesn't require as much heap space to draw
the picture.  

I think it would be a mistake for QuickDraw to decide to do the CopyBits in
pieces behind the programmer's back.  That could have an unknown affect on
the application, and is not necessary in some cases.  Quickdraw should,
however, recover gracefully from a lack of memory when drawing a picture.

In general, one of the things I think makes programming the Macintosh
difficult is the lack of error handling by the ROM.  I will point out that
the error handling has improved greatly since the old 64K ROM, and keeps
getting better.

>4.  Writing custom routines to TrackControl (with different numbers of
>parameters  for different situations).

This was an architectural mistake by the original ROM designers.  They
wanted to save ROM space by using the DragGrayRgn call to drag a control's
indicator.  Unfortunately, DragGrayRgn's actionProc takes no parameters,
while TrackControl's take a couple of parameters.  Hence the conflict.

>I recognize that MacApp *might* solve some of these criticisms, but MacApp
>is not a solution for everyone.  It certainly will not help me with the
>maintenance of applications that I've already written.

You are right on both accounts.  MacApp does take care of some of these
things for you (eg, outlining the default button and dealing with HFS).  We
never expected people to rewrite their applications to use MacApp.  The
best you can do is get the MacApp source listings and see how we handled
these situations.  

(If people are interested in a particular topic -- eg, HFS -- I or someone
else can post a short note about how we handled it in MacApp.)

>Finally, I would like to point out that I would not have taken the time to
>offer these constructive criticisms if I did not like my Mac.

You should not have to appologize for well thought out, constructive
criticism.  I would like to see more comments from other people out there.

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.com