Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!mailrus!umix!uunet!mcvax!ukc!reading!onion!cf-cm!ralph
From: ralph@computing-maths.cardiff.ac.uk (Ralph Martin)
Newsgroups: comp.sys.mac
Subject: Re: Preemptive and Nonpreemptive Multitasking
Message-ID: <238@cf-cm.UUCP>
Date: 31 Mar 88 09:42:51 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu> <1710@ssc-vax.UUCP> <234@cf-cm.UUCP> <7769@apple.Apple.Com>
Organization: Univ. Coll. Cardiff, Cardiff, WALES, UK.
Lines: 48
In-reply-to: lsr@Apple.COM's message of 24 Mar 88 19:01:32 GMT
Posting-Front-End: GNU Emacs 18.47.1 of Mon Nov 23 1987 on v1 (berkeley-unix)

I feel I must reply to lsr's comments on my remarks:

>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.

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

>>sun, but I LOATHE programming it. On the sun, part of the OS (the notifier)
>>takes care of events and calls the bits of code I want in response to the
>>events. On the Mac, I have to ask all the time what is going on, figure out

>This is the application model used by MacApp.  MacApp goes beyond handling
>user events (eg, moving windows).  MacApp will handle moving & resizing
>windows without the programmer having to write any code.  But MacApp also
>takes care of printing, file management, memory management, error handling
>issues.

OK, so MacApp is supposed to take care of these things. I have also
used MacApp, and all I can say is that it is of limited use. Among my
criticisms are that parts of it are inconsistent or not thought
through enough (e.g.the way modeless dialogs work), there are
omissions (e.g. it is not trivial to put a picture you have a handle
to on the clipboard - a very common requirement), 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! 

Before MacApp will be truly useful, many of these things will need
sorting out (or better, the Mac OS rewriting!).
A much larger library of classes will be needed (For example, the
usual type of window shows a larger part of the document if it is
expanded.  Equally valid would be to expand the window's contents with
the window).
The classes also need to be much better defined and documented (these
are not the same). This will reduce many of the unfortunate side effects
and interactions which make MacApp so tedious at present.

OK, I will get off my high horse now. I love using the Mac - I just wish that
it wasn't such a pig to program. C'mon you guys - it doesn't HAVE to be like
this. When you bring out the Mac III or whatever it's called by then, lets 
have a REAL operating system, as a firm basis to start from, with a lot of the
tedious rhubarb hidden from the programmer!