peter@sugar.hackercorp.com (Peter da Silva) (01/13/91)
In article <MWM.91Jan10120936@raven.relay.pa.dec.com>, mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > Actually, "true multitasking", as it is commonly _used_, means > preemptive multitasking. That's because all systems that were designed to multitask from day 1 use pre-emptive scheduling, *except for* a few Forth real-time systems with extremely tight memory budgets. Pre-emptive multitasking is what people for years meant by "multitasking". Polled multitasking was always considered a sort of poor cousin, and systems like Polyforth that depended on it were looked down upon. When people started referring to polled multitasking in terms that indicated they didn't know the difference between the two the terms "real" and "fake" multitasking showed up. > If you've got a reference to a textbook that > defines the term (in any way), I'd appreciate hearing about it. I've got 10 years of experience in the process control industry that defines the term that way. The usual reaction to hearing that Apple is claiming they've got a real O/S finally on the strength of their polled scheduler, among my co-workers, is "you've got to be kidding". > Bullshit. Explain to a user who doesn't have the foggiest idea what a > scheduler is why his machine - which, as far as he can tell, behaves > exactly like an Amiga under normal operation - has "fake" > multitasking. No problem. Just demonstrate that his machine doesn't behave exactly like an Amiga. Cut it down to 512K and watch it crash. Start up more thana couple of applications in a 2 Meg machine. Ask why the mouse is moving funny. Have him try to do anything useful while formatting a disk. Ask him why he can't run multifinder on a Mac Classic. > Actually, I think it's silly to define "true multitasking" at all. I agree. It's silly to even talk about a polled scheduler as "multitasking". > Either something is multitasking, or it isn't. I've already explained > how to tell which is which. If you insist on defining "true > multitasking", do it in non-technical terms. How about "no > non-privileged task can starve any other task"? Funny, people in the process control industry consider UNIX daft because a low priority task can still execute while there are higher priority tasks executing. How about defining "real multitasking" as "real-time multitasking"? At least that has a pretty good definition. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/13/91)
In article <7504@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >No problem. Just demonstrate that his machine doesn't behave exactly like an >Amiga. Cut it down to 512K and watch it crash. Start up more thana couple The average Mac user knows less about the Amiga than the average Amiga user knows about the Mac. Be that as it may, you can run a Mac 512k, and even do task switching on it. >of applications in a 2 Meg machine. Ask why the mouse is moving funny. Have him I can start up a _bunch_ of apps on a 2 meg Mac (I just have to be selective about what I launch). >try to do anything useful while formatting a disk. Ask him why he can't run Yeah, that is a substantial criticism. I mean really, how OFTEN do you need to format a disk? It is nifty to be able to do so and run another task, but it just as easy to format a bunch at once and then go back to work. >multifinder on a Mac Classic. Get a new source for your Mac info. MultiFinder runs just fine on the Classic. When someone spreads misinformation about the competition, you begin to wonder how thoroughly they know their own machine. The Amiga already is an impressive bang/$ hunk of iron WITHOUT tilting the scales with caca spread about "the other guys".
thad@cup.portal.com (Thad P Floryan) (01/13/91)
awessels@ccwf.cc.utexas.edu (Allen Wessels) in <42459@ut-emx.uucp> writes (regarding the Mac): I can start up a _bunch_ of apps on a 2 meg Mac (I just have to be selective about what I launch). Not a very user-friendly system if your apps are load-order dependent. >try to do anything useful while formatting a disk. Ask him why he >can't run Yeah, that is a substantial criticism. I mean really, how OFTEN do you need to format a disk? It is nifty to be able to do so and run another task, but it just as easy to format a bunch at once and then go back to work. Oh? I'll tell you what really shows the Mac to be the rotten Apple that it is. My secretary uses a Mac II (for doing all kind of documentation type stuff) and was printing out a bunch of stuff on the Apple Laser printer that was to be our handout material at last month's DECUS in Las Vegas, when I happened to be in her office and asked "Hey, Jude, flip over to the terminal window and I want to show you something on the VAX." She said, "I can't, I'm printing and cannot do anything else for at least 45 minutes." Apple has the audacity and arrogance to claim the Mac makes people productive? BULLSHIT! If it wasn't for the fact we needed those printings NOW and the fact we've been suckered into paying so much for the Mac and its software, I was tempted to grab that CRApple Mac and toss it out the window and over the fence and teach her how to use AmigaTeX on one of the spare office Amigas (which, by the way, prints just nicely onto the same Apple Laser printer). And as for Allen's comment "but it just as easy to format a bunch at once and then go back to work." Again, bullshit. I was just doing some file transfers and noted, "Oh oh, HD is just about full" so I just flipped to a CLI window on the Amiga, formatted a few floppies WHILE THE FILE TRANSFER WAS STILL GOING ON, and then had disks upon which to write the transfer buffs with NO LOSS OF TIME on my part (re: formatting a buncha disks beforehand). Try THAT on your stinking Apple. I have so little respect for the garbage ensuing and spewing forth from Apple that we even "converted" the Finder 7.0 CD ROM disk last month to a playtoy "frisbee" for one of the office worker's kids. Yeah, Apple sends me all kindsa shit each month on 3.5" floppies and CD ROMs; I always reformat the 3.5" floppies for use on my Amigas or 3B1s (lucky for Apple their disk labels don't have permanent adhesive or I'd really be raising a stink, and the different colored disks each month look kinda pretty in my A1010 drives :-), the CD ROMs go to the kids (sometimes there's music on them, too), and the "Apple Developer Tech Notes" are sitting in boxes, unopened. Seems only 1 or 2 pages out of each month's 100-200 page mailing even has anything about A/UX, and, since A/UX 2.0, it's not even worth trying to FIND those 2 pages in the mess buried amongst all the IIgs, MacOS and Lisa crap, let along reading or using it. I'm really not kidding, and now with the BYTE article blasting A/UX publicly, my credibilty and esteem has risen to new heights in my company (regarding all my anti-Apple criticisms). Hmmm, I may even renew my BYTE subscription now (which I dropped several years ago due to their anti-Amiga editorial stance). Thad P.S. And before you start to reply, remember this IS comp.sys.amiga.ADVOCACY where one is expected to flame/be-flamed, and to tout the obvious superiority of the Amiga over everything else. As someone else recently stated, there oughta be a Federal law requiring everyone to buy/own an Amiga! :-) Thad Floryan [ thad@cup.portal.com ]
skank@iastate.edu (Skank George L) (01/13/91)
>Thad > >P.S. And before you start to reply, remember this IS comp.sys.amiga.ADVOCACY >where one is expected to flame/be-flamed, and to tout the obvious superiority >of the Amiga over everything else. As someone else recently stated, there >oughta be a Federal law requiring everyone to buy/own an Amiga! :-) > >Thad Floryan [ thad@cup.portal.com ] Things are starting to heat up kiddies!! :) Watch the sparks fly!! I love THIS new group! We should have done this a long time ago! Things will be really great when the B-Man gets back from break! I can't wait! (I can't believe I just said that!) :) --George -- George L. Skank | skank@iastate.edu |Fast cars, fast women, fast computers... Senior, Electrical Engineering |(not necessarily in that order)
root@zswamp.fidonet.org (Geoffrey Welsh) (01/13/91)
Peter da Silva (peter@sugar.hackercorp.com ) wrote: >Funny, people in the process control industry consider UNIX >daft because a low >priority task can still execute while there are higher >priority tasks >executing. How about defining "real multitasking" as >"real-time multitasking"? >At least that has a pretty good definition. Hunh? According to my last info, UNIX will only execute a low priority process if all active higher prio procs are in wait, and the low-prio proc should be interrupted if the wait condition for a higher prio proc is satisfied. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Molson 'C' compiler... it specializes in 'case' statements!
burley@geech.ai.mit.edu (Craig Burley) (01/15/91)
Regarding Mac's Multifinder, here is how to tell whether it has true multitasking (which does mean preemptive scheduling in any context I've ever heard the term defined): Start up a comms program and get a reasonably long file transfer going, like via kermit or X-modem. Now switch to the Finder or some other app (perhaps even the comm app itself, though mine, Microphone II, is smart enough to keep things going despite the pulled-down menu -- if it is its own). Now pull down a menu and hold it down for about five minutes. Now go back to the comms program window and see how much stuff has been transferred and whether the transfer has crashed. The answer should be "No, the transfer kept plugging along", but on the Mac it currently is, "Yes, when holding a menu in the pulled-down state, no other tasks on the system continued running except perhaps the vertical retrace task". If the comms program is smart enough to put the file transfer into the vertical retrace task, try using a long compilation instead of a comm program task instead, and see if it keeps compiling even while the menu is held down. Note that in any case, it is absolutely certain that on the current Mac, either you don't have true multitasking and it is fairly easy to expose it, or the programmers of the apps you are using have had to jump through hoops to disguise it (as did the Microphone II engineers -- for which I'm very grateful). (To be fair, as I've posted before, just doing true multitasking requires a bit of jumping through hoops for the OS and its applications -- but nothing like simulating it, efficiently, without actually having it.) Anyone care to post whether this kind of scenario works on the Amiga? I.e. when holding a menu down, or doing other purely user-interface things that aren't inherently resource intensive (like just holding a mouse button down without moving the mouse), does true multitasking keep working? My guess would be yes, it does. -- James Craig Burley, Software Craftsperson burley@ai.mit.edu
jimb@pogo.ai.mit.edu (Jim Blandy) (01/15/91)
This discussion makes True Multitasking sound like the True Grail, or True Love. There's an implicit value judgement there, and nobody wants their machine to lack True Multitasking, even if they can't agree on what that actually means. Let's abandon the term, and talk about what actually happens. A Mac running the Multifinder has non-preemptive multitasking; each task voluntarily gives up control. The Amiga does preemptive multitasking; a task may be stopped at any time. It is nice to be able to run other tasks while a task waits for its I/O to complete. The Mac won't do this (will it?); big-machine OS's like VMS and Unix will do this. The Amiga does this. My college OS textbook talks about "strict" and "non-strict" priority systems for scheduling. A strict priority system never runs a lower-priority task when a higher-priority task is runnable. Under a non-strict scheme, lower-priority tasks get less time, but don't starve. Both have their uses, but don't confuse them. The Amiga exec does provide system calls to disable and re-enable multitasking; I imagine this is because Commodore would rather provide a system call than have people non-portably hack it when they need it, but one doesn't need these calls in normal Amiga programming. I think the Amiga support for multi-tasking is a bit cleaner, perhaps because it was in the design early. Separate application heap zones are unnecessary, and processing can go on concurrently with I/O, for example. Backward compatibility is very important to Apple, and this constrains them. -- -Jim Blandy jimb@ai.mit.edu
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/15/91)
In article <JIMB.91Jan14143121@pogo.ai.mit.edu> jimb@pogo.ai.mit.edu (Jim Blandy) writes:
This discussion makes True Multitasking sound like the True Grail, or
True Love. There's an implicit value judgement there, and nobody
wants their machine to lack True Multitasking, even if they can't
agree on what that actually means. Let's abandon the term, and talk
about what actually happens.
Yes, yes, yes! That's been my point all along. It's judgemental, and
there is a perfectly good term to use for it's normal use here. Also,
nobody has come up with a textbook definition, which means that
misinterpretations due to people using different definitions is
possible.
<mike
--new@ee.udel.edu (Darren New) (01/15/91)
In article <JIMB.91Jan14143121@pogo.ai.mit.edu> jimb@pogo.ai.mit.edu (Jim Blandy) writes: >A Mac running the Multifinder has non-preemptive multitasking; each >task voluntarily gives up control. The Amiga does preemptive >multitasking; a task may be stopped at any time. It's worse than this. Try starting up multifinder, hypercard, and (say) tetris. I just did this last night because I wanted to play tetris but the owner of the machine had the hypercard stack open. Anyway, the music was all messed up and the blocks fell at different speeds, making it difficult to play. I then realised that hypercard must be sucking up CPU time even though it was not active, it was not running anything, and the mouse was not near the window. I confirmed this by closing hypercard and suddenly everything was fine. On the Amiga's exec, if a task is waiting for input, it does not take any CPU time until the input is ready. With cooperative multitasking (at least as implemented on the Mac), each application is asked "are you ready yet?" and each must answer, and this takes noticable CPU time away from the tasks that *are* ready. It also becomes easy to see where tasks can block other tasks, as the music plays fine if you hold open a menu, and totally stops when a floppy is inserted (until the floppy icon comes up). Anyway, by designing in the multitasking on the Amiga, it is possible for a task to totally give up the CPU and get it back later when it needs it. On the Mac, each task must constantly use CPU time to see if it needs more. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
es1@cunixb.cc.columbia.edu (Ethan Solomita) (01/15/91)
In article <JIMB.91Jan14143121@pogo.ai.mit.edu> jimb@pogo.ai.mit.edu (Jim Blandy) writes: > >A Mac running the Multifinder has non-preemptive multitasking; each >task voluntarily gives up control. The Amiga does preemptive >multitasking; a task may be stopped at any time. > Problem is, most tasks DON'T give up control. Mac programs have to be written to purposely give up control and many are still written badly enough to not work, MicroSoft being one of the worst culprits. The Amiga's MAIN advantage is that it is built into the system. You just don't do anything unusual with your program and it'll multitask very nicely. Yes, Apple is constrained by backwards compatibility, but I hate being constrained by backwards operating systems! 8) >The Amiga exec does provide system calls to disable and re-enable >multitasking; I imagine this is because Commodore would rather provide >a system call than have people non-portably hack it when they need it, >but one doesn't need these calls in normal Amiga programming. Actually it can be necessary for normal programming, and Commodore does give examples of programming where it is necessary. If you need to play with any of the system lists, such as task lists, message ports, and you don't use Commodore supplied functions, you'll need forbid/disable. Also, if you are changing some pointers in your internal structures, such as your screen and windows structures, you have to make sure that it never leaves a usable state, otherwise you need to stop multitasking. -- Ethan "Don't forget the importance of the family. It begins with the family. We're not going to redefine the family. Everybody knows the definition of the family. ... A child. ... A mother. ... A father. There are other arrangements of the family, but that is a family and family values." -- Dan Quayle, of course. Our beloved Vice President. It's just too easy!
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/15/91)
In article <37975@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >awessels@ccwf.cc.utexas.edu (Allen Wessels) in <42459@ut-emx.uucp> > >writes (regarding the Mac): > > I can start up a _bunch_ of apps on a 2 meg Mac (I just have to be > selective about what I launch). > >Not a very user-friendly system if your apps are load-order dependent. They aren't load-order dependent. Unfortunately, Mac developers (at least the ones doing major apps) are pretty sloppy about code size and applications can't request more memory (this is a simplification) from the OS, so they take up fixed amounts of space in MultiFinder partitions. For example, on a 2 meg Mac, the OS takes up about 250k, the Finder takes up 160k, Word wants 512, and Excel wants a meg. (These are all the current versions. I can do a lot better with older versions and still have lots of functionality.) >Oh? I'll tell you what really shows the Mac to be the rotten Apple that it is. >My secretary uses a Mac II (for doing all kind of documentation type stuff) and >was printing out a bunch of stuff on the Apple Laser printer that was to be our >handout material at last month's DECUS in Las Vegas, when I happened to be in >her office and asked "Hey, Jude, flip over to the terminal window and I want to >show you something on the VAX." She said, "I can't, I'm printing and cannot do >anything else for at least 45 minutes." I'm sorry your secretary doesn't have access to reasonable Mac support. I have a bunch of people on my network doing that sort of thing and they might have to wait 30 seconds or so for something to spool to disk so that it can be printed in the background. >Apple has the audacity and arrogance to claim the Mac makes people productive? > >BULLSHIT! Thanks, but it makes people who otherwise wouldn't be very productive with an IBM very much so with a Mac. I've been using Macs and helping Mac users since 1984. It is a pretty useful machine. Unfortunately, the same interface that helps those users also makes it difficult to maxmize the machine's potential. >suckered into paying so much for the Mac and its software, I was tempted to >grab that CRApple Mac and toss it out the window and over the fence and teach >her how to use AmigaTeX on one of the spare office Amigas (which, by the way, >prints just nicely onto the same Apple Laser printer). Like I said, just because you don't know how to use the machine doesn't mean it can't do the job. Who suckered you into buying the Mac? Any computer user that buys a machine without giving it a workout on the kinds of tasks that they expect of that machine deserves what they get. >And as for Allen's comment "but it just as easy to format a bunch at once and >then go back to work." Again, bullshit. I was just doing some file transfers >and noted, "Oh oh, HD is just about full" so I just flipped to a CLI window on >the Amiga, formatted a few floppies WHILE THE FILE TRANSFER WAS STILL GOING ON, >and then had disks upon which to write the transfer buffs with NO LOSS OF TIME >on my part (re: formatting a buncha disks beforehand). Well gee, funny how things work, but human beings can multitask too! I generally can pop a disk in and format it while doing some other non computer- related task. If your working habits are such that you need to format a disk on the fly, the Amiga is your machine. [comments on the inadequacy of Apple developer info deleted] >Thad > >P.S. And before you start to reply, remember this IS comp.sys.amiga.ADVOCACY >where one is expected to flame/be-flamed, and to tout the obvious superiority >of the Amiga over everything else. As someone else recently stated, there >oughta be a Federal law requiring everyone to buy/own an Amiga! :-) Well, I think there is a difference between a flame and just a bunch whining. If the Amiga is the superior machine, it will win without a bunch of uninformed dopes bad-mouthing a machine they don't know very much about. I'm very interested in what the Amiga CAN do and not very much interested in what some people THINK the Mac can't.
a186@mindlink.UUCP (Harvey Taylor) (01/15/91)
In <MWM.91Jan14145940@raven.relay.pa.dec.com>, mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows)) writes: |In article <JIMB.91Jan14143121@pogo.ai.mit.edu> jimb@pogo.ai.mit.edu | (Jim Blandy) writes: | This discussion makes True Multitasking sound like the True Grail, or | True Love. There's an implicit value judgement there, and nobody | wants their machine to lack True Multitasking, even if they can't | agree on what that actually means. Let's abandon the term, and talk | about what actually happens. | | Yes, yes, yes! That's been my point all along. It's judgemental, and | there is a perfectly good term to use for it's normal use here. Also, | nobody has come up with a textbook definition, which means that | misinterpretations due to people using different definitions is | possible. Quite so. And even more unsettling for rabid amigoids, I have seen proselytizing OS/2 types claim that the Amiga doesn't have "real multitasking" because it doesn't have memory protection. If one errant program can take down the system, it ain't multitasking, so they say. -harvey "The earth is a graveyard of angry young men." -some old greek Harvey Taylor Meta Media Productions uunet!van-bc!rsoft!mindlink!Harvey_Taylor a186@mindlink.UUCP
dege@cs.umn.edu (Dege Jeffrey Charles) (01/15/91)
In <JIMB.91Jan14143121@pogo.ai.mit.edu> jimb@pogo.ai.mit.edu (Jim Blandy) writes: >This discussion makes True Multitasking sound like the True Grail, or >True Love. There's an implicit value judgement there, and nobody >wants their machine to lack True Multitasking, even if they can't >agree on what that actually means. Let's abandon the term, and talk >about what actually happens. >My college OS textbook talks about "strict" and "non-strict" priority >systems for scheduling. A strict priority system never runs a >lower-priority task when a higher-priority task is runnable. Under a >non-strict scheme, lower-priority tasks get less time, but don't >starve. Both have their uses, but don't confuse them. It's because of this that the Amiga folks get so upset at the idea of Windows, Multi-finder, et al., calling themselves multi-tasking. Unix has a non-strict scheduling scheme, Amiga has a strict scheduling scheme, Windows and Multifinder are neither (the OS doesn't control scheduling, each application does that for itself.) In any case, it's the usefulness to the user that matters. Both Windows and Multifinder provide increased usefulness to their users. Beyond that, not much matters. --------------------------------
pswanson@umvlsi.ecs.umass.edu (Paul Swanson) (01/15/91)
In article <42516@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > >They aren't load-order dependent. Unfortunately, Mac developers (at least the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >ones doing major apps) are pretty sloppy about code size and applications can't >request more memory (this is a simplification) from the OS, so they take up >fixed amounts of space in MultiFinder partitions. As a matter of fact they are load order dependent. Some applications adjust when there isn't as much memory available as they want and some do not. Therefore I have to launch the apps which cannot adjust first so I can be sure to get all the apps running that I want. (In this particular case it is Excel, Mathwriter and Word. Word and Excel will use less space if there is not enough available but Mathwriter just won't launch if it is last. That seems kind of load order dependent to me). > >For example, on a 2 meg Mac, the OS takes up about 250k, the Finder takes up >160k, Word wants 512, and Excel wants a meg. (These are all the current ^^^^^^^^^^^^^^ What version of Word is this? The Word on the MAC right behind me is 668K and asks for 1Meg when it starts up. > >I'm sorry your secretary doesn't have access to reasonable Mac support. I have >a bunch of people on my network doing that sort of thing and they might have >to wait 30 seconds or so for something to spool to disk so that it can be >printed in the background. I hope you have a better background printer than the one supplied by Apple. When something is printing in the background I have found that even scrolling thru text is painful. > >[comments on the inadequacy of Apple developer info deleted] This was the best part of Thad's post! I'm sure that Allen can tell me that if I do this, that, or the other thing on the MAC that Multifinder works great. But that only proves that there is a difference between MAC tasking and multi-tasking because on the Amiga multi-tasking always works well. Paul.
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/16/91)
In article <1449@umvlsi.ecs.umass.edu> pswanson@umvlsi.ecs.umass.edu (Paul Swanson) writes: >As a matter of fact they are load order dependent. Some applications No, they are not. They are quit order dependent because of fragmentation, but excepting an older version of Excel, they aren't load order dependent. >adjust when there isn't as much memory available as they want and some This is a different issue. Some applications will run under memory conditions of less memory available than the programmer decided was "recommended". >do not. Therefore I have to launch the apps which cannot adjust first >so I can be sure to get all the apps running that I want. (In this >particular case it is Excel, Mathwriter and Word. Word and Excel will >use less space if there is not enough available but Mathwriter just >won't launch if it is last. That seems kind of load order dependent to >me). It seems load order dependent because Excel and Word probably need less memory than Microsloth decided they should have. MathWriter may _really_ need that memory. (As an aside, it probably isn't a good idea to run programs at under their recommended memory size unless you know you're going to be working with small files.) >> >>For example, on a 2 meg Mac, the OS takes up about 250k, the Finder takes up >>160k, Word wants 512, and Excel wants a meg. (These are all the current > ^^^^^^^^^^^^^^ >What version of Word is this? The Word on the MAC right behind me is >668K and asks for 1Meg when it starts up. This is Word 4.0 I am talking about. Do a Get Info on the Word application icon and look at the Suggested Memory Size number. It should be 512. Somebody upped the value for Application Memory Size on your copy, I think. >I hope you have a better background printer than the one supplied by >Apple. When something is printing in the background I have found that >even scrolling thru text is painful. I'm opening myself up for a cheap shot here, but you can be sure that most utilities provided by Apple aren't as good as third party alternatives (almost by definition). Print Monitor is a CPU hog, as is the Finder. You can get replacements for both. >I'm sure that Allen can tell me that if I do this, that, or the other >thing on the MAC that Multifinder works great. But that only proves >that there is a difference between MAC tasking and multi-tasking because >on the Amiga multi-tasking always works well. Tell me, are there default time slices for programs on the Amiga? Are you telling me that all Amiga users run their machines stock? Nobody uses PD/shareware/commercial enhancements? No custom setups? If so, I'm impressed, but saddened. I'd hoped to play with things (I like tweaking.)
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/16/91)
In article <1445@umvlsi.ecs.umass.edu> pswanson@umvlsi.ecs.umass.edu (Paul Swans on) writes: >How about this: Try playing tetris while a document is printing in the >background. I tried this exactly once and found it to be quite >irritating. Oh, and as for importance, if this were possible I bet it >would be one of the biggest uses of multi-tasking on the MAC! Try a different spooler or try spooling to RAM if your spooler will let you switch spool volumes. Here's a chance for you advocates out there to wax melodic. On the Mac there is a type of process called an INIT that multitasks with or without MultiFinder. I have about 25 of these (I'm running a "lean" (for me) setup) active, providing services like screen saving, network mail and file service, a calendar/reminder program, and zillion minor utilities like pop-up menus, a menuclock, macros, and keyboard shortcuts. How is this stuff done on an Amiga?
yorkw@stable.ecn.purdue.edu (Willis F York) (01/16/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: >Multitasking continues, however that screen is locked (any task doing output >to that screen is deferred) until you release that task. Programs that don't >output to that screen (either they have their own screen or they're smart and >spawned a task for display update) aren't affected. I've noticed somthing "Silly/odd/ect.." I was crunching some iff's with CRUNCH (By the Powerpacker guy) and the prograqm ticks off a %filedone %gained, in th cli. Works fine... BUT Say i ACCIDENTLY type a char in the cli window. (Without noticing it) the program will "pause" till i hit return or delete the chars... This Seems to be somthing that SHOULDEN't happen.... I seem to remember that programs like Lharc ignore stuff typed in and keep scrolling along.... Why does crunch act diffrently... (could it of been i was using a AREXX script to crunch a BUNCH of Pics) Just wondering..... Seems to "STOP" multiasking to me.... -- yorkw@ecn.purdue.edu Willis F York ---------------------------------------------- Macintosh... Proof that a Person can use a Computer all day and still not know ANYTHING about computers.
MBS110@psuvm.psu.edu (01/16/91)
In article <42568@ut-emx.uucp>, awessels@ccwf.cc.utexas.edu (Allen Wessels) says: > >In article <1445@umvlsi.ecs.umass.edu> pswanson@umvlsi.ecs.umass.edu (Paul >Swans >on) writes: > >>How about this: Try playing tetris while a document is printing in the >>background. I tried this exactly once and found it to be quite >>irritating. Oh, and as for importance, if this were possible I bet it >>would be one of the biggest uses of multi-tasking on the MAC! > >Try a different spooler or try spooling to RAM if your spooler will let you >switch spool volumes. > >Here's a chance for you advocates out there to wax melodic. On the Mac there >is >a type of process called an INIT that multitasks with or without MultiFinder. >I have about 25 of these (I'm running a "lean" (for me) setup) active, >providing >services like screen saving, network mail and file service, a >calendar/reminder program, and zillion minor utilities like pop-up menus, >a menuclock, macros, and keyboard shortcuts. > >How is this stuff done on an Amiga? Simple enough. On a multitasking computer, there's no need to distinguish between applications, "INITs," "desk accessories," the CLI, the "desktop," and so forth. All of these are just ordinary programs running concurrently. If you want a program (any program) to be run every time you boot the machine, you put its name in the Startup-Sequence -- an ordinary text file on disk that lists programs that should be automatically run on startup. I suppose this is the equivalent of an INIT, but you really can't compare the two. (You could, for example, put DeluxePaint or WordPerfect in the Startup-Sequence...) The advantage is that no special programming tricks are required. Macintosh desk accessories must be programmed to keep handing control back to the main application "as often as possible," and INITs require a lot of special writing, installation, and maintenance. On the Amiga, whether you're writing a huge application or a menu-bar clock, you don't need to use different techniques. /Mark "Remixed for Common Household Appliances" Sachs - MBS110@psuvm.psu.edu\ |DISCLAIMER: These are all YOUR opinions, strangely enough. || // AMIGA || | "Can I speak to you privately, Doctor?" "All right..." || \X/ Power || \== "Have you got a DEATH WISH?!!" -- Romana & The Doctor, Warrior's Gate ==/
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (01/16/91)
Somebody wimps about Mac attacks here, while providing the evidence to substantiate most of the criticsms just leveled, Thad Floryan [ thad@cup.portal.com ] writes: > P.S. And before you start to reply, remember this IS > comp.sys.amiga.ADVOCACY where one is expected to flame/be-flamed, and > to tout the obvious superiority of the Amiga over everything else. As > someone else recently stated, there oughta be a Federal law requiring > everyone to buy/own an Amiga! :-) Only one? There should be at least one in each room of the house, and several in the kitchen and family room. [Firepower in the commode, yeah!] skank@iastate.edu (Skank George L) writes: > Things are starting to heat up kiddies!! :) Watch the sparks fly!! I > love THIS new group! We should have done this a long time ago! Things > will be really great when the B-Man gets back from break! I can't > wait! (I can't believe I just said that!) :) Why thank you. An amazing number of people, humorless gits to the last man, woman, and child, complained about what a bad idea it would be to provide a separate forum for these conversations. Heh! > Fast cars, fast women, fast computers ... (not necessarily in that order) Yeah, but I got a woman with bucket seats, a computer with round heels, and a car with a tendency to RAM. Sigh. /// It's Amiga /// for me: why Kent, the man from xanth. \\\/// settle for <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> \XX/ anything less? -- Convener, COMPLETED comp.sys.amiga grand reorganization.
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (01/16/91)
> [Does Amiga multitasking work when menus are held open, windows moved, etc?]
Yep, I just did a cat /etc/termcap on my terminal emulator, flopped
screens, grabbed and held open a menu, flipped screens, and the listing
kept coming through. I slid the terminal screen down, grabbed the screen
behind, and moved some windows and the screen around; you can see the
(blitter?) processor contention in a change of listing speed, but the
listing kept arriving.
I also hit a requestor on my terminal emulator screen by accident
(grabbed the wrong screen's menu), saw the text display pause while I
satisfied the requestor, then catch up in a gulp when the requestor went
away; the text still was arriving through the modem, but the separate
display task was paused to avoid overwriting the requestor (not, in this
case a true requestor, but just a prompt in the same window); despite
Mike Meyer, being able to spawn independent threads within a single
program _is_ an important part of "true" multitasking.
I'm really loving the Mac responses here "yes, you have to load things in
the right order or they don't work; no, that doesn't make the Mac OS load
order dependent"; talk about trying to bail water with a sieve!
Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (01/16/91)
es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > Problem is, most tasks DON'T give up control. Mac programs have to be > written to purposely give up control and many are still written badly > enough to not work, MicroSoft being one of the worst culprits. (Larry Rosenstein) at googy.apple.com writes: > Not true. For most applications, there is nothing special you have to > do in order to yield the CPU. It is a normal part of processing user > input. Bzzzzt! Wrong answer, but thank you for playing our game. Pausing for i/o is a separate consideration; the "cooperation" required for cooperative multitasking is built into the OS i/o routines. Waiting for i/o _is_ cooperating. It is the case of a routine that goes CPU bound and doesn't bother to give back to the OS the chance to allow another task to execute that differentiates cooperative from preemptive multitasking. For example, a Mandelbrot generator or Ray Tracer that draws to the screen (potentially for hours) and doesn't have a "hey, OS, you need some time?" at the top of some loop, locks up the machine completely in a cooperative multitasking environment. In a preemptive environment, you have to be malicious, not just careless, to sieze complete control of the machine -- you have to deliberately turn off interrupts and never restore them. So long as you leave interrupts enabled, under preemptive multitasking you don't have to ask the OS if it needs time, it will come and wrest time away from you. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (01/16/91)
burley@geech.ai.mit.edu (Craig Burley) writes: > Anyone care to post whether this kind of scenario works on the Amiga? I.e. > when holding a menu down, or doing other purely user-interface things that > aren't inherently resource intensive (like just holding a mouse button > down without moving the mouse), does true multitasking keep working? > My guess would be yes, it does. peter@sugar.hackercorp.com (Peter da Silva) writes: > Multitasking continues, however that screen is locked (any task doing > output to that screen is deferred) until you release that task. Yes, But be really careful to differentiate "task" from "program"; it is the actual modification of screen pixels that is locked (and probably only if you actually do it through the nice Intuition interfaces; scribbling directly on the bitmaps yourself doesn't look lockable, though you may then be scribbling on the menu rather than the (blitted away?) area "under" it); the rest of the program's tasks go right on executing. I tried the trick of listing /etc/termcap on my terminal emulator, then grabbing a menu on the same screen; the listing stopped being drawn, just as you say, but the characters kept being received through the modem, and the display work stacked up; when I let the menu go, the arrived text was blasted to the screen at the fastfonts inherent maybe 40Kbytes per second rate, rather than the modem's 120 bytes per second rate. > Programs that don't output to that screen (either they have their own > screen or they're smart and spawned a task for display update) aren't > affected. And parts of programs that aren't involved with screen changes keep right on going. From the behavior I saw, I'd guess my emulator was sending text display requests to Intuition as messages, and Intuition was stacking the messages until the menu was released, then doing them all as fast as possible. I'd guess that means I could stack up messages until I ran out of memory. With /etc/termcap and the overhead of a message, even 9 Megabytes may be too little room to hold open that menu "forever". > The only way to stop context switching is to call Forbid() or > Disable() and sit in a busy-wait, or otherwise do something REAL > stupid. Programs that do that don't tend to get good reviews in Amiga > magazines. And get toasted a bit in the c.s.a.* arena, too. ;-) Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/16/91)
In article <91015.180746MBS110@psuvm.psu.edu> MBS110@psuvm.psu.edu writes: >Simple enough. On a multitasking computer, there's no need to distinguish >between applications, "INITs," "desk accessories," the CLI, the "desktop," >and so forth. All of these are just ordinary programs running concurrently. Ok, that sounds neat. You might be amused to find out that Apple is phasing out desk accessories and heading towards the "everything is just a program" philosophy. >If you want a program (any program) to be run every time you boot >the machine, you put its name in the Startup-Sequence -- an ordinary text file >on disk that lists programs that should be automatically run on startup. >I suppose this is the equivalent of an INIT, but you really can't compare >the two. (You could, for example, put DeluxePaint or WordPerfect in the >Startup-Sequence...) > >The advantage is that no special programming tricks are required. >Macintosh desk accessories must be programmed to keep handing control >back to the main application "as often as possible," and INITs require >a lot of special writing, installation, and maintenance. On the Amiga, >whether you're writing a huge application or a menu-bar clock, you don't >need to use different techniques. OK, I think I probably prefer the Amiga way because it is more flexible, but INITs have a couple of advantages. For one thing, only certain kinds of programs are done as INITS and that helps distinguish among programs. For another, INIT code is often embedded in a CDEV which allows INITs to be configured through the control panel via a fairly uniform interface. INITs also need no more tending that your Startup-Sequence. All you need to do to set them up is copy them to your System Folder and reboot. Occasionally you may get a conflict and need either to resequence them or figure out which ones won't work together. I've run as many as 50-60 together without a lot of trouble on a Mac Plus and still be able to run a WP and Telecomm program with passable performance. Awright, back to the Amiga. Suppose you have a bunch of programs set in your Startup-Sequence. What determines priorities and how do you make sure programs get the time they need to do their thing?
mykes@zorch.SF-Bay.ORG (Mike Schwartz) (01/16/91)
In article <11719@goofy.Apple.COM> (Larry Rosenstein) writes: >In article <1991Jan14.221532.4431@cunixf.cc.columbia.edu>, es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: >> >> Problem is, most tasks DON'T give up control. Mac >> programs have to be written to purposely give up control and many >> are still written badly enough to not work, MicroSoft being one >> of the worst culprits. > >Not true. For most applications, there is nothing special you have to >do in order to yield the CPU. It is a normal part of processing user >input. goofy? how appropriate! :):):):):):):)
mykes@zorch.SF-Bay.ORG (Mike Schwartz) (01/16/91)
In article <11721@goofy.Apple.COM> lsr (Larry Rosenstein) writes: >In article <BURLEY.91Jan14110925@geech.ai.mit.edu>, burley@geech.ai.mit.edu (Craig Burley) writes: >> >> Now switch to the Finder or some other app (perhaps even the comm app itself, >> though mine, Microphone II, is smart enough to keep things going despite the >> pulled-down menu -- if it is its own). >> >> Now pull down a menu and hold it down for about five minutes. > >You will always be able to come up with a scenario in which the MultiFinder >model breaks down. But people don't pull down a menu and hold it for 5 >minutes, so MultiFinder works well most of the time. For most people, that's >what counts. Thos f us tht nvr wnt to the evln woodhead schl of spd rding might need 5 seconds to read a menu! It might take even longer to figure out what the menu items mean.
dfrancis@tronsbox.xei.com (Dennis Heffernan) (01/16/91)
In article <1991Jan16.015035.10356@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >Pausing for i/o is a separate consideration; the "cooperation" required >for cooperative multitasking is built into the OS i/o routines. Waiting >for i/o _is_ cooperating. It is the case of a routine that goes CPU >bound and doesn't bother to give back to the OS the chance to allow >another task to execute that differentiates cooperative from preemptive >multitasking. > StuffIt 1.5.1 has a little dialog box that opens when you run it, which slices and hands out the usual "here's who wrote this, it's shareware, pay or die" bologna. You click on it, and it goes away. Fair enough. That is, it would be if the author hadn't decided to bypass the Macintosh Way of Checking Input Events According to Cardinal Toolbox. Instead of calling the proper system routine, he peeked the mouse registers directly. He thus bypassed the normal MultiFinder piggybacks. My aforementioned Mac developer friend once started StuffIt 1.5.1 while downloading some stuff over a network and walked away. When he came back a while later, he discovered that StuffIt had not only stopped HIS machine, but it had hung the network. This was over a DIALOG BOX, people. Pre-emptive Multitasking Is Your Friend. dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 ------------------------------------------------------------------------------ "Using C will definitely cut your life expectancy by 10 years or more." -- Carl Sassenrath, GURU'S GUIDE TO THE COMMODORE AMIGA
pswanson@umvlsi.ecs.umass.edu (Paul Swanson) (01/17/91)
In article <42560@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >In article <1449@umvlsi.ecs.umass.edu> pswanson@umvlsi.ecs.umass.edu (Paul Swanson) writes: > > [bunch of 'is too' 'is not' type arguments deleted] > >Tell me, are there default time slices for programs on the Amiga? Are you >telling me that all Amiga users run their machines stock? Nobody uses >PD/shareware/commercial enhancements? No custom setups? If so, I'm impressed, >but saddened. I'd hoped to play with things (I like tweaking.) Ah Ha! You've fallen into my trap. This thread started out as an argument about who would notice the difference between preemptive and non-preemptive multitasking. I think the point was that a so called average user couldn't tell the difference. The examples I gave attempted to demonstrate that the unsophisticated user could tell the difference. The response to this was that if you substitute this program for that, flip this switch, or set some parameter to a different value then Multifinder works just fine. But, if you are sophisticated enough to figure this stuff out you are also sophisticated enough to appreciate the difference between preemptive and nonpreemptive multitasking. So basically I think EVERYBODY can tell the difference between preemptive and nonpreemptive multitasking. Paul.
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/17/91)
In article <1991Jan16.061816.15522@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: >Thos f us tht nvr wnt to the evln woodhead schl of spd rding might need >5 seconds to read a menu! It might take even longer to figure out what the >menu items mean. Well, if you don't know what the menu items mean, either RTFM, or invoke the menu item and examine the dialog it brings up or the effect it produces. (Are you trying to do serious work without even knowing how to use the program?) You're telling me that THEORETICALLY the design is a problem. I reply that IN PRACTICE, I don't encounter the problem. I've been downloading more than usual and playing games in the foreground just to test some of these objections. I have yet to lose a file and we're talking hourlong downloads.
andy@cbmvax.commodore.com (Andy Finkel) (01/17/91)
In article <42624@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >You're telling me that THEORETICALLY the design is a problem. I reply that >IN PRACTICE, I don't encounter the problem. I've been downloading more than >usual and playing games in the foreground just to test some of these objections. >I have yet to lose a file and we're talking hourlong downloads. OK, here's a practical use: On the Amiga I often stop text from scrolling in the active window by holding onto the right mouse button; this locks the layers for the window, and scrolling stops, and I read the text. When I'm ready, I let up on the button; multitasking continues, even though I'm hanging onto the menu button. Just printing to the current screen stops. (I generally do this on BIX, start going through a conference with a READ CURR TO LAS and pause with the mouse; sure, I could use the keyboard if I wanted) It's not a great example, but its sure a practical one :-) andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "God was able to create the world in only seven days because there was no installed base to consider." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
Larry.Rosenstein@Apple.COM (01/17/91)
In article <1991Jan16.015035.10356@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > > (Larry Rosenstein) at googy.apple.com writes: > > > Not true. For most applications, there is nothing special you have to > > do in order to yield the CPU. It is a normal part of processing user > > input. > > Bzzzzt! Wrong answer, but thank you for playing our game. Have you ever written a Mac application? Most application do not have to do anything special to multitask under MultiFinder. > Pausing for i/o is a separate consideration; the "cooperation" required > for cooperative multitasking is built into the OS i/o routines. Which means it isn't something the programmer has to worry about. > for i/o _is_ cooperating. It is the case of a routine that goes CPU > bound and doesn't bother to give back to the OS the chance to allow > another task to execute that differentiates cooperative from preemptive > multitasking. No argument here. But most applications are user-input bound, not CPU bound. > For example, a Mandelbrot generator or Ray Tracer that draws to the > screen (potentially for hours) and doesn't have a "hey, OS, you need > some time?" at the top of some loop, locks up the machine completely in a This is a case where you have to explicitly yield the CPU. It's an extra burden on the programmers, but it's not especially difficult to do this. I've done this for DBW Render and for the PBMPLUS utilities. Both packages run in the background under MultiFinder.
eachus@aries.mitre.org (Robert I. Eachus) (01/17/91)
In article <42560@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > Tell me, are there default time slices for programs on the Amiga? Yes, but not usually an issue. It is unusual to have two tasks at the same priority doing "number crunching," and care about the time slice. > Are you telling me that all Amiga users run their machines stock? Gawd No!!! This is the ULTIMATE hacker machine, designed as such. > Nobody uses PD/shareware/commercial enhancements? No custom > setups? If so, I'm impressed, but saddened. I'd hoped to play > with things (I like tweaking.) One nice feature of the Amiga culture (which includes a lot of people at Commodore) is that the best replacement software be it PD, shareware or commercial ends up in the next AmigaDOS. (And in cases where you don't think so, stay with the version you have.) In the early days of the Amiga 1000 doing a good job of tuning for your usage pattern could improve throughput by about ten times. A lot of this stuff has found its way into the distribution version of startup.sequence, but there are a lot more tricks you can try. (Especially if you have a 6820 board or any 68030. SetCPU from Dave Haynie can give you a 2-4x throughput improvement by itself! It has options to copy the ROMs into 32-bit FAST memory and turn on the data caches.) Robert I. Eachus Amiga 3000 - The hardware makes it great, the software makes it awesome, and the price will make it ubiquitous. -- Robert I. Eachus When the dictators are ready to make war upon us, they will not wait for an act of war on our part." - Franklin D. Roosevelt
andy@cbmvax.commodore.com (Andy Finkel) (01/18/91)
In article <42644@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >In article <17685@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: >I can see you've leveraged an aspect of the behavior of your OS into a useful >tool, but I don't see how that behavior is somehow better, or more efficent. >Maybe I don't understand the example? You wanted a practical example; that what I gave, something that I actually do that would be broken if our multitasking wasn't preemptive. Yes, I could do something else; I could take my hand off the mouse and use the keyboard, or I could scroll up in my review buffer, but that's not what I want to do...I want to stop the scroll using the mouse to read and/or ponder a line or two; then I want to let scrolling continue. I don't want to fool around with back scroll. I don't want to use the keyboard. As I said, its not a great example, as I could change the way I work. But it does show there are differences between preemptive and non-preemptive that can make a difference, and its hard to make a statement like "No one would want to ..." and make it stick. Someone will always want to "..." andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "God was able to create the world in only seven days because there was no installed base to consider." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
kdarling@hobbes.ncsu.edu (Kevin Darling) (01/18/91)
burley@geech.ai.mit.edu (Craig Burley) writes about multitasking: > Anyone care to post whether this kind of scenario works on the Amiga? I.e. > when holding a menu down, or doing other purely user-interface things that jbickers@templar.actrix.gen.nz (John Bickers) (and others) reply: > If you do something that requires locking the display a task is using > (menus, resizing, moving the window, etc), the task may be stopped > until you release the mouse button (there are different ways of > writing to a display - some care about locked displays, some don't). Perhaps this could/should be changed. It is always abhorent to me to have a supposedly preemptive system have any processes stopped or held due to fairly common (and possibly lengthy) user interactions. Resize/move rubberband lines can be flicked on/off screen during an interrupt, allowing any graphics output to otherwise continue on that screen. I've done a windowing system like this; it works like a charm. Menus are harder, but if programs use device-independent gfx calls (that is, they don't directly diddle screen memory), then this problem goes away also. - kevin <kdarling@catt.ncsu.edu>
mykes@zorch.SF-Bay.ORG (Mike Schwartz) (01/18/91)
In article <42609@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >In article <91015.180746MBS110@psuvm.psu.edu> MBS110@psuvm.psu.edu writes: > >>Simple enough. On a multitasking computer, there's no need to distinguish >>between applications, "INITs," "desk accessories," the CLI, the "desktop," >>and so forth. All of these are just ordinary programs running concurrently. > >Ok, that sounds neat. You might be amused to find out that Apple is phasing >out desk accessories and heading towards the "everything is just a program" > philosophy. > Sounds like apple is retrofitting another feature built in to every Amiga! This is not the first time. If this retrofit is as good as multifinder, the amiga will still work better. >>If you want a program (any program) to be run every time you boot >>the machine, you put its name in the Startup-Sequence -- an ordinary text file >>on disk that lists programs that should be automatically run on startup. >>I suppose this is the equivalent of an INIT, but you really can't compare >>the two. (You could, for example, put DeluxePaint or WordPerfect in the >>Startup-Sequence...) >> >>The advantage is that no special programming tricks are required. >>Macintosh desk accessories must be programmed to keep handing control >>back to the main application "as often as possible," and INITs require >>a lot of special writing, installation, and maintenance. On the Amiga, >>whether you're writing a huge application or a menu-bar clock, you don't >>need to use different techniques. > >OK, I think I probably prefer the Amiga way because it is more flexible, but >INITs have a couple of advantages. For one thing, only certain kinds of >programs are done as INITS and that helps distinguish among programs. For >another, INIT code is often embedded in a CDEV which allows INITs to be >configured through the control panel via a fairly uniform interface. > >INITs also need no more tending that your Startup-Sequence. All you need to do >to set them up is copy them to your System Folder and reboot. Occasionally you >may get a conflict and need either to resequence them or figure out which ones >won't work together. I've run as many as 50-60 together without a lot of >trouble on a Mac Plus and still be able to run a WP and Telecomm program with >passable performance. > >Awright, back to the Amiga. Suppose you have a bunch of programs set in your >Startup-Sequence. What determines priorities and how do you make sure programs >get the time they need to do their thing? There are two ways a program on the Amiga can determine its priority. One is to allow the user to set it and the other is for the software to set it as it thinks it needs to be. When you run a program, it inherits the priority of the CLI that spawned it (in this case, the CLI that is executing the startup-sequence) and you can easily change the CLI's priority before running as many programs as you want then change it again and run some more programs. Also, the Amiga features pre-emptive multitasking. This means that programs running at the same priority get an equal share of the CPU time with the other programs running at the same priority. This even happens when you use a pull down menu in one application (the others still run!). Programs running at high priorities only get the CPU when they need it. Typical programs at any priority spend more time not using the CPU than using it, especially when they are waiting for input. So you can have a very high priority program waiting for input that uses NO cpu time while lower priority programs get all they need. This is typical of a program editor that can change itself to high priority for screen refreshes then change itself back to low priority while it does other things (you want your refreshes to be fast so the machine has a snappy response). A term program can run at high priority and it will use NO cpu time until a byte comes in to the serial port, then it will get ALL the CPU time it needs to process the byte, then it will again use NO CPU time until the next byte comes. By the way, every program on my hard disk is as good as a desk accessory. I can have a million desk accessories ready to use and still use ALL of my Amiga's memory for any other purpose. My Amiga never has just "passable" performance due to the number of programs I have available. I would not call typical Amiga applications INITs, because they relate more closely to the way the Mac lets you automatically open application(s) when you boot. However, I do have programs that I run from my startup-sequence that accelerate the mouse, provide screen blanking, allow me to read and write MS-DOS 720K disks with AmigaDos commands (or from applications' file requestors), allow access to ethernet networks, allow access to UUCP, and a whole lot more. These programs do resemble INITs. I typically run all these inits, plus have a resident assembler, editor, and linker, run DPaint with 10 screens of animation, and still have 2.89 Megs of RAM free. I have not had to quit an application to make more free memory for another application in years. All this is on a 5 Meg machine. Cheers!
bard@jessica.stanford.edu (David Hopper) (01/18/91)
In article <42516@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > >Thanks, but it makes people who otherwise wouldn't be very productive with an >IBM very much so with a Mac. I've been using Macs and helping Mac users since >1984. It is a pretty useful machine. Unfortunately, the same interface that >helps those users also makes it difficult to maxmize the machine's potential. I've been a Mac consultant for two years, so I can't claim to have the same level of expertise as you; but to be honest, and not to be caustic, this is a cheesecake job. Perhaps this is saying a lot, if simplicity is what you need in a computer. But I'll be damned if I consider the Macintosh a *serious* productive computer, in the sense that it doesn't provide a useful *integrated* work environment. It is ideal for people who don't normally use computers, or for those who are entranced by Apple's marketing barrage and cannot make valued comparisons of *all* computer architectures and software design schemes. > >Like I said, just because you don't know how to use the machine doesn't mean >it can't do the job. Who suckered you into buying the Mac? Any computer >user that buys a machine without giving it a workout on the kinds of tasks >that they expect of that machine deserves what they get. I agree. Like, perhaps, a $1000 Macintosh Classic? C'mon; good business, perhaps, but I see it more as highway robbery. That damn thing can't do anything but look good on a desk (and that's subject to opinion). >Well, I think there is a difference between a flame and just a bunch whining. >If the Amiga is the superior machine, it will win without a bunch of >uninformed dopes bad-mouthing a machine they don't know very much about. > >I'm very interested in what the Amiga CAN do and not very much interested in >what some people THINK the Mac can't. Just an extremely informed dope here, making a value judgement on what I KNOW the Mac can't do, that the Amiga can. Not that I don't enjoy my job; I mean, didn't Sun Tzu once say "Know your enemy." ;-) ;-) ;-) Dave Hopper | /// Yesterday, CS. | Academic Info Resources | __ /// Today, Anthropology. | Mac & UNIX Sys-Support bard@jessica. | \\\/// | "Somebody get me a job Stanford.EDU | \XX/ Tomorrow: napping in gutters.| with a computer I LIKE"
bruce@zuhause.MN.ORG (Bruce Albrecht) (01/18/91)
> >Here's a chance for you advocates out there to wax melodic. On the Mac there >is >a type of process called an INIT that multitasks with or without MultiFinder. >I have about 25 of these (I'm running a "lean" (for me) setup) active, >providing >services like screen saving, network mail and file service, a >calendar/reminder program, and zillion minor utilities like pop-up menus, >a menuclock, macros, and keyboard shortcuts. > >How is this stuff done on an Amiga? We start them the way we start any background task from the CLI, using the run command. There's also a Workbench drawer in AmigaDos 2.0 that can be used for those who are CLI-impaired. -- bruce@zuhause.mn.org
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/19/91)
In article <1991Jan18.050529.13101@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: >By the way, every program on my hard disk is as good as a desk accessory. >I can have a million desk accessories ready to use and still use ALL of >my Amiga's memory for any other purpose. My Amiga never has just "passable" >performance due to the number of programs I have available. Well, I was talking about an 8Mhz 68000 machine there. One thing people may not realize is that Desk Accessories on the Mac do not take up processing time unless they've been run. Think of them as a menu of small (generally) programs you can run at any time without worrying about memory fragmentation issues etc. (I know, the Amiga can do this with any program...) I have 60 DAs available and it could be 200 and still not affect the performance of the machine materially. >I typically run all these inits, plus have a resident assembler, editor, >and linker, run DPaint with 10 screens of animation, and still have >2.89 Megs of RAM free. I have not had to quit an application to make more >free memory for another application in years. I wish I could do in my 5 megs what you can do in yours. The Mac has never been the leanest machine in terms of price, memory, or CPU efficiency. Its strength has always been in putting a fairly powerful interface in the hands of people who otherwise probably wouldn't be using computers, or would be using them as "1-2-3 boxes" or "Word boxes". Some people shouldn't be allowed within 10 feet of a CLI.
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/19/91)
In article <1991Jan18.085624.7710@portia.Stanford.EDU> bard@jessica.stanford.edu (David Hopper) writes: >I've been a Mac consultant for two years, so I can't claim to have the same >level of expertise as you; but to be honest, and not to be caustic, this is >a cheesecake job. Perhaps this is saying a lot, if simplicity is what you >need in a computer. But I'll be damned if I consider the Macintosh a >*serious* >productive computer, in the sense that it doesn't provide a useful >*integrated* >work environment. It is ideal for people who don't normally use computers, Could you define this, please? One of the strong points of the Mac is supposed to be its level of inter-application integration. If you think the Mac is all that simple, try playing around with ResEdit for a while. Supporting Macs isn't as tough as say, supporting IBMs or Amigas. However, supporting the typical Mac user CAN be more difficult because that Mac user expects to be able to run more programs than the typical IBM user. I wonder what the profile of the typical Amiga user IS. >or for those who are entranced by Apple's marketing barrage and cannot make >valued comparisons of *all* computer architectures and software design >schemes. You can't just compare architectures and software design and choose the best machine. You also have to consider what software is available for the machine, your current installed base, and even the kinds of computers potential hirees are likely to be familiar with. >I agree. >Like, perhaps, a $1000 Macintosh Classic? C'mon; good business, perhaps, but >I see it more as highway robbery. That damn thing can't do anything but look >good on a desk (and that's subject to opinion). What can't you do on a Classic? Please be specific. (I already know about its lack of color, thanks.) Oh, and that price should be closer to $1300 for the 2 meg RAM, 40 meg HD configuration. >Just an extremely informed dope here, making a value judgement on what I KNOW >the Mac can't do, that the Amiga can. Not that I don't enjoy my job; I mean, >didn't Sun Tzu once say "Know your enemy." ;-) ;-) ;-) The question isn't whether the machine can do what you are used to doing on your machine (do you have the equivalent of ResEdit on the Amiga?), but how suitable the machine is for a broad range of tasks, OR whether it is best suited for a particular set of tasks.
new@ee.udel.edu (Darren New) (01/19/91)
In article <7536@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >That's how the console device supports typeahead without getting output mixed >up with input: when you type in the screen it blocks output until you enter >a whole line. Other programs are not effected. I thought it was kind of >clever, actually. I prefer the method used in CP-V, namely that the input you type ahead does not echo until it is read. Looking at a hardcopy or a screen, you cant tell whether any given character was typed ahead or not. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
nsw@cbnewsm.att.com (Neil Weinstock) (01/19/91)
In article <7523@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <BURLEY.91Jan14110925@geech.ai.mit.edu> burley@geech.ai.mit.edu (Craig Burley) writes: >> Anyone care to post whether this kind of scenario works on the Amiga? I.e. >> when holding a menu down, or doing other purely user-interface things that >> aren't inherently resource intensive (like just holding a mouse button >> down without moving the mouse), does true multitasking keep working? >> My guess would be yes, it does. > >Multitasking continues, however that screen is locked (any task doing output >to that screen is deferred) until you release that task. Programs that don't >output to that screen (either they have their own screen or they're smart and >spawned a task for display update) aren't affected. Then again, for specialized applications, you can use dual-playfield mode, and the menus can work at the same time as the rest of the screen. My Asteroids program (which I really oughtta get in shape for distribution one of these days) uses the top playfield for Intuition, and does the animation on the bottom. When you pull up a menu, the animation continues without missing a beat, right underneath the menus. The background of the menus is also transparent, so you see the rocks floating around behind the menus. It's a great multitasking example, apart from being flat-out cool. - Neil --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-- Neil Weinstock @ AT&T Bell Labs // What was sliced bread att!edsel!nsw or nsw@edsel.att.com \X/ the greatest thing since?
peter@sugar.hackercorp.com (Peter da Silva) (01/19/91)
In article <42731@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > Well, I was talking about an 8Mhz 68000 machine there. So are we. > One thing people may not > realize is that Desk Accessories on the Mac do not take up processing time > unless they've been run. And Amiga programs don't take up any processing time unles they're actively doing something. A copy of "Emacs" sitting in a background window takes up zero CPU time. Even when it's got a window open it doesn't take up CPU time until you start using it. > I have 60 DAs available and it could be 200 and still not affect the > performance of the machine materially. Well, except for the RAM they take up. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
skank@iastate.edu (Skank George L) (01/19/91)
In article <42516@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > >Unfortunately, Mac developers (at least the ones doing major apps) are >pretty sloppy about code size and applications can't >request more memory (this is a simplification) from the OS, so they take up >fixed amounts of space in MultiFinder partitions. Whew!! For a moment, I thought Amiga developers were the only ones that wrote sloppy code. -- George L. Skank | skank@iastate.edu |Fast cars, fast women, fast computers... Senior, Electrical Engineering |(not necessarily in that order)
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/19/91)
In article <7540@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Well, except for the RAM they take up. DAs take up very little RAM until they are invoked. I _think_ they are are loaded into the System heap, which gets expanded dynamically. I don't know the technical limitations on DAs are, but I have DAs for all the basics: text editing, spreadsheet, term, and simple database. There's even a DA to run HyperCard stacks. It may be a kludgey OS, but it seems to work.
mykes@zorch.SF-Bay.ORG (Mike Schwartz) (01/19/91)
In article <42731@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >In article <1991Jan18.050529.13101@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: > >>By the way, every program on my hard disk is as good as a desk accessory. >>I can have a million desk accessories ready to use and still use ALL of >>my Amiga's memory for any other purpose. My Amiga never has just "passable" >>performance due to the number of programs I have available. > >Well, I was talking about an 8Mhz 68000 machine there. One thing people may not >realize is that Desk Accessories on the Mac do not take up processing time >unless they've been run. Think of them as a menu of small (generally) programs >you can run at any time without worrying about memory fragmentation issues etc. >(I know, the Amiga can do this with any program...) I have 60 DAs available and >it could be 200 and still not affect the performance of the machine materially. > Do Desk Accessories take up RAM or not? You can fit 200 desk accessories in memory at the same time? (Just a question ...). Also, programs that reside entirely on disk require NO cpu time either. I could also point out that the standard Amiga is 7.14 MHz and is slower than your 8MHz machine. However, the copper and blitter give it an effective rate of about 10MHz while the Mac has wait states that reduce it's 8MHz to effectively about 5, but even as it may be, the 7.14 MHz machine has more than passable performance all the time. >>I typically run all these inits, plus have a resident assembler, editor, >>and linker, run DPaint with 10 screens of animation, and still have >>2.89 Megs of RAM free. I have not had to quit an application to make more >>free memory for another application in years. > >I wish I could do in my 5 megs what you can do in yours. The Mac has never been >the leanest machine in terms of price, memory, or CPU efficiency. Its strength >has always been in putting a fairly powerful interface in the hands of people >who otherwise probably wouldn't be using computers, or would be using them as >"1-2-3 boxes" or "Word boxes". Some people shouldn't be allowed within 10 feet > of a CLI. Unfortunately, there will be 80Million CLI based PC machines by 1992, and ALL those people seem to be able to deal with the CLI. The Amiga is a natural machine for all those people familiar with MS-DOS because the CLI environment is similar enough on the Amiga and because you can run more than one at a time. I would like to think, however, that the Amiga provides a little more than the PC does in the way of user interface (WIMP), and a lot more in terms of standard configuration (copper, blitter, 4096 colors, mouse, multitasking, (and a list that goes on and on and on and on... ). The only thing that is keeping the Amiga from being the best 1-2-3 or Word box is Lotus and Microsoft. You can also blame CBM... We both agree that the Mac would be nicer if you could do more in less memory. We also both agree that the Mac has a superior user interface, even if it requires significant effort to program and is near impossible to port from.
es1@cunixb.cc.columbia.edu (Ethan Solomita) (01/19/91)
In article <1991Jan18.231330.16290@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > >>>In article <11719@goofy.Apple.COM> (Larry Rosenstein) writes: >>>>Not true. For most applications, there is nothing special you have to >>>>do in order to yield the CPU. It is a normal part of processing user >>>>input. >>> > > >> Larry, we already know that MultiFinder can do Task >>Switching. If it is waiting for input, WHAT'S THE POINT?? It >>isn't doing anything. ergo, that doesn't help multitasking. While >>the spreadsheet is calculating or the ray-tracer is tracing, that >>is when "true-multitasking" is tested. > > Who says that a spreadsheet recalculating or ray-tracer shouldn't be >checking for user input? > This is MULTIFINDER we're talking about! multi-threading? I doubt it. It would be relatively easy on Amiga, but no one that I know of does it on either platform. >-- >------------------------------------------------------------------------------ >Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu >Fame, fame, fame... What's it good for? Ab-so-lute-ly nothing -- Ethan "What a waste it is to lose one's mind, or not to have a mind... How true that is." -- Dan Quayle, of course. Our beloved Vice President. It's just too easy!
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/20/91)
In article <1991Jan19.035418.15192@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: >Do Desk Accessories take up RAM or not? You can fit 200 desk accessories in >memory at the same time? (Just a question ...). Also, programs that reside As I understand them, desk accessaries reside primarily on disk with a pointer to the code on disk. The desk accessory is invoked via a menu. >entirely on disk require NO cpu time either. I could also point out that >the standard Amiga is 7.14 MHz and is slower than your 8MHz machine. However, >the copper and blitter give it an effective rate of about 10MHz while the >Mac has wait states that reduce it's 8MHz to effectively about 5, but even >as it may be, the 7.14 MHz machine has more than passable performance all >the time. First, the "passable" performance I was talking about was on a 2.5 meg Mac Plus running 50-60 INITs with 2-3 applications under MultiFinder. Among those INITs were a network mail server, a peer to peer file server, online spelling checker, and a bunch of other stuff. Every machine I've ever used had some sort of performance limits, and I like to see how far I can push it before I have to "dumb it down". I find it hard to believe that you can't load the Amiga up in the same way. (Rhetorical, I KNOW it could be done.) >Unfortunately, there will be 80Million CLI based PC machines by 1992, and >ALL those people seem to be able to deal with the CLI. The Amiga is a WRONG. Most of those people know how to type "123", "dir a:", and "copy a:filename.ext b:", but ALL 80 million do NOT know how to use a CLI. Add to that the fact that, on average, they run fewer programs on their CLI-only machine than the comparable GUI user does. >natural machine for all those people familiar with MS-DOS because the CLI >environment is similar enough on the Amiga and because you can run more than Uh, the CLI on the Amiga may be similar to DOS AFTER you have mastered the Amiga CLI, but when a friend of mine started setting up his 500 we had a LOT of problems trying to use our DOS experience. >one at a time. I would like to think, however, that the Amiga provides a >little more than the PC does in the way of user interface (WIMP), and a lot >more in terms of standard configuration (copper, blitter, 4096 colors, mouse, >multitasking, (and a list that goes on and on and on and on... ). With 16 Mhz 286s with 256 color VGA and Windows machines running around $1500, some of those advantages are starting to blur. >We both agree that the Mac would be nicer if you could do more in less >memory. We also both agree that the Mac has a superior user interface, >even if it requires significant effort to program and is near impossible >to port from. I'm no "real" programmer, but I've written BASIC programs for both the IBM and the Mac. The Mac programs are a little more difficult to work with because you have to add the interface, but if I can do it, I suspect any programmer whose techniques haven't petrified can learn to adapt. I set up one of the BASIC utilities I wrote to background and it took no extra code. This may be a result of how the BASIC compiler handles the code, but it can be done, and easily. (Of course, I STILL don't know why it executes faster in the background than in the foreground.) Porting is just a matter of what your development enviroment supports. If you had one that shared a common library of calls with the mac end, you could port just fine. Ask Microsoft how they do it.
mykes@zorch.SF-Bay.ORG (Mike Schwartz) (01/20/91)
In article <42792@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >In article <1991Jan19.035418.15192@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: > >>Do Desk Accessories take up RAM or not? You can fit 200 desk accessories in >>memory at the same time? (Just a question ...). Also, programs that reside > >As I understand them, desk accessaries reside primarily on disk with a pointer >to the code on disk. The desk accessory is invoked via a menu. > >>entirely on disk require NO cpu time either. I could also point out that >>the standard Amiga is 7.14 MHz and is slower than your 8MHz machine. However, >>the copper and blitter give it an effective rate of about 10MHz while the >>Mac has wait states that reduce it's 8MHz to effectively about 5, but even >>as it may be, the 7.14 MHz machine has more than passable performance all >>the time. > >First, the "passable" performance I was talking about was on a 2.5 meg Mac Plus >running 50-60 INITs with 2-3 applications under MultiFinder. Among those INITs >were a network mail server, a peer to peer file server, online spelling checker, >and a bunch of other stuff. > I think you might be able to run 2 or 3 applications on a 2.5 Meg Amiga and still have lots of RAM left and still have zero performance problem. As you add programs to the Amiga, you just use up the RAM they need. Applicatons that are waiting for input take ZERO cpu time, so there is NO performance decrease. Naturally, if you start 2 ray tracing programs at the same time, they will take just a tad longer than if you ran one and let it finish and then ran the other, but the system does exactly what you expect. The only thing that pushes the Amiga, performance-wise, is trying to do a ton of 3-d type stuff in real time, just something that NO 68000 could do no matter how well it was programmed. >Every machine I've ever used had some sort of performance limits, and I like to >see how far I can push it before I have to "dumb it down". I find it hard to >believe that you can't load the Amiga up in the same way. (Rhetorical, I KNOW >it could be done.) > >>Unfortunately, there will be 80Million CLI based PC machines by 1992, and >>ALL those people seem to be able to deal with the CLI. The Amiga is a > >WRONG. Most of those people know how to type "123", "dir a:", and "copy >a:filename.ext b:", but ALL 80 million do NOT know how to use a CLI. Add to >that the fact that, on average, they run fewer programs on their CLI-only >machine than the comparable GUI user does. > I wish all you had to do was type 1-2-3 on the Amiga, but there is no such program. Blame it on Lotus. Blame it on CBM. You can do "dir a:" on the Amiga, and almost any other MS-DOS command (read that MS-DOS command, not invocation for an Application). Anybody who wishes that MS-DOS had MORE RAM usable, or multitasking, or whatever, should graduate to the Amiga (this is .advocacy...). And no matter how you slice it, 80 Million is still 1/3 of the US population and is still 10x the number of Macs and Amigas combined... Too bad we are the only enlightened ones (SARCASM intened here). But all those unenlightened do productively use those machines, or they would stop selling. >>natural machine for all those people familiar with MS-DOS because the CLI >>environment is similar enough on the Amiga and because you can run more than > >Uh, the CLI on the Amiga may be similar to DOS AFTER you have mastered the >Amiga CLI, but when a friend of mine started setting up his 500 we had a LOT >o f problems trying to use our DOS experience. > Has either of you ever set up a DOS machine? >>one at a time. I would like to think, however, that the Amiga provides a >>little more than the PC does in the way of user interface (WIMP), and a lot >>more in terms of standard configuration (copper, blitter, 4096 colors, mouse, >>multitasking, (and a list that goes on and on and on and on... ). > >With 16 Mhz 286s with 256 color VGA and Windows machines running around $1500, >some of those advantages are starting to blur. > A more realistic way of phrasing this is that the disadvantages of the PC are starting to blur. Remember, the features of the Amiga come STOCK with EVERY machine sold. You do not have to spend an extra dime on any one of them. Those who bought STOCK PCs a year ago or more have had to spend extra money to get similar, if not as powerful features. I gave up on the PC a long time ago when I realized how medicore it would always be (640K used to be enough RAM). I sure wish I could put 64MB of RAM on my AT&T 6300 like I can on my Amiga. Don't get me wrong, what they have done with the PC is impressive, because it should have died a long time ago, but somehow they have always managed to breath new life into it (faster CPUs, graphics, mice, WIMP interfaces). But if you are a software developer for the PC, you have to write lots of software just to support the different mice, video adapters, sound boards, operating system environments, etc. Then you get to work on what the application does. One last point, with VGA, you get 256 colors, and with HAM you get 4096. AT THE SAME TIME. And a 16MHz 286 is still running programs written for an 8-bit 8088 99% of the time. I hardly call it an advantage. If you want to compare the best of both worlds, compare a 25MHz 68040 with a 25MHz 486 and you will find that the 486 is half as powerful. >>We both agree that the Mac would be nicer if you could do more in less >>memory. We also both agree that the Mac has a superior user interface, >>even if it requires significant effort to program and is near impossible >>to port from. > >I'm no "real" programmer, but I've written BASIC programs for both the IBM and >the Mac. The Mac programs are a little more difficult to work with because you >have to add the interface, but if I can do it, I suspect any programmer whose >techniques haven't petrified can learn to adapt. I set up one of the BASIC >utilities I wrote to background and it took no extra code. This may be a >result of how the BASIC compiler handles the code, but it can be done, and >easily. (Of course, I STILL don't know why it executes faster in the >background than in the foreground.) > >Porting is just a matter of what your development enviroment supports. If you >had one that shared a common library of calls with the mac end, you could port >just fine. Ask Microsoft how they do it. Microsoft is a multibillion dollar company. They can put a large team of engineers on each version. They do it with hard work and lots of programmer hours. Given those resources, it is easy to port. But if you are not as wealthy, it is much more painful. Learning to Adapt to the Mac is a 3 year learning curve for even the best of programmers (to become fully competant at the entire set of OS calls). This does petfrify me. On the other hand, the Amiga is quite easy to port to from the PC or Unix or the ST (in 'C'). I think you underestimate how difficult it is to support a library of calls with the Mac end. I have ported from the Mac to the Amiga and even though the CPUs are both 68000, you either have to rewrite significant parts of the MAC OS to run on the Amiga, or you have to rewrite the application from scratch. Either choice is a big loss.
peter@sugar.hackercorp.com (Peter da Silva) (01/20/91)
In article <1991Jan18.231330.16290@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > Often, when a spreadsheet is calculating a huge file, or running a > macro, you want to move around and see other parts of the spreadsheet, > Or given a ray-tracer. I have (on occasion) ray-traced 1024 x 1024 > pictures - but I only have a 640 x 480 monitor. So I often need to > move around (i.e. scroll-bars, i.e. checking for user input) On the Amiga you'd do that by splitting the program into a compute engine and a user interface task. The compute engine runs at full speed without having any code in the main loop to check for user interaction, and the user interface task just sits there waiting for input taking up no CPU time until you need it. Amiga... working smarter means working faster. > Does this slow the program down? > Yes On the Mac it does. On the Amiga it doesn't. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/20/91)
In article <42792@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > Every machine I've ever used had some sort of performance limits, and I like > to see how far I can push it before I have to "dumb it down". I find it hard > to believe that you can't load the Amiga up in the same way. Sure you can, but it takes a lot more work because you don't hit the limits until you run out of RAM or CPU, instead of running out of reserved chunks of RAM and because you have too many programs all spinning on the event loop. My 3000 has 1.5 MEG, and I haven't run out yet except for when I tried to run AmigaVision: which came free with the machine and given its minimum requirements of 3 MEG (!) was worth every cent. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
davewt@NCoast.ORG (David Wright) (01/21/91)
In article <1991Jan19.035418.15192@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: >Unfortunately, there will be 80Million CLI based PC machines by 1992, and >ALL those people seem to be able to deal with the CLI. The Amiga is a But many of the PC's out there are not used by people who us the DOS command line, but stay only in a menuing system or program selector like Uniplex, the DOS 4.0 Shell, etc. And I have seen MANY IBM's that were set up to load 1-2-3 at boot time, and if you tried to use the "Quit" option just executed 1-2-3 again so the user couldn't get to the command line (without knowing what they were doing). You have to remember MOST of the PC compat machines sold for the first half of that type of machines life were sold for use in business, not home, and I would bet that that is STILL the majority of sales or of sales related to people buying for use at home what they have at work so that they can work at home. >We both agree that the Mac would be nicer if you could do more in less >memory. We also both agree that the Mac has a superior user interface, >even if it requires significant effort to program and is near impossible >to port from. I have to disagree there. I haven't seen anyting that the Mac has in it's UI that isn't in AmigaDOS 2.0, or couldn't be put in there by a very simple utility. Doing so would NOT be a "hack" but would simply be adding a feature to the UI without forcing people to have it all the time. I know I HATE the Mac window open/close functions, with there annoying growing/shrinking boxes. When I click a window to open close it, it should close ASAP. Under 2.0 you can have all kinds of nice utilities that use the "Commodities Exchange" to do things like blank the screen or accellerate the mouse, and not run into any problems utilities fighting amongst themselves. And in fact, there are MANY features of AmigaDOS 2.0 that the Mac UI lacks. Dave
lron@easy.hiam (Dwight Hubbard) (01/21/91)
In article <1991Jan21.055854.14130@rice.edu>, Shawn Joel Dube writes: > Seriously, I think cooperative is better. Take the following for example: > Two task are running. One is waiting on a keypress (via OS subroutine) > and the other is doing some serious number-crunching. With the Amiga, valuable > time is being spent doing nothing (waiting for a keypress). With co-op > multitasking, almost all of the cpu time is spent with the number cruncher. Ahh, the keyboard on the Amiga is interupt driven and NO time will be spent waiting for a keypress. The task waiting for the keypress will be WAITing until the OS receives the keypress and puts it back on the READY que. Since the task is waiting it gets no CPU until a key is pressed and correct me if I'm wrong but I believe the Mac does poll the keyboard so some CPU time is wasted checking for keypresses even if none have arrived. CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD? 3 Dwight Hubbard 3 USENET : uunet!easy!lron 3 3 Kaneohe, Hawaii 3 GT-Power: 029/004 (lron) 3 3 3 CFR : 31:910/101 (Dwight Hubbard) 3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
rjc@geech.ai.mit.edu (Ray Cromwell) (01/21/91)
In article <1991Jan21.004720.25985@ncsuvx.ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes: >>> [Mac example: scrolling around while raytracing.] > >So the speed diff is only related to the (Mac GetEvent delay x number of >times) it's called; versus the (Amiga tick routine delay x number of times) >it's done. Unless we know those timings, speed claims are meaningless. >Perhaps there's a better example? - kevin <kdarling@catt.ncsu.edu> A better example of Preemptive vs cooperative multitasking may be in the continuity of preemptive multitasking. For equal priority tasks on the Amiga using all of their time-slice, tasks will run at the same speed. Consider this preemptive cycle chart. *=Cycle Amiga Time ---> Task A |******** ******** ******** ********> Task B | ******** ******** ******** > Mac Task A |***** ** ****** ************* ** ***> Task B | *************** ***** * ** ** > Mac multitasking cycles will be highly irregular in a heavily loaded system. I suspect that loading a Mac up with time consuming tasks will make the system very jerky, while the Amiga will only slow down. (assuming no high priority tasks block out lower tasks, or something blocks the display for long periods of time.) In my own opinion cooperative multitasking is not multitasking, simply because its not very transparent. How far do you draw the line in defining multitasking? Can Commodore 64's considered to be multitasking because you can put music, and other programs in the IRQ interupt? Can I consider a computer to be multitasking, if all software on the system is written using co-routines to call other software programs? Where is the line drawn? I consider the line to be put at preemptive. Why? Well because I'm considering a task to be an entity which should be allowed to run without voluntarily giving up its control. Consider a benchmark. Benchmarks on the Mac vs Amiga may be unfair, because Mac benchmarks can take all the CPU for its test, while Amiga benchmarks actually test the system's peformance as a whole. I also don't consider the Mac to be multitasking since it hasn't been multitasking from the beginning. Can Mac programs talk to each other? send signals, semaphores? Can they share files, disc resources? Can the Mac update screen windows that are behind other windows without bringing them to front? The Amiga's OS was designed with multitasking from the start. It contains all the facilities to support full blown multitasking and sharing of machine resources. Some of the things that make life on the Amiga easier are Devices, Libraries, and Handlers (all sharable.) On the Amiga, I can 'mount MSH:' and presto, my drive now supports MS-DOS which can be used with ALL programs. I can also MOUNT NET: and use external Amiga's devices as if they were my own (yea, yea, AppleTalk can do this too). I dunno, I guess I'm biased. I've used IBMs,STs, C64/128, Vic20, Trs-80, Cocos, Macs, and the Amiga is the funnest and best development environment I've used.
jsd@wahoo.rice.edu (Shawn Joel Dube) (01/21/91)
In article <12880@life.ai.mit.edu>, rjc@geech.ai.mit.edu (Ray Cromwell) writes: |> |> *=Cycle |> |> Amiga Time ---> |> Task A |******** ******** ******** ********> |> Task B | ******** ******** ******** > |> |> Mac |> Task A |***** ** ****** ************* ** ***> |> Task B | *************** ***** * ** ** > |> Nice chart. |> In my own opinion cooperative multitasking is not multitasking, simply |> because its not very transparent. The multi-tasking on our school's Sun Sparcs is sometimes noticible so does that mean they don't have multitasking? :) Seriously, I think cooperative is better. Take the following for example: Two task are running. One is waiting on a keypress (via OS subroutine) and the other is doing some serious number-crunching. With the Amiga, valuable time is being spent doing nothing (waiting for a keypress). With co-op multitasking, almost all of the cpu time is spent with the number cruncher. Yes, I agree it would make the system somewhat unstable but I don't consider this a problem except when playing games or doing animation. |> Can Mac programs talk to each other? send signals, semaphores? If programmed to do so, yes. I believe in the next release of the Mac OS, the ability to have something like Window's Dynamic Data Link will exist that the Amiga (correct if I'm wrong) doesn't have. |> Can they share files, disc resources? I'll have to pass on that one. |> Can the Mac update screen windows that are |> behind other windows without bringing them to front? Yes. -- rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr r ___ _ r r /__ | \ N U K E I R A Q ! ! ! r r ___/hawn |__\ube ----------------------- r r jsd@owlnet.rice.edu r rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
pcooper@eecs.wsu.edu (Phil Cooper - CS495) (01/21/91)
In article <1991Jan21.055854.14130@rice.edu> jsd@wahoo.rice.edu (Shawn Joel Dube) writes: >In article <12880@life.ai.mit.edu>, rjc@geech.ai.mit.edu (Ray Cromwell) writes: >|> >|> *=Cycle >|> >|> Amiga Time ---> >|> Task A |******** ******** ******** ********> >|> Task B | ******** ******** ******** > >|> >|> Mac >|> Task A |***** ** ****** ************* ** ***> >|> Task B | *************** ***** * ** ** > >|> > >Nice chart. > >|> In my own opinion cooperative multitasking is not multitasking, simply >|> because its not very transparent. > >Seriously, I think cooperative is better. Take the following for example: >Two task are running. One is waiting on a keypress (via OS subroutine) >and the other is doing some serious number-crunching. With the Amiga, valuable >time is being spent doing nothing (waiting for a keypress). Of course, this is just wrong... If one task is waiting on a key press, no CPU time is consumed by it. If the program is written correctly (without a polling loop or some such nonsense), it merely waits. When the key is pressed, the task is signalled and it continues. So, as you can see, no time is being wasted. Also, please check your facts before posting trash like this. It really angers me (and others) when misinformation is spread under the pretense of truth. Have a nice day... Phil Cooper
farren@well.sf.ca.us (Mike Farren) (01/21/91)
awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >As I understand them, desk accessaries reside primarily on disk with a pointer >to the code on disk. The desk accessory is invoked via a menu. You do not understand them. Desk accessories become part of the system file, unless you are running a utility like "Suitcase". They absolutely take up RAM. >With 16 Mhz 286s with 256 color VGA and Windows machines running around $1500, >some of those advantages are starting to blur. Nope. They're getting clearer, as you find that you STILL can't get the capability of a $500 Amiga 500 on anything short of a $1500 '386 machine, and you can't get some of them even then. >Porting is just a matter of what your development enviroment supports. Get a life. You don't understand porting at ALL. A common library of calls does NOTHING for you if you don't have the OS underneath those calls. How, for example, would you propose to simulate CreateProc() on a Mac? Or, for that matter, GetResource() on an Amiga? You can't. Sure, you can move BASIC programs back and forth, mostly. But BASIC is very far from being generally useful, and NEVER the language of choice for professional work. -- Mike Farren farren@well.sf.ca.us
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/22/91)
In article <22780@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: >awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >>As I understand them, desk accessaries reside primarily on disk with a pointer >>to the code on disk. The desk accessory is invoked via a menu. > >You do not understand them. Desk accessories become part of the system >file, unless you are running a utility like "Suitcase". They absolutely >take up RAM. I don't think you understand them either. Just because a resource (in this case a DA) is loaded into the System file does NOT mean that it is loaded into RAM. That is the whole idea behind using resources. They are loaded as necessary, and the memory is released when the resource is not needed. (This is an oversimplification of course.) One of the annoying things about these discussions is that advantages and disadvantages of the various systems are exaggerated. Just because the Mac doesn't have Amiga memory management doesn't mean that it has none at all. >>With 16 Mhz 286s with 256 color VGA and Windows machines running around $1500, >>some of those advantages are starting to blur. > >Nope. They're getting clearer, as you find that you STILL can't get the >capability of a $500 Amiga 500 on anything short of a $1500 '386 machine, >and you can't get some of them even then. Who ever said that computer manufacturers had to compete on a model for model basis? Everybody and their dog has already agreed that the 500 is one of the best bang/$ computer available. >>Porting is just a matter of what your development enviroment supports. > >Get a life. You don't understand porting at ALL. A common library of >calls does NOTHING for you if you don't have the OS underneath those >calls. How, for example, would you propose to simulate CreateProc() on >a Mac? Or, for that matter, GetResource() on an Amiga? You can't. As I understand porting, there are very few cases in which SOME of the code does not have to be rewritten. As usual in these discussions, some people can't control themselves enough to omit certain kinds of comments. I never said porting was a simple matter of recompiling the source on the new machine. >Sure, you can move BASIC programs back and forth, mostly. But BASIC >is very far from being generally useful, and NEVER the language of >choice for professional work. I guess I wasn't clear in pointing out that I knew BASIC wasn't a great example. I suppose if you are careful with your definition of professional, BASIC is NEVER the language of choice. Maybe you should advise Microsoft to stop selling their high-end BASIC development systems.
jsd@boreal.rice.edu (Shawn Joel Dube) (01/22/91)
In article <1991Jan21.101849.13078@eecs.wsu.edu>, pcooper@eecs.wsu.edu (Phil Cooper - CS495) writes: |> >|> |> >|> *=Cycle |> >|> |> >|> Amiga Time ---> |> >|> Task A |******** ******** ******** ********> |> >|> Task B | ******** ******** ******** > |> >|> |> >|> Mac |> >|> Task A |***** ** ****** ************* ** ***> |> >|> Task B | *************** ***** * ** ** > |> >|> |> > |> >Nice chart. |> > |> >|> In my own opinion cooperative multitasking is not multitasking, simply |> >|> because its not very transparent. |> > |> >Seriously, I think cooperative is better. Take the following for example: |> >Two task are running. One is waiting on a keypress (via OS subroutine) |> >and the other is doing some serious number-crunching. With the Amiga, valuable |> >time is being spent doing nothing (waiting for a keypress). |> |> Of course, this is just wrong... If one task is waiting on a key press, |> no CPU time is consumed by it. If the program is written correctly (without |> a polling loop or some such nonsense), it merely waits. When the key is |> pressed, the task is signalled and it continues. So, as you can see, no time |> is being wasted. Also, please check your facts before posting trash like this. |> It really angers me (and others) when misinformation is spread under the |> pretense of truth. Assuming the chart above is correct, time is allocated to each process equally. Any idiot can see that Task A gets just as much time as Task B, even if Task A is simply waiting for a keypress. I didn't make the chart, so if it's wrong, don't blame me for spreading false information. Blame the person who made the chart. |> |> Have a nice day... |> Phil Cooper -- rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr r ___ _ r r /__ | \ N U K E I R A Q ! ! ! r r ___/hawn |__\ube ----------------------- r r jsd@owlnet.rice.edu r rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
doubt@spotted.rice.edu (Douglas Benjamin Triggs) (01/22/91)
In article <1991Jan21.055854.14130@rice.edu>, jsd@wahoo.rice.edu (Shawn Joel Dube) writes: |> |> Amiga Time ---> |> |> Task A |******** ******** ******** ********> |> |> Task B | ******** ******** ******** > |> |> |> |> Mac |> |> Task A |***** ** ****** ************* ** ***> |> |> Task B | *************** ***** * ** ** > |> |> |> Seriously, I think cooperative is better. Take the following for example: |> Two task are running. One is waiting on a keypress (via OS subroutine) |> and the other is doing some serious number-crunching. With the Amiga, |> valuable time is being spent doing nothing (waiting for a keypress). With |> co-op multitasking, almost all of the cpu time is spent with the number |> cruncher. No, a program running under AmigaOS would not waste any time doing nothing (waiting for that keypress). It would skip that task and do the others, unless the programmer is a complete idiot (which, alas, some seem to be). A more accurate graph would be: Amiga Time ---> Task A |**** ** **** ****> Task B | **** **** **** **** **** **** > Task C | **** **** **** **** **** > ^ point A ^ point B (Where task A is waiting for a keypress between points A and B.) The operating system only runs tasks which are on the "ready" list, not ones that are waiting for an external event... |> rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr |> r ___ _ r |> r /__ | \ N U K E I R A Q ! ! ! r |> r ___/hawn |__\ube ----------------------- r |> r jsd@owlnet.rice.edu r |> rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr Doubtfully yours, --my name here-- --- doubt@owlnet.rice.edu --- GM # 8400000E _ _ doubt //// o MacIntosh, adj., idiotic, braindead, terminally __ /| _ _ //// stupid. Usage: "That manual is 'macintosh'" \'o.O' \\\X/// see also: useless; overpriced; ripoff =(___)= \XXX/ o Lotus, v., synonym for "sucks." Usage: "Lotus U (sucks)." see also: federal juristiction invol- "O.A.M.I.P." ving CD's, state borders, and immoral purposes Oop! Ack!
jsd@boreal.rice.edu (Shawn Joel Dube) (01/22/91)
In article <1991Jan21.205623.3867@rice.edu>, doubt@spotted.rice.edu (Douglas Benjamin Triggs) writes: |> In article <1991Jan21.055854.14130@rice.edu>, jsd@wahoo.rice.edu (Shawn Joel |> Dube) writes: |> |> |> |> Amiga Time ---> |> |> |> Task A |******** ******** ******** ********> |> |> |> Task B | ******** ******** ******** > |> |> |> |> |> |> Mac |> |> |> Task A |***** ** ****** ************* ** ***> |> |> |> Task B | *************** ***** * ** ** > |> |> |> |> |> No, a program running under AmigaOS would not waste any time doing nothing |> (waiting for that keypress). It would skip that task and do the others, |> unless the programmer is a complete idiot (which, alas, some seem to be). |> A more accurate graph would be: |> |> Amiga Time ---> |> Task A |**** ** **** ****> |> Task B | **** **** **** **** **** **** > |> Task C | **** **** **** **** **** > |> ^ point A ^ point B |> |> (Where task A is waiting for a keypress between points A and B.) |> Now compare Doug's chart to the one above. Which does it most look like? I would say that it looks mostly like the Mac's becuase each task is not getting eqaul CPU time. |> |> Doubtfully yours, |> --my name here-- |> |> --- doubt@owlnet.rice.edu --- GM # 8400000E |> _ _ |> doubt //// o MacIntosh, adj., idiotic, braindead, terminally __ /| |> _ _ //// stupid. Usage: "That manual is 'macintosh'" \'o.O' |> \\\X/// see also: useless; overpriced; ripoff =(___)= |> \XXX/ o Lotus, v., synonym for "sucks." Usage: "Lotus U |> (sucks)." see also: federal juristiction invol- |> "O.A.M.I.P." ving CD's, state borders, and immoral purposes Oop! Ack! -- rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr r ___ _ r r /__ | \ N U K E I R A Q ! ! ! r r ___/hawn |__\ube ----------------------- r r jsd@owlnet.rice.edu r rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
davewt@NCoast.ORG (David Wright) (01/22/91)
In article <1991Jan21.055854.14130@rice.edu> jsd@wahoo.rice.edu (Shawn Joel Dube) writes: > >Seriously, I think cooperative is better. Take the following for example: >Two task are running. One is waiting on a keypress (via OS subroutine) >and the other is doing some serious number-crunching. With the Amiga, valuable >time is being spent doing nothing (waiting for a keypress). With co-op >multitasking, almost all of the cpu time is spent with the number cruncher. You obviously don't know anything about the Amiga. When any task is waiting for the keyboard, or the mouse, or anything else, it uses NO time. It is waiting for a signal to occur, and until one does, and the task scheduler decides the signal needs to goto that task, that process takes ZERO time. So in fact, the number cruncher on the Mac would get LESS time, as it has to execute calls to see if other tasks need to run instead of just doing it's number crunching, and letting the OS switch tasks when the crunchers time is up (which is at a USER determined time, NOT just because the program called a function whose only purpose is to task switch, as long as there is another task to run, whether the user wanted it to run or not). >If programmed to do so, yes. I believe in the next release of the Mac OS, >the ability to have something like Window's Dynamic Data Link will exist >that the Amiga (correct if I'm wrong) doesn't have. You are wrong. An Amiga program can be notified any time just about any object is changed (a file, a directory, a window, etc.). For example, you can drag an icon into the icon editor's window while the program is running and the icon editor will know to edit that icon. Dave
bruce@zuhause.MN.ORG (Bruce Albrecht) (01/22/91)
>In article <42609@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >In article <91015.180746MBS110@psuvm.psu.edu> MBS110@psuvm.psu.edu writes: >Awright, back to the Amiga. Suppose you have a bunch of programs set in your >Startup-Sequence. What determines priorities and how do you make sure programs >get the time they need to do their thing? You set the priority of the spawning task to the priority you want the background task to run at, asynchronously start the background task with RUN, and set your priority for the next task. There's at least one PD utility that does all that for you. You may have some programs never get executed, if there's enough stuff running at a higher priority, but that's operator error. -- bruce@zuhause.mn.org
farren@well.sf.ca.us (Mike Farren) (01/22/91)
I, my very flawed self, wrote: >awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >>As I understand them, desk accessaries reside primarily on disk with a pointer >>to the code on disk. The desk accessory is invoked via a menu. >You do not understand them. Desk accessories become part of the system >file, unless you are running a utility like "Suitcase". They absolutely >take up RAM. No, *I* don't understand them. Should have looked it up in Inside Mac, instead of posting a knee-jerk pseudo-knowledgable response at 4:00 A.M. Sorry - it's been pointed out to me by several that DAs do not take up space in the system file - only pointers to them and their disk locations do. Still think the "infinite DAs" of the Amiga are better, though :-) -- Mike Farren farren@well.sf.ca.us
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/23/91)
In article <22820@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: >Sorry - it's been pointed out to me by several that DAs do not take up >space in the system file - only pointers to them and their disk locations They DO take up space in the System if you aren't using Suitcase or MasterJuggler. The deal is that the System isn't entirely loaded into RAM. Before I used SuitCase, I had System files in the 3-4 meg range on 1 meg Mac Pluses. The System still only took up 200-300k. Fonts and Desk Accesories were loaded as needed and the resources purged as others were called. >do. Still think the "infinite DAs" of the Amiga are better, though :-) As a matter of fact, so do I. Maybe we'll see them in a couple of years on the Mac. (I'm just glad my Mac's motherboard will take 128 meg, 'cause I think I'll be needing it.)
daveh@cbmvax.commodore.com (Dave Haynie) (01/23/91)
In article <42828@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >>to compare the best of both worlds, compare a 25MHz 68040 with a 25MHz 486 and >>you will find that the 486 is half as powerful. >Given the leap-frogging nature of chips, I've never considered the best at any >particular time a good comparison of machines. I figure the 030 and the 486 are >the chips to compare Given similarly creative systems around them, an '030 + '882 does roughly 1/2 the amount of work that a '486 does at the same speed, integer-wise, and maybe 1/3 the work, floating-point wise. For example, Personal Workstation found the HP 50MHz 68030 machines to run just a tad faster than similarly equipped 25MHz 80486 machines. Under UNIX, at least. Of course, a good 50MHz system is much more expensive to build than a good 25MHz system, which is why a more modern chip architecture, like the '486 or '040, can approach the cost of an older system of similar performance even before the price on the new parts starts dropping (you don't really see this in the PClone market, since there aren't any 50MHz '386s to compare to the 25MHz '486s). >(and I still wouldn't take a 486 running Windows over an 030 Amiga or Mac.) Pointing out, of course, that CPU speed isn't the whole ball of wax. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
doubt@elf.rice.edu (Douglas Benjamin Triggs) (01/23/91)
In article <1991Jan21.221744.5966@rice.edu>, jsd@boreal.rice.edu (Shawn Joel Dube) writes: |> |> |> |> Amiga Time ---> |> |> |> |> Task A |******** ******** ******** ********> |> |> |> |> Task B | ******** ******** ******** > |> |> |> |> |> |> |> |> Mac |> |> |> |> Task A |***** ** ****** ************* ** ***> |> |> |> |> Task B | *************** ***** * ** ** > |> |> |> |> |> |> |> |> |> No, a program running under AmigaOS would not waste any time doing |> |> nothing (waiting for that keypress). It would skip that task and do the |> |> others, unless the programmer is a complete idiot (which, alas, some seem |> |> to be). A more accurate graph would be: |> |> |> |> Amiga Time ---> |> |> Task A |**** ** **** ****> |> |> Task B | **** **** **** **** **** **** > |> |> Task C | **** **** **** **** **** > |> |> ^ point A ^ point B |> |> |> |> (Where task A is waiting for a keypress between points A and B.) |> |> |> |> Now compare Doug's chart to the one above. Which does it most look like? |> I would say that it looks mostly like the Mac's becuase each task is not |> getting equal CPU time. |> |> -- |> rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr |> r ___ _ r |> r /__ | \ N U K E I R A Q ! ! ! r |> r ___/hawn |__\ube ----------------------- r |> r jsd@owlnet.rice.edu r |> rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr The graphs are not what I would call "similar." The Mac's tasking is jerky, and the Amiga's is somewhat smoother (to say the least). In any case, on the Amiga, no program can take exclusive control of the CPU unless it does something special, while on the Mac, an incorrectly written program can easily do this, unless it does something special to avoid it. Doubtfully yours, --my name here-- --- doubt@owlnet.rice.edu --- GM # 8400000E _ _ doubt //// o MacIntosh, adj., idiotic, braindead, terminally __ /| _ _ //// stupid. Usage: "That manual is 'macintosh'" \'o.O' \\\X/// see also: useless; overpriced; ripoff =(___)= \XXX/ o Lotus, v., synonym for "sucks." Usage: "Lotus U (sucks)." see also: federal juristiction invol- "O.A.M.I.P." ving CD's, state borders, and immoral purposes Oop! Ack!
daveh@cbmvax.commodore.com (Dave Haynie) (01/23/91)
In article <1991Jan21.055854.14130@rice.edu> jsd@wahoo.rice.edu (Shawn Joel Dube) writes: >Seriously, I think cooperative is better. I think you got that backwards... >Take the following for example: >Two task are running. One is waiting on a keypress (via OS subroutine) >and the other is doing some serious number-crunching. With the Amiga, >valuable time is being spent doing nothing (waiting for a keypress). On the Amiga, no time is spent waiting for a keypress. If a task needs to wait synchronously for some I/O event, it is suspended, consuming no CPU time, until the I/O operation has completed. >With co-op multitasking, almost all of the cpu time is spent with the number >cruncher. The co-op system may indeed point the CPU at the crunching task. So will the Amiga OS, since the I/O bound tasks are waiting for I/O interrupts and signals before they get rescheduled. Now you press a key. The Amiga will get an interrupt, the waiting task will get signaled and, assuming its at the same or high priority than the CPU bound task, it'll get activated during the next time slice. On the co-op system, one of two things happens. Either the CPU bound task must have some event monitor subroutine in somewhere, wasting CPU time each time its called, or the I/O blocking task will have to wait for the CPU bound task to complete before processing the keypress. In either case, the Amiga gets the same combination of CPU and I/O bound tasks done faster, guaranteed, than the co-op system. >If programmed to do so, yes. I believe in the next release of the Mac OS, >the ability to have something like Window's Dynamic Data Link will exist >that the Amiga (correct if I'm wrong) doesn't have. Under 2.0x (which is out on the A3000 now, unlike Apple's System 7.0), the Amiga has facilities which do the same kind of thing. One such facility is file notification. Basically, this does the data linking via the filesystem, which happens to be the way many programs already handle this kind of problem. On Macs, Amigas, and other systems, you very often have a collection of programs to manipulate the various pieces of one final product. For example, a document processing program may import graphics from a drawing program and charts from a spreadsheet. When dealing with multitasking, multiuser, or networked systems, it became clear some time back that a simple file import mechanism could easily leave you with stale data. Because the files only get updated, at best, when an application is started up. On the Amiga, an application can not only import a file, but ask the filesystem to send it a message if that file ever changes. So if you change drawings over a network and I flip over to my spreadsheet and change the graph in the aforementioned example, when I flip back to the documentation processor, it'll already have the new versions there waiting for me if it knows about notification. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
torrie@cs.stanford.edu (Evan J Torrie) (01/23/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: > No. Programs can set their own priorities, however, and the input > handling task runs at a higher priority than anything else (so if > you raise an application's priority to, say, 1 (normal is 0), then > you will still get input). Can you explain the "input handling" task? Do programs spin off an input-handler thread (this is how OS/2 programs are written if I recall)? > A number of programs display some intelligence about what priority > to use automatically (like editors that edit at priority 1, or > executable packers that crunch at priority -1, etc). And some can > be configured. "Some" can be configured? Is there an all-purpose "nice" command? > The input handling task runs at a priority of 20, and this is what > handles using Intuition, so at that level interactive use stays > reasonable. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "And remember, whatever you do, DON'T MENTION THE WAR!"
jbickers@templar.actrix.gen.nz (John Bickers) (01/23/91)
Quoted from <1991Jan21.072642.23587@Neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan J Torrie): > How does the Amiga handle priorities for interactive tasks? e.g. if > I have a word processor in the foreground, in which I'm scrolling > around, typing characters in etc, can you guarantee that it gets more > time (by setting it to a higher priority) than background tasks? Is Yes, the user can set priorities. > that handled automatically by the system (i.e. recognising interactive > tasks)? No. Programs can set their own priorities, however, and the input handling task runs at a higher priority than anything else (so if you raise an application's priority to, say, 1 (normal is 0), then you will still get input). A number of programs display some intelligence about what priority to use automatically (like editors that edit at priority 1, or executable packers that crunch at priority -1, etc). And some can be configured. The input handling task runs at a priority of 20, and this is what handles using Intuition, so at that level interactive use stays reasonable. > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (01/23/91)
Quoted from <1991Jan21.073234.23885@Neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan J Torrie): > With a preemptive multitasking system, you would still have the same > problem on a heavily loaded system. The screen saver would run to the > end of its timeslice, then the other programs would run to the end of > their timeslices, and you'd still get that pause in the animation > while the other programs are running. Animation programs, sound programs, and comms programs doing downloads are more candidates for automatically moving into higher priority ranges. > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (01/23/91)
Quoted from <1991Jan21.132909.18488@ncsuvx.ncsu.edu> by kdarling@hobbes.ncsu.edu (Kevin Darling): > In <1991Jan21.004720.25985@ncsuvx.ncsu.edu> I contend: > >> So the speed diff is only related to the (Mac GetEvent delay x number of > >> times) it's called; versus the (Amiga tick routine delay x number of times) > >> it's done. Unless we know those timings, speed claims are meaningless. > > >jbickers@templar.actrix.gen.nz (John Bickers) replies: > > Having the ray tracer do one of these GetEvent() calls must have > > more of a relative effect on the ray tracer than having another > > task in the wait list under Exec. > > "Must have"? Again, without timing data such statements are meaningless > conjecture. If say, the GetEvent() took 10us to figure out there was no > events/tasks, and the regular Amiga tick interrupt routine took 20us, This is somewhat askew... I said "more of a relative effect". By this I mean: Suppose the Mac tracer rendered a scene in N seconds if it didn't call GetEvent() every so often. Adding GetEvent() calls must increase the rendering time (unless someone's finally gotten those thiotimoline (sp?) chips working :). Now suppose the Amiga tracer rendered a scene in N seconds with M idle tasks on the machine. Adding another task to do what the GetEvent() call was supposed to accomplish (user interface stuff) has the same cost as adding any other task - whether it's connected with the tracer or not. So the "relative" affect is zero - the extra interface has the same cost as any other task sitting idle. The Amiga N may be greater than the Mac N, and adding a task may increase the Amiga N more than adding GetEvent()s increases the Mac N, but this extra cost isn't "the tracer", it's the same as adding any other task. (On a related note, you can simply boost the tracer's priority as required to reduce the M value above). > I fully agree! At the same time, we just didn't have enough info to make > a claim that preemptive = faster in the given example. In fact, I'd bet that Yeah. Multitasking at all implies some overhead that a single-tasking system isn't going to have. This is the price we pay for convenience. Xoper reports figures that look really bad re CPU usage during CPU intensive things. Anyone know how accurate Xoper can be assumed to be? > That kind of kneejerk reaction can make all claims suspect. best - kev -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (01/23/91)
Quoted from <42858@ut-emx.uucp> by awessels@ccwf.cc.utexas.edu (Allen Wessels): > BASIC is NEVER the language of choice. Maybe you should advise Microsoft to > stop selling their high-end BASIC development systems. It was interesting to read a claim by Gates (sp?) once that he could implement anything (my memory is vague) in BASIC faster than anyone else who used any other language. Did anyone ever take him up on that? -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
davewt@NCoast.ORG (David Wright) (01/23/91)
In article <1991Jan22.200035.29996@rice.edu> jsd@arcadien.rice.edu (Shawn Joel Dube) writes: > >But the Amiga's tasking is still jerky. You obviously haven't seen it, or you saw it used be someone who had their task priorities screwed up royally. The Amiga seems to do the best task switching of any system I have used (Unix/Xenix/Minix, OS-9, Mac, NeXT, Windows, etc.). Since by default all tasks run at the same priority, tasks tend to not be jerky, but rather everything runs more slowly. Of course the user is free to adjust the priorities to improve the time on more critical tasks (which you can't do on the Mac). And even at a higher priority, most tasks need to do something like wait for data from the [keyboard|mouse|serial] device, and so give up the CPU during times when the user won't notice the task switch. >|> In any case, on >|> the Amiga, no program can take exclusive control of the CPU unless it does ^^^^^^^^^^^^^^ >|> something special, while on the Mac, an incorrectly written program can ^^^^^^^^^^^^^^^^^^^^^^ >|> easily do this, > >I feel that that feature *should* exsist (program taking over complete control) Read what he said. He didn't say it was impossible (and almost all commercial "arcade-type" programs do), he said that you had to specifically ASK to do so, whereas on the Mac you must specifically ALLOW a task switch (outside of system calls). >the display might be distorted (slowed or jerky). I have yet to encounter a Mac program >that took full control. In fact, old programs (written when the Mac was first released) >work properly when used in MultiFinder. Hogwash. The older the Mac program is, the more likely it is to use busy loops for timing (many games for the Mac won't run correctly on faster machines. I know. Running them under AMax II on my 25Mhz 030 many are unplayable because the programmer was to [lazy|stupid|ignorant] to do timing via a hardware clock.) And under MultiFinder (which I use exclusively when running AMax) many programs (not just games) hog the CPU and the task in the front tends to get more CPU time than the others, which may (and in my normal mode IS) be the incorrect thing to do. As another example of the brain-deadness of MultiFinder, consider that you have to stop MultiFinder to make a system file change, then restart all the applications you have running. This is rediculous. On the Amiga you can change any system preference, and not only do things continue to operate, but any program that wants to know about the changes can be automatically notified, and start taking advantage of them right away. Dave
peter@sugar.hackercorp.com (Peter da Silva) (01/23/91)
In article <1991Jan21.004720.25985@ncsuvx.ncsu.edu>, kdarling@hobbes.ncsu.edu (Kevin Darling) writes: > > On the Amiga you'd do that by splitting the program into a compute engine > > and a user interface task. The compute engine runs at full speed without > > having any code in the main loop to check for user interaction, and the > > user interface task just sits there waiting for input taking up no CPU time > > until you need it. > So the speed diff is only related to the (Mac GetEvent delay x number of > times) it's called; versus the (Amiga tick routine delay x number of times) > it's done. Unless we know those timings, speed claims are meaningless. > Perhaps there's a better example? - kevin <kdarling@catt.ncsu.edu> This assumes that all you're doing is running the computation. The context here is multitasking, and running the ray-trace in the background. So, the difference in speed comes up in a couple of ways: 1. The compute-intensive program has a smaller main loop. The main loop may also have no subroutine calls in it, which greatly simplifies the task of optimising it because it never has to worry about aliasing. 2. Most of the time most of the programs on the Amiga are quiescent, and aren't even on the ready queue. So the only thing taking away from the compute task is the vertical blank interrupt (the tick routine). The Mac system, on the other hand, runs through all the other tasks in the system that call GetNextEvent, every time. It also frequently makes tours through the code for programs that call WaitNextEvent. The Amiga allocates available resources much more efficiently than the Mac: I'm currently using my stock Amiga 1000. 7.16 MHz 68000, 512K. I can multitask effectively and usefully in this environment, using real programs. In fact I have 243K free right now. I don't think anyone would claim that you could even run multifinder in a similarly equipped Mac. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/23/91)
In article <1991Jan21.055854.14130@rice.edu> jsd@wahoo.rice.edu (Shawn Joel Dube) writes: > Two task are running. One is waiting on a keypress (via OS subroutine) > and the other is doing some serious number-crunching. With the Amiga, valuable > time is being spent doing nothing (waiting for a keypress). With co-op > multitasking, almost all of the cpu time is spent with the number cruncher. I think you have things backwards. On the Amiga a task waiting for a keypress takes up zero CPU time. Not "almost no" CPU time, Zero. It's not even on the ready queue. It's in a wait state. On the Mac a program waiting for a keypress has to sit there and handle all the events coming into it from WaitNextEvent. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/23/91)
In article <1991Jan21.072642.23587@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > I have a word processor in the foreground, in which I'm scrolling > around, typing characters in etc, can you guarantee that it gets more > time (by setting it to a higher priority) than background tasks? Yes. > Is that handled automatically by the system (i.e. recognising interactive > tasks)? No. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/23/91)
In article <1991Jan21.073234.23885@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > With a preemptive multitasking system, you would still have the same > problem on a heavily loaded system. The screen saver would run to the > end of its timeslice, then the other programs would run to the end of > their timeslices, and you'd still get that pause in the animation > while the other programs are running. Not at all, that's what priorities are all about. The Amiga doesn't use a strict round-robin scheduler. I hope your screen saver uses delays after each screen instead of chucking out displays as fast as it can. What does it do on a faster CPU? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/23/91)
In article <42858@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > Maybe you should advise Microsoft to > stop selling their high-end BASIC development systems. I have. When I discovered that Microsoft is using Basic as a macro language in Windows I nearly puked. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/24/91)
In article <1991Jan23.044023.4829@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >ASK to do so, whereas on the Mac you must specifically ALLOW a task switch >(outside of system calls). Some people out there may get the impression that Mac programmers somehow constantly have to remind themselves of this requirement. It is second nature for most of them. You take as much CPU as you need and you pass it on. > Hogwash. The older the Mac program is, the more likely it is to use >busy loops for timing (many games for the Mac won't run correctly on Well, the other day I accidentally launched MacWrite 1.0 (1984) on this Mac IIsi and it ran just fine (I'm using multifinder.) >faster machines. I know. Running them under AMax II on my 25Mhz 030 many >are unplayable because the programmer was to [lazy|stupid|ignorant] to >do timing via a hardware clock.) And under MultiFinder (which I use It is a bad habit, but one I've seen in programs for many machines. If, for some reason, you WANT to play those games, check out either Sludge or SpeedChopper. They'll waste CPU time until things are slow enough for you. > As another example of the brain-deadness of MultiFinder, consider >that you have to stop MultiFinder to make a system file change, then restart >all the applications you have running. This is rediculous. On the Amiga you >can change any system preference, and not only do things continue to operate, >but any program that wants to know about the changes can be automatically >notified, and start taking advantage of them right away. Exactly what changes are you thinking of? I can add and remove DAs with Font/ DA Mover, and fonts with another utility. Some applications don't check to see if the system config has changed (and, as far as I know there isn't a way to notify them of this change), but they CAN do it. Just as an example, while running this term session I ran ResEdit, opened the System file, added an FKEY and saved the change. The FKEY was immediately available. At the very least, I didn't "have" to stop MultiFinder or restart the term session. What kinds of System preferences are you talking about on the Amiga? I don't know what the analagous (if they exist) examples would be on the Mac. Most preferences I normally change are in the Control Panel.
torrie@cs.stanford.edu (Evan J Torrie) (01/24/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: >Quoted from <1991Jan22.215801.4557@Neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan J Torrie): >> Can you explain the "input handling" task? Do programs spin off an >> input-handler thread (this is how OS/2 programs are written if I > Consider that there are two levels to input handling. One is handling > receipt of the users actions (buffering keystrokes, moving the mouse > pointer, resizing windows, swapping screens, etc). The other is the Do user actions include "mouse-downs" in things like scroll-bars etc?? > application actually getting around to doing something with the input. This is what I'm interested in. > This gets input from the user, and funnels each event through a > chain of input handlers. The program JDMouse is one such, which How does a program become an input handler? I presume you can spawn off a task, and tell it to be an input handler... > The 2nd level can be handled in a variety of ways (some programs > do use input-handlers as well as normal mechanisms), and varies > from program to program. I'm mainly interested in the 2nd level, i.e. how a normal application would handle getting and processing events in an interactive fashion. You say some programs do use input-handlers... does this mean they multi-thread themselves, spinning off an input handler task, and then communicate between the main program and the input handler task? What is the "normal mechanism"? The particular scenario I'm interested in is this... suppose we have a word processing application, with scroll bars, etc running at a normal priority (say 1 or so) on a heavily loaded system. When a user clicks on the scroll bar, the ideal is to respond as quickly as possible (i.e. the text/pictures in the word processor scroll down quickly). From the discussion above, it seems that the input.device task will handle the mouse down immediately (because it's running at such a high priority). But normally, the code to regenerate the window's view (what I call an Update event) is located in the main word processor task. If the word processor task remains at priority 1, this code won't get run until the WP's task gets scheduled by the scheduler (which on a heavily loaded system may be in the tenths of a second). Thus, it seems to be possible to buffer up a whole lot of mousedowns on the scroll bar, all received by the input.device task, but the actual code to regenerate the window won't be scheduled... thus won't you get a jerky, or at least a non-responsive task? I'm just wondering if you would get better response by having the OS temporarily boosting the priority of an interactive task (e.g. raising the word processor priority to 10 while the user is clicking on the scroll bar in the WP's window) -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Fame, fame, fame... What's it good for? Ab-so-lute-ly nothing
rjc@geech.ai.mit.edu (Ray Cromwell) (01/24/91)
In article <1991Jan23.213736.28220@Neon.Stanford.EDU| torrie@cs.stanford.edu (Evan J Torrie) writes: |jbickers@templar.actrix.gen.nz (John Bickers) writes: | |Quoted from <1991Jan22.215801.4557@Neon.Stanford.EDU| by torrie@cs.stanford.edu (Evan J Torrie): | Consider that there are two levels to input handling. One is handling | receipt of the users actions (buffering keystrokes, moving the mouse | pointer, resizing windows, swapping screens, etc). The other is the | | Do user actions include "mouse-downs" in things like scroll-bars etc?? Yep. | application actually getting around to doing something with the input. | | This is what I'm interested in. | | This gets input from the user, and funnels each event through a | chain of input handlers. The program JDMouse is one such, which | | How does a program become an input handler? I presume you can spawn |off a task, and tell it to be an input handler... There are a bunch of ways. One of the easiest is to ask the input.device to "please install my routine into your handler chain." I've never written an input handler (most people don't need to), but thats how I remember it. | The 2nd level can be handled in a variety of ways (some programs | do use input-handlers as well as normal mechanisms), and varies | from program to program. | | I'm mainly interested in the 2nd level, i.e. how a normal |application would handle getting and processing events in an |interactive fashion. | You say some programs do use input-handlers... does this mean they |multi-thread themselves, spinning off an input handler task, and then |communicate between the main program and the input handler task? Most Amiga programs use IDCMP. This stands for Intuition Direct Communications Message Port :-) IDCMP is a Message Port that receive input events from intuition that can range from timer ticks, mouse move events, button clicks, someone picking a menu, hitting a key, selecting a gadget, sizing a window, etc. Lots of stuff. Even inserting a disk. See below. | What is the "normal mechanism"? | | The particular scenario I'm interested in is this... suppose we have |a word processing application, with scroll bars, etc running at a |normal priority (say 1 or so) on a heavily loaded system. | When a user clicks on the scroll bar, the ideal is to respond as |quickly as possible (i.e. the text/pictures in the word processor |scroll down quickly). | From the discussion above, it seems that the input.device task will |handle the mouse down immediately (because it's running at such a high |priority). But normally, the code to regenerate the window's view |(what I call an Update event) is located in the main word processor |task. If the word processor task remains at priority 1, this code |won't get run until the WP's task gets scheduled by the scheduler |(which on a heavily loaded system may be in the tenths of a second). This is what makes the Amiga so nice. In a typical application. A program opens a window and Intuition creates an IDCMP port. The program will then Wait(MyWindow-|UserPort-|mp_SigBit) for an input event to occur. The application at this point falls asleep. When an input event occurs intuition sends a message to the Window's IDCMP(UserPort), Exec's scheduler says 'Hey, this task was asleep waiting for this event, lets wake him up.' The Application wakes up and Replys to the Message, then processes it. | Thus, it seems to be possible to buffer up a whole lot of mousedowns |on the scroll bar, all received by the input.device task, but the |actual code to regenerate the window won't be scheduled... thus won't |you get a jerky, or at least a non-responsive task? Intuition is smart, the internal window generation code runs on the input.device task instead of the user task (notice in the list that was posted, the input.device was eating 30% of CPU time.). Also, rendering is done IN PARALLEL with the blitter chip, nice isn't it? The only way lots of input events get buffered up, is if the user task doesn't respond to the messages intuition sends to its IDCMP port, or the system is SEVERLY bogged down. I have never encountered this except when I foolishly ran a program which set its priority higher than the input.device. | I'm just wondering if you would get better response by having the OS |temporarily boosting the priority of an interactive task (e.g. raising |the word processor priority to 10 while the user is clicking on the |scroll bar in the WP's window) Not really, unless your are running a ray-tracer at a higher priority than your WP, which is stupid.
jbickers@templar.actrix.gen.nz (John Bickers) (01/24/91)
Quoted from <1991Jan22.215801.4557@Neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan J Torrie): > jbickers@templar.actrix.gen.nz (John Bickers) writes: > > No. Programs can set their own priorities, however, and the input > > handling task runs at a higher priority than anything else (so if > Can you explain the "input handling" task? Do programs spin off an > input-handler thread (this is how OS/2 programs are written if I Consider that there are two levels to input handling. One is handling receipt of the users actions (buffering keystrokes, moving the mouse pointer, resizing windows, swapping screens, etc). The other is the application actually getting around to doing something with the input. The 1st level is handled by a single task. The following is a list of tasks currently running on my machine... CPU:68020/68881 CPU activity: 25.0% Dispat/Sec: 19.4 I/O Ints/Sec: 11.7 ID TYPE STATE PRI CPUSE NUM TASKNAME ----------------------------------------------------- 0025d190 Process Running 0 6.7% --- Xoper 00202748 Process Waiting 4 0.0% 0 RexxMaster 0020b4a8 Process Waiting 4 0.0% --- WSH_Completer 002185b0 Process Waiting 1 0.6% --- JDMouse 00219b78 Process Waiting 5 0.0% --- PopUpMenu 0021f450 Process Waiting 4 0.0% --- Snap 00222b50 Process Waiting 10 4.1% --- MISC 00225b90 Process Waiting 0 0.0% 1 New_WShell 0022eac8 Process Waiting 5 0.0% --- CON 0023c5b8 Process Waiting 0 2.0% 2 [ getty ] 0023db38 Process Waiting 5 0.0% --- NULL 0023df40 Process Waiting 0 0.0% 3 [ dcron ] 0024019c Task Waiting 0 0.0% --- narrator.device 00242d98 Process Waiting 10 0.0% --- PATH 00251510 Process Waiting 0 0.0% 4 [ tnews ] 0025ef20 Process Waiting 10 4.4% --- FAST 0027c810 Process Waiting 1 0.0% 0 CygnusEd 00c00bd8 Process Waiting 10 8.3% --- File System +-> 00c0270a Task Waiting 20 47.7% --- input.device | 00c0482e Task Waiting 5 8.5% --- trackdisk.device | 00c05d08 Process Waiting 10 4.4% --- File System | 00c06266 Task Waiting 5 8.5% --- trackdisk.device | 00c13e48 Process Waiting 0 0.0% --- RAM | 00c15360 Process Waiting 10 4.1% --- DH0 | 00c169cc Task Waiting 5 0.0% --- hddisk.device | +- See input.device, the one with a priority of 20? That's it. This gets input from the user, and funnels each event through a chain of input handlers. The program JDMouse is one such, which does screen blanking (timer events), mouse acceleration (mouse events), and what-not. PopUpMenu and Snap are another two. The 2nd level can be handled in a variety of ways (some programs do use input-handlers as well as normal mechanisms), and varies from program to program. > > A number of programs display some intelligence about what priority > > to use automatically (like editors that edit at priority 1, or > > executable packers that crunch at priority -1, etc). And some can > > be configured. > > "Some" can be configured? Is there an all-purpose "nice" command? By configured I mean can be set to use a particular priority through a configuration file. By "nice" command I assume you mean a command that can change task priorities on the fly (that's not what I meant by configured, sorry). Anyhow, yes, the program that produced the task list above can also be used to change priorities (amongst other things, including pausing or killing tasks). > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
Erik.Funkenbusch@p7.f55.n282.z1.fidonet.org (Erik Funkenbusch) (01/24/91)
SJ> From: jsd@boreal.rice.edu (Shawn Joel Dube) SJ> Date: 21 Jan 91 17:05:57 GMT SJ> Organization: Rice University SJ> Message-ID: <1991Jan21.170557.25934@rice.edu> SJ> Newsgroups: comp.sys.amiga.advocacy SJ> In article <1991Jan21.101849.13078@eecs.wsu.edu>, SJ> pcooper@eecs.wsu.edu (Phil Cooper - CS495) writes: >|> >|> >|> >|> *=Cycle >|> >|> >|> >|> Amiga Time ---> >|> >|> Task A |******** ******** ******** ********> >|> >|> Task B | ******** ******** ******** > >|> >|> >|> >|> Mac >|> >|> Task A |***** ** ****** ************* ** ***> >|> >|> Task B | *************** ***** * ** ** > >|> >|> >|> >|> In my own opinion cooperative multitasking is not multitasking, simply >|> >|> because its not very transparent. >|> > >|> >Seriously, I think cooperative is better. Take the following for example: >|> >Two task are running. One is waiting on a keypress (via OS subroutine) >|> >and the other is doing some serious number-crunching. With SJ> the Amiga, valuable >|> >time is being spent doing nothing (waiting for a keypress). >|> >|> Of course, this is just wrong... If one task is waiting on a key press, >|> no CPU time is consumed by it. If the program is written correctly (without >|> a polling loop or some such nonsense), it merely waits. When the key is >|> pressed, the task is signalled and it continues. So, as you SJ> can see, no time >|> is being wasted. Also, please check your facts before posting SJ> trash like this. >|> It really angers me (and others) when misinformation is spread under the >|> pretense of truth. SJ> Assuming the chart above is correct, time SJ> is allocated to each process equally. SJ> Any idiot can see that Task A gets just SJ> as much time as Task B, even if Task A SJ> is simply waiting for a keypress. SJ> I didn't make the chart, so if it's SJ> wrong, don't blame me for spreading false SJ> information. Blame the person who made the chart. No, that chart is NOT quite correct, whenever a task needs a resource such as a key pressed or disk I/O it gives up it's processor time with a Wait() instructionn. in this case it's like co-operative multi-tasking, however the big difference is that when task A (or B) has used up it's aloted time it switches to the next task, wheather the program is ready or not. >|> >|> Have a nice day... >|> Phil Cooper SJ> -- SJ> rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr SJ> r ___ _ r SJ> r /__ | \ N U K E I R A Q ! ! ! r SJ> r ___/hawn |__\ube ----------------------- r SJ> r jsd@owlnet.rice.edu r SJ> rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr SJ> n
lsr@Apple.com (Larry Rosenstein) (01/24/91)
In article <17913@cbmvax.commodore.com>, daveh@cbmvax.commodore.com (Dave Haynie) writes: > > updated, at best, when an application is started up. On the Amiga, an > application can not only import a file, but ask the filesystem to send it a > message if that file ever changes. So if you change drawings over a network > and I flip over to my spreadsheet and change the graph in the aforementioned > example, when I flip back to the documentation processor, it'll already have > the new versions there waiting for me if it knows about notification. And that's what happens under System 7 (via the Edition Manager).
orovner@sdcc13.ucsd.edu (Oleg Rovner) (01/24/91)
In article <11836@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: > >And that's what happens under System 7 (via the Edition Manager). And WHERE is System 7? -- ************************************************************************ GOD BLESS AMERICA! SUPPORT OUR TROOPS AND OUR ALLIES! FREE KUWAIT! ************************************************************************
peter@sugar.hackercorp.com (Peter da Silva) (01/24/91)
Big charts and huge .signatures omitted, we have: In article <1991Jan21.221744.5966@rice.edu>, jsd@boreal.rice.edu (Shawn Joel Dube) writes: > Now compare Doug's chart to the one above. Which does it most look like? > I would > say that it looks mostly like the Mac's becuase each task is not getting eqaul > CPU time. All the tasks that *need* CPU time at any point are getting an even share of it. More importantly, most tasks sit there most of the time *not* needing any CPU time. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/24/91)
I said: > On the Mac a program waiting for a keypress > has to sit there and handle all the events coming into it from WaitNextEvent. Now someone from Apple sent me mail disputing this. Yes, the task can ignore any but keypress inputs, but if it does that its window will not be properly updated: it's the applications responsibility for managing its own window, and obscured sections of that window will not be repainted when windows in front of it disappear. I suspect that other aspects of the application's user interface will break until it starts listening for display events again, but in any event it's not practical for a Mac task to just ignore everything but keypresses, so I doubt much, if any, real software does. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
davewt@NCoast.ORG (David Wright) (01/24/91)
In article <1991Jan22.215801.4557@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > > Can you explain the "input handling" task? Do programs spin off an >input-handler thread (this is how OS/2 programs are written if I >recall)? There is one global system input handler, which feeds into the other programs. But a program is free to "spin off" another task to do it's I/O handling, so that the user can move around a spreadsheet while it is recalculating, if they wish. > "Some" can be configured? Is there an all-purpose "nice" command? All commands can have their priority adjusted, even ones that set their own priority. the command "ChangeTaskPri" will allow you to set a specific priority either for the current CLI, or for tasks that are running outside of the current CLI. Most of the programs that set their own priority allow you to set a "delta" priority for that application, so you can say that the subtasks the program may start will run at "-1" for that task (one below that tasks priority). But the system priorities are all fixed numbers, with 0 being the default. Dave
davewt@NCoast.ORG (David Wright) (01/24/91)
In article <1991Jan23.213736.28220@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >jbickers@templar.actrix.gen.nz (John Bickers) writes: > > Do user actions include "mouse-downs" in things like scroll-bars etc?? Yes, as well as mouse movements, keys such as the shift key being pressed and released, disks being inserted and removed, virtually everything. > How does a program become an input handler? I presume you can spawn >off a task, and tell it to be an input handler... It depends on what you want to do. If you want to ONLY be an input handler you should be a very small and fast program, and you can put yourself into the input even chain above or below the mian system input handler. But this is nor usually reccomended. The better way to do this is to write an application that follows the guildelines for running under "Commodities Exchange", which is available under 2.0. This lets you write an input event handler that can take out or insert events into the input even queue and still get along with other programs doing the same thing. And the user gets a nice WorkBench control panel that lets them freeze, restart, and remove any CEX applications they wish. > I'm mainly interested in the 2nd level, i.e. how a normal >application would handle getting and processing events in an >interactive fashion. > You say some programs do use input-handlers... does this mean they >multi-thread themselves, spinning off an input handler task, and then >communicate between the main program and the input handler task? If they wish, but that is not normally needed. Most programs on any machine are waiting for user input, not running in the background. For instance a paint program would have no need to spawn another task for input, since it is always waiting. And under Intuition, the task doesn't even have to be ready for input for you to click in it's gadgets or select pull-down menus. The program will get the events from it's private input queue when it is ready for them. >task. If the word processor task remains at priority 1, this code >won't get run until the WP's task gets scheduled by the scheduler >(which on a heavily loaded system may be in the tenths of a second). > Thus, it seems to be possible to buffer up a whole lot of mousedowns >on the scroll bar, all received by the input.device task, but the >actual code to regenerate the window won't be scheduled... thus won't >you get a jerky, or at least a non-responsive task? Yes, but the user would expect this, if they had a lot of other programs running at the same priority. > I'm just wondering if you would get better response by having the OS >temporarily boosting the priority of an interactive task (e.g. raising >the word processor priority to 10 while the user is clicking on the >scroll bar in the WP's window) Yes, this would work. But is very rude, and not many programs do this. How do you know that the user WANTS the WP to work smoothly? Personally, I run a multi-user game on my computer 100% of the time, in the background. I want the remote users I/O to be as fast as possible, so I run their programs at a higher priority (2 & 3), while I run mine at 0 or less. I would refuse to use a WP that upped it's priority without asking my permission. I expect the repsonse to be slower (although normally neither myself and the other users can't tell anyone is using the system besides themselves), and I'm willing to live with it, those rare times it occurs. But technically, yes, you could do what you want. But why not just run at the same priority all the time? If the user wants faster response they can up the WP priority. Since most of the time it will be waiting for user input, the other tasks will get plenty of time to run in the background, even if the user has the WP running at a high priority. Dave
kdarling@hobbes.ncsu.edu (Kevin Darling) (01/25/91)
<11836@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: |<17913@cbmvax.commodore.com>, daveh@cbmvax.commodore.com (Dave Haynie): | |> updated, at best, when an application is started up. On the Amiga, an |> application can not only import a file, but ask the filesystem to send it a |> message if that file ever changes. | |And that's what happens under System 7 (via the Edition Manager). And OS9 L-II 3.0 had it. And I suspect most OS's will before very long, if they don't already. OS's seem to be converging at a rapid rate. It's just a matter of time before they all look quite similar to the programmer. Dunno if that's good or bad (I tend to think "good"). Sidenote: I'm not sure why some mention that System 7 isn't out yet. Amiga 2.0 isn't out yet for 500's, I thought. And sure won't be for my A1000 :-(. This kind of argument is a two-way street; and obviously nulls out within a fairly short period of time. cheers - kev
daveh@cbmvax.commodore.com (Dave Haynie) (01/25/91)
In article <42828@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >In article <1991Jan20.042633.16661@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: >>I sure wish I could put 64MB of RAM on my AT&T 6300 like I can on my Amiga. >(Just curious, but does anyone out there have that much RAM installed?) I set up an A3000 with 16MB of motherboard Fast RAM, 2MB of Chip RAM, 32MB of Zorro III expansion RAM, and 2MB of Zorro II expansion RAM just for kicks once. I didn't really have anything useful to do with all that memory, so I gave back most of the 4MB DRAMs, and I'm now back to the basic 10MB setup (8MB Fast, 2MB Chip) that I've found I can't use up in anything I normally do with my system. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
peter@sugar.hackercorp.com (Peter da Silva) (01/26/91)
In article <1991Jan22.215801.4557@Neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan J Torrie) writes: > "Some" can be configured? Is there an all-purpose "nice" command? Yes, you can set the priority of any shell or process. Unfortunately some programs blithely override this. You can't easily reset it after one starts up, but it *is* possible. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/26/91)
In article <1991Jan23.213736.28220@Neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan J Torrie) writes: > You say some programs do use input-handlers... does this mean they > multi-thread themselves, spinning off an input handler task, and then > communicate between the main program and the input handler task? Yes. What they usually do is create a message port, and then spawn off a task to handle computations. This task immediately waits on the message port until you need to crunch. The user-interface task can then sit there handling the user's requests. > From the discussion above, it seems that the input.device task will > handle the mouse down immediately (because it's running at such a high > priority). But normally, the code to regenerate the window's view > (what I call an Update event) is located in the main word processor > task. A word processor would probably not be split up this way, because they don't tend to be compute bound. This would be more like a spreadsheet. Also, the display would be handled by the user-interface task. The compute task just updates internal tables... the display selects the portions of those tables the user wants to see and presents them. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/26/91)
In article <1991Jan24.174925.10783@ncsuvx.ncsu.edu>, kdarling@hobbes.ncsu.edu (Kevin Darling) writes: > Sidenote: I'm not sure why some mention that System 7 isn't out yet. > Amiga 2.0 isn't out yet for 500's, I thought. And sure won't be for > my A1000 :-(. Agreed, this is a bummer. Especially since there's little technical reason why not. But at least it didn't obsolete as fast as the skinny mac. I don't think anyone could compare Apple and Commodore by this criterion and confuse the two... (hell, I'm using my 1000 right now. My 3000 has a keyboard problem. Who's using their original 128K Mac?) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (01/26/91)
kdarling@hobbes.ncsu.edu (Kevin Darling) writes: ><11836@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: >|<17913@cbmvax.commodore.com>, daveh@cbmvax.commodore.com (Dave Haynie): >| >|> updated, at best, when an application is started up. On the Amiga, an >|> application can not only import a file, but ask the filesystem to send it a >|> message if that file ever changes. >| >|And that's what happens under System 7 (via the Edition Manager). > >And OS9 L-II 3.0 had it. And I suspect most OS's will before very long, >if they don't already. OS's seem to be converging at a rapid rate. >It's just a matter of time before they all look quite similar to the >programmer. Dunno if that's good or bad (I tend to think "good"). > >Sidenote: I'm not sure why some mention that System 7 isn't out yet. >Amiga 2.0 isn't out yet for 500's, I thought. And sure won't be for >my A1000 :-(. This kind of argument is a two-way street; and obviously >nulls out within a fairly short period of time. cheers - kev BUT 2.0 *IS* available to 3000 owners. 7.0 is only available to developers. bringing 2.0 into ANY argument is quite valid because of all the 3000 owners that use it. when a Mac ships whith ANY version of 7.0 then it too can be brought into the fray of things. UUCP: {amdahl!bungia, crash}!orbit!pnet51!chucks ARPA: crash!orbit!pnet51!chucks@nosc.mil INET: chucks@pnet51.orb.mn.org
torrie@cs.stanford.edu (Evan J Torrie) (01/27/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Jan23.213736.28220@Neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan J Torrie) writes: >> priority). But normally, the code to regenerate the window's view >> (what I call an Update event) is located in the main word processor >> task. >A word processor would probably not be split up this way, because they don't >tend to be compute bound. This would be more like a spreadsheet. >Also, the display would be handled by the user-interface task. The compute >task just updates internal tables... the display selects the portions of those >tables the user wants to see and presents them. So the two tasks share the same address space/structures etc?? Do the commercially available programs on the Amiga actually DO this? (e.g. the WordPerfect, Advantage, or whatever the WPs, SSs and DBs are...) -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "I didn't get where I am today without knowing a good deal when I see one, Reggie." "Yes, C.J."
jbickers@templar.actrix.gen.nz (John Bickers) (01/27/91)
Quoted from <1991Jan23.213736.28220@Neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan J Torrie): > jbickers@templar.actrix.gen.nz (John Bickers) writes: > How does a program become an input handler? I presume you can spawn > off a task, and tell it to be an input handler... You don't start a seperate task. You usually have the handling routine inside your program, and call an OS routine to add a pointer to your code to the list. This is adding your code to an existing task (the input.device), which you then communicate with. A similar mechanism is used to add interrupt handlers. When the input.device processes an event, it gets the raw data, constructs a message, and then executes this list of handlers. So your code will be executed as part of the input.device task. This means the programmer needs to pay attention to what stack and local variables their handler expects to be using. Not hard. There are at least three ways the handler can communicate with the rest of your program: use shared variables (ie: the input.device task would be reading/writing your program's data space), use task signals, use messages. > What is the "normal mechanism"? Someone else explained IDCMPs. One of the input handlers in the list belongs to ("is", in a way) Intuition. Intuition gets the event, converts it into an Intuition event, then if it's meaningful to do so, passes it to the active user program IDCMP (ie: the active window). > From the discussion above, it seems that the input.device task will > handle the mouse down immediately (because it's running at such a high > priority). But normally, the code to regenerate the window's view > (what I call an Update event) is located in the main word processor > task. If the word processor task remains at priority 1, this code Yes, this is what happens. The application will be waiting for a message indicating that the user has fiddled with a "proportional gadget", and while the message will get queued up at the high input.device priority, the application will process it at whatever rate it is trekking at. > Thus, it seems to be possible to buffer up a whole lot of mousedowns > on the scroll bar, all received by the input.device task, but the > actual code to regenerate the window won't be scheduled... thus won't > you get a jerky, or at least a non-responsive task? Yes. The user solution is to raise the priority of the application. The application design solution would be to use several tasks, one to do the data munging, and a higher priority one to handle the interface. Note that interactive tasks (like editors) tend to spend most of their time in the "wait" list, so it's ok to run them at a high priority if you wish to. While they are waiting for events, they have negligible effect on other tasks in the system. > I'm just wondering if you would get better response by having the OS > temporarily boosting the priority of an interactive task (e.g. raising I don't believe there is a good OS solution. A user may not want a download halted while their word-processor scrolls its display a bit faster. Or whatever. The interactions involved between Intuition and all the tasks involved seem too complicated to me for an OS solution to be practical. A user can send time-consuming events to a number of tasks at the same time, for example. No, I'd leave this for the user to decide with something like Xoper, and only make broad assumptions at the application design level. > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
dac@prolix.ccadfa.oz.au (Andrew Clayton) (01/27/91)
kdarling@hobbes.ncsu.edu (Kevin Darling) writes: > > > >Sidenote: I'm not sure why some mention that System 7 isn't out yet. > >Amiga 2.0 isn't out yet for 500's, I thought. And sure won't be for > >my A1000 :-(. This kind of argument is a two-way street; and obviously > >nulls out within a fairly short period of time. cheers - kev > I've SEEN an A1000 running Workbench 2.0. I've just got my ECS denise (for my A2500), and am sorely tempted to go 2.0 Productivity mode on my Nec 3D is SUPERB. I am eagerly awaiting the official release of 2.0 to the wide world. Dac -- _l _ _ // Andrew Clayton. Canberra, Australia. I Post . (_](_l(_ \X/ ccadfa.cc.adfa.oz.au!prolix!dac . . I am. -------- I cannot send or receive email. Not to anyone at all. Not even you.
peter@sugar.hackercorp.com (Peter da Silva) (01/28/91)
In article <MWM.91Jan14120949@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > Yeah - GNU Emacs works like a charm, and ADPro can handle some > _really_ large images in 1.5M. And AmigaVision runs alongside both of > those, just fine. Where did you say that beachfront property was, > Peter? I stand by what I said. I can run all the apps I want without worrying about which order I load them or what is going to conflict with what. Of course you're gonna get applications that don't even run *once* in 1.5 Meg. There are always people out there writing oversized, overrated, and underdesigned programs. And people willing to buy more and more RAM to run them. I'm quite happy with Digipaint, Sculpt, Manx C, etcetera. And even if AmigaVision ran on my 3000 it's no use to me... there's no separate runtime that'll fit on my 1000, so I can't use it to write stuff for my son. For me Amigavision was worth every penny I spent on it. Lucky it was free... Anyone got any suggestions for a *small* multimedia authoring program? In any case, this thread does not belong in .misc, but rather in .advocacy. How about leaving it there this time? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
torrie@cs.stanford.edu (Evan J Torrie) (01/28/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: >Quoted from <1991Jan23.213736.28220@Neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan J Torrie): >> jbickers@templar.actrix.gen.nz (John Bickers) writes: >> How does a program become an input handler? I presume you can spawn >> off a task, and tell it to be an input handler... >[lots of good explanations deleted] > constructs a message, and then executes this list of handlers. So > your code will be executed as part of the input.device task. This > means the programmer needs to pay attention to what stack and local > variables their handler expects to be using. Not hard. Just as a matter of interest, it seems to me that this design would be somewhat difficult to graft virtual memory/memory protection onto without some serious backward compatibility problems... Has anyone thought about adding VM/protection onto AmigaDos?? Is it going to be a problem? >> I'm just wondering if you would get better response by having the OS >> temporarily boosting the priority of an interactive task (e.g. raising > I don't believe there is a good OS solution. A user may not want > a download halted while their word-processor scrolls its display > a bit faster. > Or whatever. The interactions involved between Intuition and all the > tasks involved seem too complicated to me for an OS solution to be > practical. A user can send time-consuming events to a number of > tasks at the same time, for example. No, I'd leave this for the user > to decide with something like Xoper, and only make broad assumptions > at the application design level. Perhaps that may be best. My question was whether there have been any studies done in this area. If you read all the classic OS design textbooks, they're all written around the assumption of large timesharing multiuser OSes... none that I've seen give much thought to a single user multitasking OS. For example, I believe the Amiga OS was derived from Tripos? by Metacomco?. What was the original design decision behind the Amiga OS ancestors? -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "If it weren't for your gumboots, where would you be? You'd be in the hospital, or in-firm-ary..." F. Dagg
kdarling@hobbes.ncsu.edu (Kevin Darling) (01/28/91)
In <3889@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >> Sidenote: I'm not sure why some mention that System 7 isn't out yet. >> Amiga 2.0 isn't out yet for 500's, I thought. [me] > >BUT 2.0 *IS* available to 3000 owners. 7.0 is only available to developers. >bringing 2.0 into ANY argument is quite valid because of all the 3000 owners >that use it. when a Mac ships with ANY version of 7.0 then it too can be >brought into the fray of things. Gosh, after watching people use 2.0 for comparisons long before *IT* came out, it's great that you feel this way. I suppose this means that we also shouldn't mention future 040/etc cards for the A3000 cpu slot to others? Or coming video boards? Or? (ahem ;-) >> This kind of argument is a two-way street; and obviously >> nulls out within a fairly short period of time. cheers - kev Plus, I think we might agree that waiting until all arguments are "valid", would take some of the fun out of things. <grin>
peter@sugar.hackercorp.com (Peter da Silva) (01/28/91)
In article <1991Jan22.033011.21457@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: > I might also point out that AmigaWorld's #1 game of last year was > a European title, Shadow of the Beast, which I would hardly say was a quick > and easy program to do. I find it difficult to play, but not impossible. I don't know... the only guy I know who hasn't given up on it has been using the immortality hack. > I agree 100%. I don't like to cut anything from the design of the game, > especially for the sake of the operating system which does NOTHING for the > game. Sure does. Lets the game run on a 3000, to begin with. In fact I'd love a few decent ports of some of the old 8-bit games. You know, where they couldn't sell the sizzle but instead had to make the game itself attractive. You'll get a lot more playing time out of a good, simple, playable game like Tracers than a fancy, visually exciting, but unplayable game like anything Psygnosis has produced thus far. > I agree, too, and it seems as if a lot of publishers are going to off-disk > protection (look up a word in the manual, please). I have one game that uses "look up a word on the box" protection. I couldn't believe it! How many people keep the game packaging? > Honest people typically don't buy the cartridge devices you are talking > about. I don't know... I'm thinking of it. I've spent enough on $10 a pop replacement disks from Accolade to pay for it. Does anyone know if these replacements show up on the author's royalty statements? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/28/91)
Please... if you have to post to inappropriate groups at least direct followups somewhere better? In article <1991Jan23.094943.9336@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: > Rubbish! The OS steals around 100k, depending > on how many devices are attached, buffers etc. It is VERY tight getting > a game to fit in 512k! You usually have to page stuff off the > disk... Then you've probably written too much code. (god, once upon a time people actually write some fairly impressive programs on the Apple-II with only 48K available, and much of that taken up in the hi-res screen... how quickly we become spoiled) Let me just say that I *will* buy games that are less than balls-to-the-wall so long as they will run nicely. *AND* playability is given priority. > Yep. And you need lots of that nowdays. Yep. Gotta keep people from noticing that some clone of "Galaxians" is almost unplayable for anyone over 15. Oh well, at least this did force me to keep my 1000 when I got my 3000. Got too many badly behaved games to think of getting rid of it, and it *has* come in handy. :-< -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
navas@cory.Berkeley.EDU (David C. Navas) (01/29/91)
In article <1991Jan27.005727.1196@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > So the two tasks share the same address space/structures etc?? Do Sometimes. One of the unique Amiga things.... Of course, ALL programs share the same "address space" if I'm understanding you correctly :) >the commercially available programs on the Amiga actually DO this? >(e.g. the WordPerfect, Advantage, or whatever the WPs, SSs and DBs >are...) Well, I don't know about commercial packages, but my Jazzbench program is a *group* of co-operating processes. Base package requires four. And it usually works. Usually. Not bad for a package written without a knowledge of what a semaphore is... Under 1.3 it was a lot easier to insert GetMsg()s somewhere in your ray-tracing package. Under 2.0 I would not be surprised if such things became more prolific (that is multi-threaded packages). David Navas navas@cory.berkeley.edu "Excuse my ignorance, but I've been run over by my train of thought." -me [Senior EECS major, programmer for GeoWorks, author of JazzBench] (and Calvin)
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (01/29/91)
kdarling@hobbes.ncsu.edu (Kevin Darling) writes: >In <3889@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >>> Sidenote: I'm not sure why some mention that System 7 isn't out yet. >>> Amiga 2.0 isn't out yet for 500's, I thought. [me] >> >>BUT 2.0 *IS* available to 3000 owners. 7.0 is only available to developers. >>bringing 2.0 into ANY argument is quite valid because of all the 3000 owners >>that use it. when a Mac ships with ANY version of 7.0 then it too can be >>brought into the fray of things. > >Gosh, after watching people use 2.0 for comparisons long before *IT* >came out, it's great that you feel this way. I suppose this means that we >also shouldn't mention future 040/etc cards for the A3000 cpu slot to others? >Or coming video boards? Or? (ahem ;-) Hmmm.. you mean people were comparing 2.0 with other things before it was released? it seems to me that commodore had such a tight clamp on anything leaking out that when AmigaWorld reported that it wasn't going to be 1.4 but 2.0 everyone claimed they were lying. when it finally was announced it was a big shock to most of us, and was shipping with 3000's the next month. > >>> This kind of argument is a two-way street; and obviously >>> nulls out within a fairly short period of time. cheers - kev > >Plus, I think we might agree that waiting until all arguments are "valid", >would take some of the fun out of things. <grin> UUCP: {amdahl!bungia, crash}!orbit!pnet51!chucks ARPA: crash!orbit!pnet51!chucks@nosc.mil INET: chucks@pnet51.orb.mn.org
eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) (01/29/91)
--
=========================================================================
Eduardo Horvath eeh@btr.com
..!{decwrl,mips,fernwood}!btr!eeh
"Trust me, I am cognizant of what I am doing." - Hammeroideeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) (01/29/91)
In article <1991Jan27.005727.1196@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >peter@sugar.hackercorp.com (Peter da Silva) writes: > >>In article <1991Jan23.213736.28220@Neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan J Torrie) writes: >>> priority). But normally, the code to regenerate the window's view >>> (what I call an Update event) is located in the main word processor >>> task. >>A word processor would probably not be split up this way, because they don't >>tend to be compute bound. This would be more like a spreadsheet. >>Also, the display would be handled by the user-interface task. The compute >>task just updates internal tables... the display selects the portions of those >>tables the user wants to see and presents them. > So the two tasks share the same address space/structures etc?? Do >the commercially available programs on the Amiga actually DO this? >(e.g. the WordPerfect, Advantage, or whatever the WPs, SSs and DBs >are...) Yes, as a matter of fact WordPerfect does spawn several tasks. There is WordPerfect itself, the printer process, and the spell-checker/thesaurus. These are completely separate programs, and can be invoked separately. I often print out documents while editing text and percieve no slowdown in the interface at all. As a matter of fact, WordPerfect spawns a new task for each document that is being editted (a fact that wasn't easy to find because these tasks are called "kashmir". Wonder why.) I suppose that this means two users could both be running WordPerfect on the same machine concurrently, if the input re-direction problem could be solved. On the Amiga, all tasks share the same address space. Structure sharing is a more complicated question. In general, shared memory is not a good solution to the problem of inter-process communication because it makes programs unreasonably complicated. It becomes impossible to keep track of which task modified a location last, and makes debugging next to impossible. What's more important is that the tasks are sharing the same code. WP is implemented with a heavy reliance on dynamic libraries and lightweight threads, so several instances of WP editing different documents take up very little room. -- ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid
peter@sugar.hackercorp.com (Peter da Silva) (01/30/91)
I said: > Yes, you can set the priority of any shell or process. Unfortunately some > programs blithely override this. You can't easily reset it after one starts > up, but it *is* possible. This is, of course, false. You can easily reset it after starting the application. Next time, Peter, check the docs before posting. I will note, however, that I had forgotten this feature of changetaskpri because I'd never had to diddle with task priorities after startup. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/30/91)
In article <1991Jan27.214435.15976@Neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan J Torrie) writes: > Has anyone thought about adding VM/protection onto AmigaDos?? Is it > going to be a problem? Yes, and yes. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
kdarling@hobbes.ncsu.edu (Kevin Darling) (01/30/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes >> For example, I believe the Amiga OS was derived from Tripos? by Metacomco?. >> What was the original design decision behind the Amiga OS ancestors? > > AmigaDOS was apparently based on Tripos. This is the bit that does > things like normal file management, loading programs, etc. > There is another level to the OS that does the multitasking and > inter-process stuff, called Exec. This is not related to Tripos. I'm sure the CBM guys will let us know. But in the meantime, I thought y'all would be interested in part of a 1988 TRIPOS advertisement. <kdarling@catt.ncsu.edu> ---------------------------- begin quote ------------------------------- WHAT IS TRIPOS: The system was first developed some years ago in the University of Cambridge in the U.K. It was designed as a model of a classical operating system. In 1981 it was taken to the University of Bath where work had been started on a 68000-based system. TRIPOS was ported to this hardware. Three years later, METACOMCO acquired the rights and started a conversion which would be commercialized. This work was assisted by the CBM-Amiga in March 1985 when they chose the system as the kernel of their AmigaDOS. DESIGN PHILOSOPHY: Maximum response speed was a major design objective for TRIPOS. It is designed to have as few overheads as possible, resulting in a fast OS for realtime applications. Three areas where this philosophy is clearly demonstrated are scheduling, memory management and message passing. The scheduler adopts a strict task-priority system. There is no overhead for the time-slicing process required in a system using "round-robin" type scheduling. A task which is allocated processor time continues to run until a higher priority task is ready to run or until it suspends itself. In the area of memory management, kernel primitives are provided for allocating and freeing memory. No checking is done to stop a program using non-allocated space. By adopting this non-memory-management approach, all memory accesses can be executed as fast as the memory allows, avoiding any clock cycles inserted by an MMU. Clearly, the applications software writer has to ensure that programs are well-behaved. A similar philosophy is applied to the message-passing system. All communications within TRIPOS is done by sending and receiving packets. These packets are areas of memory containing the information and are passed by reference rather than copied. Is is because of the memory management philosophy that this method of message passing can be adopted, avoiding the unnecessary duplication of memory. KEY FEATURES: * True multitasking realtime OS * Small ROMMable code * Highly interactive and user friendly * Open architecture * Integrated debugger * Hierarchical filing system * RAM disk included * Device independent I/O * Support for windows ------------------------------ end quote -------------------------------
djohnson@beowulf.ucsd.edu (Darin Johnson) (01/31/91)
In article <7664@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Jan27.214435.15976@Neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan J Torrie) writes: >> Has anyone thought about adding VM/protection onto AmigaDos?? Is it >> going to be a problem? > >Yes, and yes. OK, here's an idea. Since a lot of the problems will result because some programs may not use MEMF_PUBLIC correctly, why not have a utility that allows only specified programs to run with VM/protection. For example: > runvm mytestprog -= Illegal Address Format @xxxxxx =- -= Terminating process =- -= We now return you to your regularly scheduled(ha) system =- >runvms swap=hd0:swap mytestprog2 -= Sorry, process attempted to send a message using private memory =- etc. I think this would simplify the task of trying to get VM to work with everything under the sun. What would be needed is a paging handler and setpatching of memory routines. If you want more than one VM task to run at once, or to work with other mmu utilities, then you have to make sure that the scheduler correctly switches context in the mmu when necessary. -- Darin Johnson djohnson@ucsd.edu - Political correctness is Turing undecidable.
jbickers@templar.actrix.gen.nz (John Bickers) (01/31/91)
Quoted from <1991Jan27.214435.15976@Neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan J Torrie): > Just as a matter of interest, it seems to me that this design would > be somewhat difficult to graft virtual memory/memory protection onto > without some serious backward compatibility problems... > Has anyone thought about adding VM/protection onto AmigaDos?? Is it > going to be a problem? I think VM is quite feasible, since it should be transparent to the system at quite a low level. Memory protection is quite different. Discussions on this have been held before, and I believe at least one person was working on adding VM. > Perhaps that may be best. My question was whether there have been > any studies done in this area. If you read all the classic OS design No idea. I've heard that people are looking harder at running distributed OSs, in which case the power available would make questions of interface speed moot. > For example, I believe the Amiga OS was derived from Tripos? by > Metacomco?. What was the original design decision behind the Amiga OS > ancestors? AmigaDOS was apparently based on Tripos. This is the bit that does things like normal file management, loading programs, etc. There is another level to the OS that does the multitasking and inter-process stuff, called Exec. This is not related to Tripos. > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (02/01/91)
Quoted from <1991Jan30.131318.18064@ncsuvx.ncsu.edu> by kdarling@hobbes.ncsu.edu (Kevin Darling): > jbickers@templar.actrix.gen.nz (John Bickers) writes > > There is another level to the OS that does the multitasking and > > inter-process stuff, called Exec. This is not related to Tripos. Oops. Can I take this back? :) I made the assumption that Exec != Tripos because of the BCPL/C differences apparent in the two parts of the system. > ---------------------------- begin quote ------------------------------- > > WHAT IS TRIPOS: The system was first developed some years ago in the -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
bartonr@eecs.cs.pdx.edu (bartonr) (02/02/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: > Oops. Can I take this back? :) I made the assumption that Exec != Tripos > because of the BCPL/C differences apparent in the two parts of the system. DOS is mostly BCPL, but Exec is, I believe, entirely or almost entirely written in assembler, not C. ================================================================================
davewt@NCoast.ORG (David Wright) (02/08/91)
Quoted from <1409@pdxgate.UUCP> by bartonr@eecs.cs.pdx.edu (bartonr): > DOS is mostly BCPL, but Exec is, I believe, entirely or almost entirely > written in assembler, not C. Actually, DOS is not BCPL anymore, although the old BCPL-style entry points are there for compatibility. Dave
stevep@wrq.com (Steve Poole) (05/10/91)
In article <1991Jan16.015035.10356@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >(Larry Rosenstein) at googy.apple.com writes: > >> Not true. For most applications, there is nothing special you have to >> do in order to yield the CPU. It is a normal part of processing user >> input. > >Bzzzzt! Wrong answer, but thank you for playing our game. > >Pausing for i/o is a separate consideration; the "cooperation" required >for cooperative multitasking is built into the OS i/o routines. Waiting >for i/o _is_ cooperating. It is the case of a routine that goes CPU >bound and doesn't bother to give back to the OS the chance to allow >another task to execute that differentiates cooperative from preemptive >multitasking. > I doubt that you need to explain multitasking nomenclature to Larry or any of us. Larry's point was that during the course of a typical application, the event loop is tripped through frequently enough for cooperative multitasking to proceed smoothly. An event loop in the midst of a computation intensive routine is no big deal, and a standard part of a responsive, well-behaved application. True, many things could be better. Bagging old models at the expense of application base can be done, if riskily. Multifinder does a fine job for the vast majority of users, despite lacking some of the features I'd really like to see. The world's full of tradeoffs. -- -------------------------------------------------------------------------- -- INTEL 80x86: Just say NOP -- Internet: stevep@wrq.com -- AOL: Spoole -- --------------------------------------------------------------------------
peter@sugar.hackercorp.com (Peter da Silva) (05/15/91)
In article <1991May10.010449.11340@milton.u.washington.edu> stevep@wrq.com (Steve Poole) writes: > of us. Larry's point was that during the course of a typical application, the > event loop is tripped through frequently enough for cooperative multitasking > to proceed smoothly. But it isn't. Observed behaviour: a Mac II (which certainly has the Amiga 1000 beat on horsepower) just doesn't run smoothly compared to the older Amigas. > An event loop in the midst of a computation intensive routine is no big deal, > and a standard part of a responsive, well-behaved application. Yes it is a big deal, and no it's not a standard part of any such thing. It's just something that Apple programmers have to do to keep the faith. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
stevep@wrq.com (Steve Poole) (05/16/91)
In article <1991May15.113621.22300@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >But it isn't. Observed behaviour: a Mac II (which certainly has the Amiga 1000 >beat on horsepower) just doesn't run smoothly compared to the older Amigas. > I didn't make any claims about relative smoothness. I've used a Mac II for years and find that in most cases it's smooth enough. There are plenty of crappy apps that DON'T cooperate, but there are plenty that do. >> An event loop in the midst of a computation intensive routine is no big deal, >> and a standard part of a responsive, well-behaved application. > >Yes it is a big deal, and no it's not a standard part of any such thing. It's >just something that Apple programmers have to do to keep the faith. Obviously the context was within a Mac application. No need to intentionally misinterpret. I've never found it to be particularly troublesome. Clearly, a preemptive solution would be preferable, but anyone with a modicum of intellect can cope. -- -------------------------------------------------------------------------- -- INTEL 80x86: Just say NOP -- Internet: stevep@wrq.com -- AOL: Spoole -- --------------------------------------------------------------------------
peter@sugar.hackercorp.com (Peter da Silva) (05/17/91)
In article <1991May15.171830.25748@milton.u.washington.edu> stevep@wrq.com (Steve Poole) writes: > In article <1991May15.113621.22300@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >But it isn't. Observed behaviour: a Mac II (which certainly has the Amiga 1000 > >beat on horsepower) just doesn't run smoothly compared to the older Amigas. > I didn't make any claims about relative smoothness. I've used a Mac II for > years and find that in most cases it's smooth enough. There are plenty > of crappy apps that DON'T cooperate, but there are plenty that do. I *am* making claims about relative smoothness. And your "smooth enough" would drive me crazy. Just as a Microsoft Windows user's "smooth enough" would drive you crazy. And we're each satisfied. > >> An event loop in the midst of a computation intensive routine is no big deal, > >> and a standard part of a responsive, well-behaved application. > >Yes it is a big deal, and no it's not a standard part of any such thing. It's > >just something that Apple programmers have to do to keep the faith. > Obviously the context was within a Mac application. Not obvious to me. > No need to intentionally > misinterpret. I've never found it to be particularly troublesome. Clearly, > a preemptive solution would be preferable, but anyone with a modicum of > intellect can cope. If I wanted to just "cope" I'd probably have an MS-DOS machine. It's a lot cheaper and from where I sit not a lot more painful than a Mac for programming. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.