jeff@visix.UUCP (Jeff Barr) (04/12/89)
> [ I was complaining about the lack of multitasking on the PC and MAC ] > > In article <191@visix.UUCP>, jeff@visix.UUCP (Jeff Barr) writes: > > This is purely an operating system problem, its not related to the interface > > at all. > > It's related to the interface, since most of what little O/S there is on the > Mac (and now with Windows and its successors, the PC) is entirely oriented > towards the user interface. You can't write a program on these machines > unless it's tied tightly to the user interface. The whole concept of running > in the background is alien. I disagree, but don't have the time to get into a major discussion about this. The operating system and the interface are distinct on both the Mac and Windows. I'll agree that background support is limited (but possible on both of these operating systems). A sufficiently powerful interface should allow access to all interesting parts of the underlying operating system; it shouldn't ignore powerful (but sometimes hard to visually present/activate) features. Jeff > -- > Peter da Silva, Xenix Support, Ferranti International Controls Corporation. > > Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. > Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com. /\ Jeff Barr \ / Visix Software, Inc. /\ 800-832-8668 \ / / \ uunet!visix!jeff \ / 1525 Wilson Blvd. / \ 703-841-5858 \ / / \ \/ Arlington, VA 22209 / \ \/ "A MIMD is a terrible thing to waste."
austing@Apple.COM (Glenn L. Austin) (04/12/89)
In article <3810@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >[ I was complaining about the lack of multitasking on the PC and MAC ] > >In article <191@visix.UUCP>, jeff@visix.UUCP (Jeff Barr) writes: >> This is purely an operating system problem, its not related to the interface >> at all. > >It's related to the interface, since most of what little O/S there is on the >Mac (and now with Windows and its successors, the PC) is entirely oriented >towards the user interface. You can't write a program on these machines >unless it's tied tightly to the user interface. The whole concept of running >in the background is alien. Running in the background is alien to the Mac and Windows?!? Boy, you'd better let the authors of the background print spoolers know that so that they can fix their programs to run only in the foreground rather than in either the foreground or background, or background only in those two systems! In fact, there is a program on the Mac that runs *ONLY* in the background under MultiFinder -- Backgrounder. Guess what -- no user interface. All it does is watch for print spool files and start up another program to manage the spool. I guess the Mac can't really handle that! ;-) ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
peter@ficc.uu.net (Peter da Silva) (04/13/89)
In article <192@visix.UUCP>, jeff@visix.UUCP (Jeff Barr) writes: > The operating system and the interface are distinct on both the Mac > and Windows. Every Mac program I have ever seen has been a slave to GetNextEvent. This is distinct from the operating system? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
peter@ficc.uu.net (Peter da Silva) (04/13/89)
In article <28834@apple.Apple.COM>, austing@Apple.COM (Glenn L. Austin) writes: > Running in the background is alien to the Mac and Windows?!? You you'd better > let the authors of the background print spoolers know... Oh yes, you write a program that looks like a device driver and claim that it's just another program running in the background. Gack. You can not take a random Macintosh program and stick it in th background. It's tied to GetNextEvent. When you can run a compile concurrently with Photon Paint then you can make the claim that the Mac supports background processing. I've been able to do that on the Amiga for years. Even before I got my RAM expanded, though I couldn't actually compile and run Deluxe Paint together in 512K. Now with plenty of RAM I can compile a program while using Photon or Deluxe Paint to work on the imagery... without really slowing the compile down, since the program isn't busy-waiting on GetNextEvent. It's limited by my speed. Even with 512K Deluxe Paint got along fine with all manner of programs. Plain, ordinary, programs that don't require learning a whole new paradigm. Because on the Amiga, as on UNIX, the operating system handles time-slicing. Your program can completely ignore the user interface, sit on the CPU as long as it wants, and the system will happily chug along. If you guys had written a decent conventional O/S for the Mac and stuck the user interface on top of it I'd be using it now instead. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
wyle@inf.ethz.ch (Mitchell Wyle) (04/14/89)
>>[ I was complaining about the lack of multitasking on the PC and MAC ] >>> This is purely an operating system problem, its not related to the interface >>> at all. >>It's related to the interface, since most of what little O/S there is on the >>Mac (and now with Windows and its successors, the PC) is entirely oriented >>towards the user interface. You can't write a program on these machines >>unless it's tied tightly to the user interface. The whole concept of running >>in the background is alien. >Running in the background is alien to the Mac and Windows?!? Boy, you'd better >let the authors of the background print spoolers know that so that they can >fix their programs to run only in the foreground rather than in either the >foreground or background, or background only in those two systems! In fact, >there is a program on the Mac that runs *ONLY* in the background under >MultiFinder -- Backgrounder. Guess what -- no user interface. All it does is >watch for print spool files and start up another program to manage the spool. The original point is more subtle; there is no crontab in DOS or MacOS; there are no daemons. There is only poor programmer support for background processing (get-next-event in mac-OS); OS/2 appears a bit better in this regard. Even the wonderful spooler in multi-finder feels it must tell the user what's happening and creates the print-monitor process. The programs are *all* *HOMUNCULOUS*!! We want *true* background processing! We want "daemon" support! Consider this Bourne-shell construct which has worked for 16 years, up through new versions of Unix! if test "$0" != "/bin/sh" ; then # check if we're fork'd /bin/sh < $0 & # Fork ourself in background, leave exit 0 fi # Child process: while <something> ; do [.... do real work...] sleep 300 done --------------------------------- Now do you get it? Unix was born to run background processes; OS/2 is getting there (though slowly). Mac-OS is moving even more slowly because the programming philosophy is so user-interface centered; application writers must put special code into their programs which give up the CPU; it should be the other way around. MIND (by Greg Dudek) did some great stuff with pre-multifinder mac-OS; it was the closest thing to a "true" background process I found. BTW: will mac-OS 6.0.4 (the "System" file) be larger than A/UX 1.1 "/unix" file? Inquiring mac-users want to know! ;-) -Mitch -- -Mitchell F. Wyle wyle@ethz.uucp Institut fuer Informationssysteme wyle@inf.ethz.ch ETH Zentrum / 8092 Zurich, Switzerland +41 1 256 5237