anson@elrond.CalComp.COM (Ed Anson) (01/01/70)
In article <1544@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: > > All that is necessary >is that Multifinder be told that the application can run in the background, >which is indicated by a bit in a resource. (The Multifinder people tried >this with one public domain program and it worked fine.) This is great! I expect that (for example) Excel could be made to work this way. But I assume that the correct bit in the correct resource is not already set, since MicroSoft didn't know about this when they wrote the program. So... In order to help us all upgrade our compatible applications: What is the magic bit? In which resource? -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM
lsr@apple.UUCP (Larry Rosenstein) (01/01/70)
In article <1544@apple.UUCP> I wrote: > >You can say that the multitasking in Unix or the Amiga O/S is more >advanced, but you cannot say that Multifinder is not multitasking. >Multitasking is the ability to run 2 processes (apparently) at the same >time, which is something Multifinder can do. Someone asked me if this statement implied that MultiFinder could only run 2 processes at once. The answer is no. You can run as many processes simultaneously as you have memory for. I should have written "2 or more" instead of just "2". -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
ali@rocky.STANFORD.EDU (Ali Ozer) (08/16/87)
In article <2758@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Well, as long as the downloading loop cedes control of the processor every >time through, a trivial code change, then synchronous multitasking will >serve this end quite well. ... > I don't think you understand the Mac >very well, frankly. You don't need time-slicing with a notebook and pen, >and for 95% of the things on the Mac you don't need it, either. For the >remaining 5%, MultiFinder makes it pretty easy to write them so they can run >in the background, even in current versions. No coroutines, asynchronous >notifications, or other weird code structures, just periodically giving up >control of the processor. For something like a download or save, it ought >to be nearly trivial. For computation-intensive processing, presumably you >don't want to slow things down to that extent anyway, whether through >synchronous or asynchronous interruptions. I think I understand the Mac, so I will reply to this one... The multitasking we Amiga users talk about is the kind of multitasking that sits there waiting for you to need it. It's not the kind of multitasking that the programmer or the user has to prepare for. Any computer (even the C64) can be made to print in the background, but no programmer of user will take the time to do all the work, because it requires extra effort. Same with most Mac user's attitude towards multitasking --- They think it requires extra work, or means your programs will run twice as slow... Right now, as I'm typing this, I'm running VideoScape 3D, a *computationaly expensive* 3D graphics program. When I started running the program, I had no intention of reading news. But then I decided to create a 100-frame animation, and a pretty hairy one, one that's going to take about 20 minutes. After watching it go through the first 3 frames, I decided it was a waste of time, so I simply went to my CLI window and ran VT100, and here I am. VideoScape is running at priority -5, while VT100 is running at 0, so I feel absolutely no slowdown it my typing. But, VideoScape is already at frame 40, so it's running fine. Maybe a few percent slower, but hey, I got to browse through comp.sys.mac in the meantime, not an easy feat! (And when I say "few percent," I do mean 2 or 3 percent, not 20 percent. Amazing how little CPU typing requires.) I did not need to "change a few lines in my code," nor I did not need to decide before had that I was going to run VT100 during VideoScape. Then there's the programmers life. Think how much better Mac programs would be if you had multitasking. Those convoluted loops to get events! How you have to make sure everything gets done everytime through your loop. How CPU-intensive routines seem to step on user's input! Etc.. With "true" multitasking, an ordinary program can start up any portion of itself (say a function or a procedure) as a seperate task. The code is not duplicated, it just starts running as a task which either dies when the parent things it's had enough of a life, or when it hits its end. Just think about it, Mac programmers, if you had that ability, how much better your programs would look and how much better you would feel not having to do convoluted things... And to the person who said "you don't need messages in a graphics environment" --- well, what better way to get the tasks in a situation like this talking? I appreciate Apple's effort in trying to get the Mac to multitask --- what I don't understand is how they call these current attempts (like the Switcher and now the Multifinder) "multitasking". Ali Ozer, ali@rocky.stanford.edu [Wow I'm upto frame 62.]
zrm@eddie.MIT.EDU (Zigurd R. Mednieks) (08/19/87)
> >I think I understand the Mac, so I will reply to this one... > >The multitasking we Amiga users talk about is the kind of >multitasking that sits there waiting for you to need it. It's not the >kind of multitasking that the programmer or the user has to >prepare for. Any computer (even the C64) can be made to print in the >background, but no programmer of user will take the time to do all the work, >because it requires extra effort. Same with most Mac user's attitude towards >multitasking --- They think it requires extra work, or means your programs >will run twice as slow... > I think we are confusing multitasking with the relative merits of premptive and non-premptive scheduling. While the Amiga may work well with premptive scheduling, Unix, for example, does not work well on low-powered micros. It is partly due to the fact that the Mac is a single-tasking machine with limited (vertical-retrace manager) background tasking that it can run a slick window system as well as it does. It takes a 16Mhz 68020 to do as well with Unix and X or some other windowing environment. Take a look at an old 68000 based Apollo or Sun running some window system. It is pretty doggy. So, in order to maintain the quality, not merely the capability, of the Macintosh's interactive environment, non-preemptive scheduling lets each task decide exactly how much of the processor it ought to have. Badly behaved CPU hogs will, presumably, get bad reviews and people won't buy them. That is probably a better way of weeding them out than with some clever scheduling algorithm. Or, from another point of view, I would rather see application designers making CPU usage decisions than system designers. Personally, I don't mind writing software that hooks into the admittedly elaborate event processing structure of the Macintosh because it gives me total control over what is going on. I won't mind writing background tasks that use the various facilities in the Macintosh for background tasking because they too will allow more complete control over CPU allocation than premptive scheduling. -Zigurd ---------------------------------------------------------------------- Zigurd Mednieks MURSU Corporation P.O. Box 1894 Cambridge, MA 02138 (617) 522-9035
lsr@apple.UUCP (Larry Rosenstein) (08/20/87)
In article <496@rocky.STANFORD.EDU> ali@rocky.UUCP (Ali Ozer) writes: > >I did not need to "change a few lines in my code," nor I did not need to >decide before had that I was going to run VT100 during VideoScape. It turns out that some existing programs will run without change in the background under Multifinder. There are programs that were written to allow user interaction (menus choices, etc.) while it is off computing. The most common way of doing this is to poll for events while processing and handle the event normally when one comes in. Multifinder will do a process switch at these times. All that is necessary is that Multifinder be told that the application can run in the background, which is indicated by a bit in a resource. (The Multifinder people tried this with one public domain program and it worked fine.) >I appreciate Apple's effort in trying to get the Mac to multitask --- what >I don't understand is how they call these current attempts (like the >Switcher and now the Multifinder) "multitasking". You can say that the multitasking in Unix or the Amiga O/S is more advanced, but you cannot say that Multifinder is not multitasking. Multitasking is the ability to run 2 processes (apparently) at the same time, which is something Multifinder can do. It is true that Multifinder 1.0 uses non-preemptive scheduling as opposed to preemptive scheduling used by the Amiga or Unix. This means that applications have to be cooperative in order to run in the background. From the end user's point of view, the result is the same; you can have your computer do more than one thing at a time. The vast majority of users could care less how it works inside. The difference between Multifinder and the Amiga O/S is subtle and something that many users won't understand. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
maiden@sdcsvax.UCSD.EDU (VLSI Layout Project) (08/21/87)
In article <1173@elrond.CalComp.COM> anson@elrond.UUCP (Ed Anson) writes:
[much about Juggler/MultiFinder running regular programs in background]
#
# So... In order to help us all upgrade our compatible applications:
#
# What is the magic bit? In which resource?
# --
# =====================================================================
# Ed Anson, Calcomp Display Products Division, Hudson NH 03051
# (603) 885-8712, anson@elrond.CalComp.COM
The magic bit:
In ResEdit open the SIZE -1 resource in the application. This
was used for Switcher and includes information about switching,
memory requirements, etc. There are also a number of undefined
bits (radio buttons). The second undefined button is the magic
bit. This is information from MacExchange.
--
Edward K. Y. Jung
The Deep Thought Group: Searching for a better way to think.
UUCP: {seismo|decwrl}!sdcsvax!maiden
ARPA: maiden@beowulf.ucsd.edu