Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!udel!eplrx7!leipold From: leipold@eplrx7.UUCP (leipold) Newsgroups: comp.sys.mac Subject: Re: Real Multifinder (was Re: Hey Apple Mac engineers...) Message-ID: <738@eplrx7.UUCP> Date: 1 Sep 89 12:54:13 GMT References: <46100321@uxe.cso.uiuc.edu> <1989Aug15.001507.14552@sj.ate.slb.com> <24626@iuvax.cs.indiana.edu> <3997@internal.Apple.COM> Reply-To: leipold@eplrx7.UUCP (Walt Leipold) Distribution: usa Organization: E.I. du Pont de Nemours & Co. Lines: 28 In article <3997@internal.Apple.COM> Larry Rosenstein writes: >It is possible to work under MultiFinder without writing any extra code, >although by writing some MultiFinder-specific code you can make the system >operate more smoothly. I've been watching this thread for a week or so, and have to disagree (partially) with the above. The original question appeared to refer to the amount of extra code you'd need to add to a Unix-style program (which gets backgrounding for free) to get it running in the background on the Mac. This is not just a matter of adding some Multifinder- specific code. Instead, you have to add an entire event loop to the program to allow Multifinder to timeslice it. And quite often, a program's original (hopefully) clean structure (the case for most Unix filters) is badly corrupted by contorting it to fit an event loop. Of course, you could argue that Unix-style filter programs don't fit the Mac's user interface model, and that their use should therefore be discouraged (or even made a punishable offense). However, there are a _lot_ of good Unix programs. I'd like to be able to use them "out of the box" on my Mac. And some tasks (that I'd probably like to run in the background anyway) are more efficiently handled with the Unix 'user interface standard' of filters and pipes, especially when enhanced by shell scripts and filename wildcards. -- "As long as you've lit one candle, Walt Leipold you're allowed to curse the darkness." (leipolw%esvax@dupont.com) --