Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!ncar!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!rochester!PT.CS.CMU.EDU!andrew.cmu.edu!rs4u+ From: rs4u+@andrew.cmu.edu (Richard Siegel) Newsgroups: comp.sys.mac Subject: Re: Preemptive and Nonpreemptive Multitasking Message-ID: Date: 6 Apr 88 13:30:31 GMT References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu> <1710@ssc-vax.UUCP> <234@cf-cm.UUCP> <7769@apple.Apple.Com>, <238@cf-cm.UUCP>, <8WKWrJy00VQFMQPVht@andrew.cmu.edu> Organization: Carnegie Mellon University Lines: 131 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 ==================================================================