🚀 go-pugleaf

I'm sorry, but as a Mac programmer of some experience I need to comment on this
one...

First, I'm going to put words in Mr. Rosenstein's mouth:
> *Excerpts from: 31-Mar-88 Re: Preemptive and Nonpreem.. Ralph*
> *Martin@computing-m (2691)*

> >Handles on the Macintosh are optional (although very useful).  You can
> >allocate nonrelocatable blocks if you want, and you can lock handles to
> >prevent them from moving.  Memory is compacted only when needed, and the
> >times when this happens are well-documented.

I would clarify this by saying that "The use of Handles on the Macintosh for
internal program data types is optional, although very useful."

> *Excerpts from: 31-Mar-88 Re: Preemptive and Nonpreem.. Ralph*
> *Martin@computing-m (2691)*

> Optional my foot. Many of the toolbox routines have arguments which are
> handlesand if the programmer isnt careful in locking them down, he will soon
> learn
> that understanding the Mac's "memory (mis)management model" is NECESSARY!

The User Interface Toolbox routines do, in many cases, require handles as
arguments. However, I know of NO CASE where a handle passed to a UI Toolbox
routine needs to be locked. (There are some cases in the OS calls that require
that a buffer be locked, but you can use a nonrelocatable block or a pointer to
a statically allocated (e.g. an array) data structure. The programmer is not
required to muck around with handles - a good example is the Menu Manager. You
call GetMenu() which returns a MenuHandle. Then you call InsertMenu() which
puts it in the menu bar, and then you forget about it, unless you want to call
DisposMenu, or GetItem, or DisableItem, or some similar procedure. But at no
point in this process does the programmer have to care about what's in the
handle, or have to worry about locking or unlocking the handle.

For my user interfaces, I let the Memory Manager do its thing without
interference, and it works just fine for my purposes.

> *Excerpts from: 31-Mar-88 Re: Preemptive and Nonpreem.. Ralph*
> *Martin@computing-m (2691)*

> (e.g. it is not trivial to put a picture you have a handle
> to on the clipboard - a very common requirement)

Excuse me? EXCUSE ME?! Obviously, you've either never tried to put a picture on
the Clipboard, or you haven't expended the effort to figure out how to do it.
Watch:

        procedure CopyPicture(p : PicHandle);
        var
                err : OSErr;

        begin
                HLock(p);
                err := ZeroScrap;
                err := PutScrap('PICT', GetHandleSize(p), p^);
                HUnlock(p);
        end;

I have probably gotten the order of arguments to PutScrap wrong, because it's
been a while since I last did this. The point is, it *IS* trivial to do this,
whether it's a MacApp oversight or not.

> *Excerpts from: 31-Mar-88 Re: Preemptive and Nonpreem.. Ralph*
> *Martin@computing-m (2691)*

> if you try to do
> anything serious with it, you soon find that many things you want
> to do require overriding MacApp at much lower levels than should be
> strictly necessary, and the programmer STILL has to worry about memory
> management, despite the comment above - just look at the MacApp example
> sources if you want any proof!

I don't use MacApp, (I've posted on the subject and won't rehash it here) but I
am not surprised. First of all, MacApp is not a total application development
library - you can't expect that your application can be implemented by a few
library routines. Consider: MacApp is a "Generic MACintosh APPlication". It is
a FRAMEWORK. It provides the basis so that you don't have to worry about
writing the major user-interface features. I repeat: it IS NOT (and, I suspect,
wasn't designed to be) a total solution.

        *> Excerpts from: 31-Mar-88 Re: Preemptive and Nonpreem.. Ralph*
> *Martin@computing-m (2691)*

> Equally valid would be to expand the window's contents with
> the window).

True, except that expanding the window's contents is a highly
application-specific function. If you're using a text editor, and you make the
window bigger, do you REALLY want to use a bigger typeface? I kinda doubt it.
Graphics applications have use for "Fit In Window" functionality, but again,
that's a trivial case - just supply a different rectangle to scale the picture
in.

> *Excerpts from: 31-Mar-88 Re: Preemptive and Nonpreem.. Ralph*
> *Martin@computing-m (2691)*

> I love using the Mac - I just wish that
> it wasn't such a pig to program.

        I enjoy using it too, and I *don't* think it's hard to program. True,
it's intricate, but there are many things in life that are more complicated.

> *Excerpts from: 31-Mar-88 Re: Preemptive and Nonpreem.. Ralph*
> *Martin@computing-m (2691)*

> with a lot of the
> tedious rhubarb hidden from the programmer!

You have completely missed the point of the Macintosh User Interface Toolbox
and of MacApp. The "point" being that the Toolbox frees you from having to
implement the standard features (menus, windows, etc) for all of your programs,
and that MacApp frees you from having to implement the higher-level details of
using the ROM routines.

        Honestly, you can't expect to get something for nothing. I read from
this that that's precisely what you're after.

                --Rich

===================================================================
Rich Siegel
Confused Undergrad, Carnegie-Mellon University

The opinions stated here do not represent the policies
of Carnegie-Mellon University.

Arpa: rich.siegel@andrew.cmu.edu
UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rich.siegel
==================================================================