Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!claris!apple!lsr From: lsr@Apple.COM (Larry Rosenstein) Newsgroups: comp.sys.mac Subject: Re: Preemptive and Nonpreemptive Multitasking Message-ID: <7880@apple.Apple.Com> Date: 9 Apr 88 01:01:59 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> Reply-To: lsr@apple.UUCP (Larry Rosenstein) Organization: Advanced Technology Group, Apple Computer Lines: 81 In article <238@cf-cm.UUCP> ralph@computing-maths.cardiff.ac.uk (Ralph Martin) writes: > >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! In most of the cases where handles are created by the Toolbox, the programmer can treat them as uniterpreted 32 bit numbers. The Toolbox will take care of locking them if that is necessary, and usually will provide procedure calls to access their contents. In some (unusal) cases, however, you do have to access the contents of a Toolbox handle directly and will have to dereference it twice. My original comment was intended to refer to the application-specific parts of a program. There is no requierment that you use handles internally in your program, and since the Mac Memory Manager provides a way to create pointers to non-relocatable blocks you have the freedom to choose the memory management model you want. >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 I don't claim that MacApp is perfect, only that it solves many of the problems of Macintosh programming, andthat it is being improved (based on developer feedback). >through enough (e.g.the way modeless dialogs work), there are The dialog support is being totally rewritten. Part of the problem in the old UDialog was that we tried to use the ROM Dialog Manager where possible, and there was a mismatch in the models used by MacApp and the Dialog Manager. In MacApp 2.0, the new dialog unit doesn't use the Dialog Manager at all, and things are much cleaner and more consistent. >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 I think this requires defining a new view class, but that's all. It is true that there are some classes that would be helpful to provide. We tried to make MacApp as solid as possible, and didn't have time to write very many building blocks. There are some building blocks available from the MacApp Developer's Association. >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 think MacApp's memory management is as easy at will get on the Macintosh. There is no virtual memory, so you have to worry about memory requests that can fail. You have to tell MacApp how much memory to reserve for your maximum working set, and you have to check for errors returned by the Memory If you do these 2 things then MacApp will make sure that your program doesn't crash. We have gotten some very positive feedback from MacApp users. The fact is that people have written some sophisticated programs with MacApp. They cover a wide range of application areas (music, word processing, filing, engineering). On the other hand, we don't usually hear from developers who are unsuccessful with MacApp. >A much larger library of classes will be needed (For example, the MacApp 2.0 contains a larger variety of view classes. There is also a way to create all your views based on the description in a resource. This makes it much easier to create windows (including dialogs) in MacApp 2.0. >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. The manual is being rewritten and will include a tutorial section. MacApp 2.0 has a lot of improvements to make it easier to use. The first version of any large system is always going to have deficiencies. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 27-AJ Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr