Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!sugar!peter From: peter@sugar.hackercorp.com (Peter da Silva) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Amiga basher Message-ID: <1991Jun17.225758.10283@sugar.hackercorp.com> Date: 17 Jun 91 22:57:58 GMT References: <56@ryptyde.UUCP> <1991Jun16.152251.17044@cunixf.cc.columbia.edu> <60@ryptyde.UUCP> Organization: Sugar Land Unix -- Houston, TX Lines: 35 In article <60@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: > First off, nearly all applications written before Multifinder multitasked > in it, and you DON"T have to "write your code in a very specific way". Yes you do. Whether under multifinder or not, a Mac application has to be written in a manner reminiscent of a device driver, with frequent calls to the operating system to allow it to schedule other tasks and DAs. The DAs themselves are even more complex, being similar to an interrupt handler or a task in an old-fashioned single-loop control system. In any case, all Mac apps are written to the same "event loop" model. Programs like HaiCalc, which use a client-server model, are impossible. Conventional UNIX programs that often spin for a protracted period number-crunching are extremely unfriendly to the Mac. > Anything that involves user interaction calls WaitNextEvent(), Or GetNextEvent in older apps. > which does > tell the OS that the app is waiting for user input and you should switch > to the next app. WaitNextEvent() is called all the time, not just when > apps are waiting for user input, because they always have to take user > input into account. I.e., all Macintosh apps are designed as interactive editors. Including inherently batch processes like compilers, or server-type programs like sequencers. > [various problems with the Mac], but that's cooperative multitasking for you. Yep... -- Peter da Silva. `-_-' . 'U` "Have you hugged your wolf today?"