kkirksey@eng.auburn.edu (Kenneth B. Kirksey) (01/12/91)
Can somebody please tell me why Apple has yet to implement TRUE multitasking in the system software? I know that it's really not that hard of a task, especially since the amiga has had it for quite some time. Is there a valid reason for not doing it? I'm really curious +---------------------------+------------------------------------------------+ | Ken Kirksey | "It's a small world, and it smells funny, | | Auburn University | I'd buy another if it wasn't for the money." | | kkirksey@eng.auburn.edu | -Andrew Eldritch | | | The Sisters of Mercy | +---------------------------+------------------------------------------------+
rudd@calvin.stanford.edu (Kevin Rudd) (01/16/91)
In article <48107@apple.Apple.COM> heksterb@Apple.COM (Ben Hekster) writes: >kkirksey@eng.auburn.edu (Kenneth B. Kirksey) asks: > >> Can somebody please tell me why Apple has yet to implement TRUE multitasking >> in the system software? I know that it's really not that hard of a task, >> especially since the amiga has had it for quite some time. Is there a valid ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> reason for not doing it? I'm really curious > Is the above supposed to imply that the Amiga only has things which are easy and that the Macintosh has all of the REAL hard stuff included in it? -- Kevin :-)
peirce@outpost.UUCP (Michael Peirce) (01/16/91)
In article <kkirksey.910112013111@lab12.eng.auburn.edu>, kkirksey@eng.auburn.edu (Kenneth B. Kirksey) writes: > > Can somebody please tell me why Apple has yet to implement TRUE multitasking > in the system software? I know that it's really not that hard of a task, > especially since the amiga has had it for quite some time. Is there a valid > reason for not doing it? I'm really curious It's obvious, Apple is trying to keep good technology out of the hands of their customers and make life harder for them (lots of :-)! ) Seriously, this has been beat into the ground before. Apple, for all its faults, tries very hard to protect its customer's software investment. This means that they don't try to break existing software (though they sometimes fail at this of course). This means that major changes in basic architecture are hard to do (you can't just take away GetNextEvent!). Another point is that the current, cooperative multitasking, WORKS VERY WELL FOR MOST USERS. Maybe it falls down if you want to run a ray tracer and compute pi to 10000000 places and still play solarian at the same time. But for the guy who wants to run Word and MacDraw and PageMaker concurrently it works great. Even more demanding users (like me :-) ) find it quite workable. For example, right now, using good old cooperative multitasking I'm running MacWrite II writing a letter. I have a clock blinking up in the right hand corner of the screen. I'm also running uAccess. It dials up another uucp machine every hour, transfers mail & news and signals me when there's something new. I can even be downloading a file using America Online at the same time using another serial line. All while I'm busily working on my letter. Sure seems like MultiTasking to me! Frankly, I rather they got FileSharing and TrueType fontsworking before they further improve their multitasking. -- michael -- Michael Peirce -- outpost!peirce@claris.com -- Peirce Software -- Suite 301, 719 Hibiscus Place -- Macintosh Programming -- San Jose, California 95117 -- & Consulting -- (408) 244-6554, AppleLink: PEIRCE
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/16/91)
In article <1991Jan15.183312.27926@maverick.ksu.ksu.edu> jxf@altair.cis.ksu.edu (Jerry Frain) writes: >Yes, yes, preemptive multiprogramming has been around for some 25 years >now, but Apple still hasn't figured out how to do it on the Mac (except >under A/UX -- but AT&T wrote the part of the OS that does the scheduling). At the very best you might be able to claim either that Apple hasn't found a way to do it on current Macs and remain compatible with the existing software base, or that Apple hasn't publicly released a solution yet. I'm pretty sure work on System 8 is going on in parallel with 7.0 and that 8.0 will have to be competetive with OSes that will be out by then. >And give Apple employees a way to divert attention away from the real >question, which is, > > "Why hasn't Apple implemented a preemptive multiprogrammming OS?" This question has already been answered. It doesn't do you any good to get a gnifty new OS if all your application software breaks. We live in a market economy and new advancements come out in spurts. >For me, the answer to this question is not important. If you have looked >at the Q&A list for System 7.0, the issue of preemptive multiprogramming >was barely addressed. It seems that Apple is now researching ways to >possibly provide this feature. This has been general knowledge for the last year and a half, if not longer. Again, I doubt that "Apple is [just] now researching ways...." >>Followup to: comp.sys.amiga.has.true.multitasking.na.naah.na.naah.naaah > >A very mature response. Glad you could help. Uhuh. Right.
jxf@altair.cis.ksu.edu (Jerry Frain) (01/16/91)
heksterb@Apple.COM (Ben Hekster) writes: >kkirksey@eng.auburn.edu (Kenneth B. Kirksey) asks: >> Can somebody please tell me why Apple has yet to implement TRUE multitasking >> in the system software? I know that it's really not that hard of a task, >> especially since the amiga has had it for quite some time. Is there a valid >> reason for not doing it? I'm really curious >Perhaps Mr. Kirksey will be so kind as to refer me to some computer science >literature where the term `true multitasking' is defined. "True multitasking" is not defined. However, it is readily apparent that Mr. Kirksey _is_ referring to "preemptive multiprogramming." Mr. Herkster apparently lacks the ability to infer what Mr. Kirksey was attempting to convey. > As it is, the term >seems only to serve the purpose of consoling insecure Amiga owners. The term also seems to serve the purpose of enabling Apple employees to direct the attention away from the issue. I don't know how many times I've seen a request like the original article, and a response by an Apple employee very similar to the article which I am following up to. Mr. Herkster's behavior is certainly not professional. >Followup to: comp.sys.amiga.has.true.multitasking.na.naah.na.naah.naaah How very mature. Thank you so much for your help. In answer to the original query, the System 7.0 Q&A list almost provides some insight as to Apple's plans for preemptive multiprogramming for the Mac. Some reference was made in the Q&A list to the fact that Apple is now researching preemptive multiprogramming for the Mac. However, I would much rather see protected memory mode enabled for those Macs which have memory management units installed, than preemptive multiprogramming. The Mac's "cooperative multiprogramming" is adequate. It _does_ allow me to download files in the background. Fortunately, downloading files is mostly all I need performed in the background, 'cause that's about all the Mac's cooperative multiprogramming is good for. I'd _really_ like to be able to compile my programs in the background. Fat chance. It is such a pain to reboot simply because I had a bad pointer in a program that went out and scrambled the OS. Protected mode would solve this problem. The lack of protected mode is extremely primitive, to say the least. Regards, --Jerry -- Jerry Frain -- Systems Programmer Kansas State University Department of Computing & Info Sciences Internet : jxf@cis.ksu.edu Manhattan, Kansas UUCP : ...!rutgers!ksuvax1!jxf
heksterb@Apple.COM (Ben Hekster) (01/16/91)
In a previous posting, I said: >> Perhaps Mr. Kirksey will be so kind as to refer me to some computer science >> literature where the term `true multitasking' is defined. jxf@altair.cis.ksu.edu (Jerry Frain) responds: > I believe that Mr. Kirksey is referring to what many of us label > "preemptive multiprogramming." Well, if that is what he meant, why didn't he just *say* it? The computer science field is extensive enough that we don't need to invent new terms to describe concepts for which perfectly good ones that have been in use for decades exist already, just to satisfy the egos of certain individuals..! `True' multitasking is a vague term which says nothing, and was obviously coined for its implication that other kinds of multitasking (depending on what you feel `true multitasking' means) must necessarily be `false'. Preemptive/nonpreemtive *says* something. > Yes, yes, preemptive multiprogramming has been around for some 25 years > now, but Apple still hasn't figured out how to do it on the Mac (except > under A/UX -- but AT&T wrote the part of the OS that does the scheduling). Presumably it would not be impossible to implement some sort of preemptive multitasking scheme for the Finder, but frankly I don't see the burning necessity for it. The Macintosh, under MultiFinder, already *has* multitasking. Without necessarily wanting to get into The Great Multitasking Debate again, let me just point out that non-preemptive multitasking also has its benefits--in the case of the Macintosh, the application that the *user* sends events to gets control of the processor. At the moment, I have MPW (compiling), MacBrowse and (obviously) Finder in the background, and I have no wish for them to preempt *me*. Having MPW suspend while I edit this message is fine. I am not debating the point that preemptive multitasking has advantages also--which is the better may be a matter of personal preference. As it is, the Macintosh's form of multitasking does satisfy my requirements, and there I really see little need to resort to multitasking-mudslinging. I also said: (uh oh) >> As it is, the term >> seems only to serve the purpose of consoling insecure Amiga owners. to which Jerry Frain responded: > And give Apple employees a way to divert attention away from the real > question, which is, > > "Why hasn't Apple implemented a preemptive multiprogrammming OS?" That's funny, I always assumed that `true multitasking' was invented to obscure `preemptive'. > For me, the answer to this question is not important. If you have looked > at the Q&A list for System 7.0, the issue of preemptive multiprogramming > was barely addressed. It seems that Apple is now researching ways to > possibly provide this feature. I agree that the question has little importance. Let me point out, though, that I am not a real Apple employee, but a student intern with his own personal opinions. > I would much, much rather see protected for the OS and all of the applications > than preemptive multiprogramming. Again, I agree, although even the benefits of protected-mode execution are also debatable. >> Followup to: comp.sys.amiga.has.true.multitasking.na.naah.na.naah.naaah > A very mature response. Glad you could help. No problem, dude.
long@mcntsh.enet.dec.com (Rich Long) (01/16/91)
In article <42554@ut-emx.uucp>, awessels@ccwf.cc.utexas.edu (Allen Wessels) writes... >programs. What exactly do you need your machine to do that "true" multitasking >would allow? Oh...let's see. How about being able to switch out of the Finder during copy operations or disk formatting? How about not having one's download wedge because a menu was held down too long? How about getting decent foreground performance with something running in the background that is not a "good citizen"? How about real print spooling? Richard C. Long * long@mcntsh.enet.dec.com * ...!decwrl!mcntsh.enet.dec.com!long * long%mcntsh.dec@decwrl.enet.dec.com
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/16/91)
In article <19019@shlump.nac.dec.com> long@mcntsh.enet.dec.com (Rich Long) writes: > >In article <42554@ut-emx.uucp>, awessels@ccwf.cc.utexas.edu (Allen Wessels) writes... >>programs. What exactly do you need your machine to do that "true" multitasking >>would allow? > > Oh...let's see. How about being able to switch out of the Finder during copy > operations or disk formatting? How about not having one's download wedge OK, I'm not a programmer, but I wonder if these can't be handled by the right software. They are real issues, but for how many users. Sometimes you just say "Uncle" to the law of diminishing returns. Just how much of the average user's time is occupied with these tasks? > because a menu was held down too long? How about getting decent foreground I think it is possible to increase the size of the serial port buffer to extend the amount of time you can hold the menu down. But really, just how long are you holding menus down? I download a LOT under MF and I've rarely had a download interrupted. Even then, many of those interruptions are due to line noise (I've watched happen occasionally when the term program is the only thing running.) > performance with something running in the background that is not a "good > citizen"? How about real print spooling? Every company that sells an OS has programming guidelines, and I'd guess that most of them will tell you the bets are off if the program is written in an OS-unfriendly fashion. What do you mean by real print spooling? You want a better spooler than Print Monitor? How about a better macro program than MacroMaker. A better backup program than HDBackup? Can you say 3rd party product?
heksterb@Apple.COM (Ben Hekster) (01/16/91)
awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > [...] What exactly do you need your machine to do that "true" multitasking > would allow? long@mcntsh.enet.dec.com (Rich Long) responds: > Oh...let's see. How about being able to switch out of the Finder during copy > operations or disk formatting? How about not having one's download wedge > because a menu was held down too long? How about getting decent foreground > performance with something running in the background that is not a "good > citizen"? How about real print spooling? But these things are basically unrelated to the type of multitasking involved. Non-preemptive multitasking implies some judgment on the part of the application programmer as to the desirability of relinquishing the processor at a given stage in the program. With preemptive multitasking these decisions are always made by a scheduler using some fixed algorithm. In my opinion, a well-written application has the potential of having a much finer and well-tuned use of the processor than probably most general schedulers. I am certainly not disputing that this requires more effort of the application programmer. As to your observation regarding the effect of menu operations (mouse drag operations in general) on background tasks--these are typically `high- intensity' operations that require high feedback fidelity, so suspending background applications seems the correct thing in these cases. Have you ever experienced mouse operations in preemptive multitasking environments? My experience with X Window on high-performance workstations (various window managers), for instance has been that feedback is frequently so *awful* (intermittent, or no reaction to mouse movements at all for periods on the order of many seconds) as to make complicated interactions extremely difficult. (No flame on X intended, just an observation on the workstation environment) If you want to experiment, you might try setting up MenuHook and DragHook to a little routine that calls WaitNextEvent, and see if performance is more to your liking. _______________________________________________________________________________ Ben Hekster | "I don't want to start any blasphemous | rumors/ but I think that God's got a AppleLink: heksterb | sick sense of humor/ and when I die Internet: heksterb@apple.com | I expect to find Him laughing" BITNET: heksterb@henut5 | --Depeche Mode [Some Great Reward]
jxf@orion.cis.ksu.edu (Jerry Frain) (01/16/91)
awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >In article <19019@shlump.nac.dec.com> long@mcntsh.enet.dec.com (Rich Long) writes: >>In article <42554@ut-emx.uucp>, awessels@ccwf.cc.utexas.edu (Allen Wessels) writes... >> Oh...let's see. How about being able to switch out of the Finder during copy >> operations or disk formatting? How about not having one's download wedge >OK, I'm not a programmer, but I wonder if these can't be handled by the right >software. They are real issues, but for how many users. Sometimes you just >say "Uncle" to the law of diminishing returns. This response sounds like it is coming straight out of the (_early_) 1960s. Please people! Get it straight, just this once. There is no reason to have to wait for a floppy disk to be formatted before I can use my hard disk. The technology to access two i/o devices simultaneously has been around (and in use) for more than twenty years. I'd like to access both of my drives (with different programs), now, please. I refuse "to say `Uncle'" to a primitive system which hampers my ability to be productive. I would rather enhance the existing system to suit my needs. > Just how much of the average >user's time is occupied with these tasks? I have an 80 MB drive. I don't have the money right now to invest in a tape backup system. I need to initialize ~seventy 1.40MB floppies so that I can back up my hard drive (no, I did not purchase already-formatted floppies). Now, would you care to calculate how much of my time will be spent formatting these seventy diskettes? Maybe _your_ average user does not require backups. Maybe _your_ average user has a tape backup system. However, this is the scenario presented to you by _this_ average user, who would like to use their time as productively as possible. I have to keep a book at my desk to read during disk formatting, compiles, unstuffs a StuffIt! file, etc. while my SE/30 is at the mercy of its currently-running program. >> performance with something running in the background that is not a "good >> citizen"? How about real print spooling? >Every company that sells an OS has programming guidelines, and I'd guess that >most of them will tell you the bets are off if the program is written in an >OS-unfriendly fashion. OS-unfriendly? Now there's a nifty term. A program should have to be "OS-friendly," that's a lot of what this whole discussion is about. A primary job of the typical operating system is to manage resources. Memory, disks, processes, etc. are all resources. If an OS cannot manage a resource effectively and efficiently, then that part of the OS should be enhanced so that it can manage the resource properly. > A better backup >program than HDBackup? Yup. I'd like to see one that compresses files as it backs them up. The standard hard disks are not getting any smaller. A simple system enhancement like providing a better back up utility would help many users. > Can you say 3rd party product? Sure, I can say that. And I'll get one, too, if you'll buy it for me. (Actually, I'll probably make my own, eventually). Regards, --Jerry -- Jerry Frain -- Systems Programmer Kansas State University Department of Computing & Info Sciences Internet : jxf@cis.ksu.edu Manhattan, Kansas UUCP : ...!rutgers!ksuvax1!jxf
fry@zariski.harvard.edu (David Fry) (01/16/91)
I love Mac's, I love MultiFinder, and I know the details of programming a Mac to approach "true multi-tasking" capabilities. I also use Unix GUI's with the correspondingly delayed user response to certain events, and I agree that's very annoying. As difficult as it may be to re-write the MacOS to allow pre-emptive multitasking, it is undeniable that this should be done, and everyone at Apple understands this, I think. Regardless of what CAN be done now to approximate the results of "true multi-tasking," there is no reason programmers should have to think about this. When downloading files, I have to plan how to use my Mac during that time so that I don't kill the download. I think Apple will come up with a solution to this problem that will be worth waiting for. In the meantime, however, please don't give us a snow job about how it's not necessary. David Fry fry@math.harvard.EDU Department of Mathematics fry@huma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
heksterb@Apple.COM (Ben Hekster) (01/16/91)
awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >Every company that sells an OS has programming guidelines, and I'd guess that >most of them will tell you the bets are off if the program is written in an >OS-unfriendly fashion. jxf@orion.cis.ksu.edu (Jerry Frain) responds: > OS-unfriendly? Now there's a nifty term. A program should have to be > "OS-friendly," that's a lot of what this whole discussion is about. > > A primary job of the typical operating system is to manage resources. > Memory, disks, processes, etc. are all resources. If an OS cannot manage > a resource effectively and efficiently, then that part of the OS should > be enhanced so that it can manage the resource properly. These are indeed all examples of system resources. Although the OS does manage resources, it is up to the application to use them wisely. An analog to the processor-preemptive multitasking system, we could have memory-preemptive multitasking too--use all the memory you want, but keep it too long, and the OS pulls the rug out from under your feet... Save documents on disk? Fine--but if some other application needs space on a full volume, the OS will automatically delete enough files to make room for it... Well, you get my drift. To me, processor non-preemption seems to make sense. In the same way, still my opinion of course, if an application programmer feels that the user will be best served by completing a certain task as quickly as possible without interference from other applications that may happen to be present, he can implement this. If the application is performing a lengthy task, it might relinquish processor time to allow its user to do something else in the meantime. Of course this means that bad programs (that do not call WaitNextEvent as often as they might) will hog processor resources. So will applications that make extravagant NewHandle calls hog memory resources (and some do!). _______________________________________________________________________________ Ben Hekster | "I don't want to start any blasphemous Student intern | rumors/ but I think that God's got a AppleLink: heksterb | sick sense of humor/ and when I die Internet: heksterb@apple.com | I expect to find Him laughing" BITNET: heksterb@henut5 | --Depeche Mode [Some Great Reward]
wwtaroli@rodan.acs.syr.edu (Bill Taroli) (01/16/91)
In article <kkirksey.910112013111@lab12.eng.auburn.edu> kkirksey@eng.auburn.edu (Kenneth B. Kirksey) writes: >Can somebody please tell me why Apple has yet to implement TRUE multitasking >in the system software? I know that it's really not that hard of a task, >especially since the amiga has had it for quite some time. Is there a valid >reason for not doing it? I'm really curious I think you've used just about one of the most vague terms in the comuting world. Multitasking, in the most general sense, simply means being able to get your computer to run multiple programs at the same time. MultiFinder does indeed do this, but (as with anyting) there are drawbacks. MF employs cooperative multitasking. This means that all applications must abide by one set of rules (Apple's) to ensure that everyone gets times to process. However, another serious problem (not specific to MF) in the Mac OS is that there is no memory protection between applications. Thus, if our two programs are running, and mine wants to write in your address space, it can do so without any problem whatsoever. Most other systems (esp. Unix) employ preemptive multitasking. This simply means that the OS is responsible for the scheduling of tasks. Depending upon the power of the machine, this can degrade performance of applications and result in sluggish user reponse (two reasons Apple may have chose not to go this route). Bringing up the Amiga is a real interesting thing here since there are many claims that multitasking is implemented primarily in hardware on that system. Although there are different chips specialize for different tasks (something Apple has yet to do effectively, in my opinion), this would neither support multitasking OR any form of parallelism in and of itself. Without support from the OS level for preemptive MT, the Amiga simply would not have the capability. It's difficult not to start comparing hardware in these cases, but it should recognized that hardware is _not_ the source of multitasking... it is software (the OS, or the Appls). Thus, in a broad sense, the answer to your query is that the Mac already does multitasking. It just doesn't do it the same way as the Amiga. There is really no claim one way or the other which is best, as circumstances may cause one to perform better than the other. So, Apple's decision to the MF route (although possibly due to minimal work on their part) was based on the overal goals of the interface (quick response to user events, and giving priority to the foreground application). -- ______ Bill Taroli -- Syracuse University | "The only thing necessary for \ PT / | the triumph of evil is for \ / Internet: wwtaroli@rodan.acs.syr.edu | good men to do nothing." \/ BITNET: wwtaroli@sunrise.acs.syr.edu | -- Edmund Burke
krk@cs.purdue.EDU (Kevin Kuehl) (01/16/91)
In article <1991Jan16.005818.3521@rodan.acs.syr.edu> wwtaroli@rodan.acs.syr.edu (Bill Taroli) writes: >to perform better than the other. So, Apple's decision to the MF route > (although possibly due to minimal work on their part) was based on I don't know if I am giving Apple too much credit, but I think they probably realized that preemptive scheduling would make a 68000 dinosaur slow. I worked on an SE for a few months last semester and I don't think I would ever want preemptive multitasking on it. Maybe if Apple's product line consisted totally of machines with 50Mhz 030's or 040's, they should use preemptive multitasking, but it doesn't. -- Kevin Kuehl krk@cs.purdue.edu kuehlkr@mentor.cc.purude.edu
jjwcmp@isc.rit.edu (Jeff Wasilko) (01/16/91)
In article <19019@shlump.nac.dec.com> long@mcntsh.enet.dec.com (Rich Long) writes: >In article <42554@ut-emx.uucp>, awessels@ccwf.cc.utexas.edu (Allen Wessels) writes... >>programs. What exactly do you need your machine to do that "true" multitasking >>would allow? > > Oh...let's see. How about being able to switch out of the Finder during copy > operations or disk formatting? How about not having one's download wedge > because a menu was held down too long? How about getting decent foreground > performance with something running in the background that is not a "good > citizen"? How about real print spooling? Or how about importing a 100 pages or so of text into one XPress document while working on another, while exporting data from a database... Does anyone know if MachTen supports more 'preemptive' multitasking than MultiFinder? I'd love to be able to switch from one app to another without waiting for the Mac to let me do it at it's convenience... Jeff -- | RIT VAX/VMS Systems: | Jeff Wasilko | RIT Ultrix Systems: | |BITNET: jjwcmp@ritvax +----------------------+ INET:jjwcmp@ultb.isc.rit.edu| |INTERNET: jjwcmp@ritvax.rit.edu |____UUCP:jjwcmp@ultb.UUCP____| |'claimer: I speak only for myself. Opinions expressed are NOT those of RIT.|
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/16/91)
In article <1991Jan15.233452.1163@maverick.ksu.ksu.edu> jxf@orion.cis.ksu.edu (Jerry Frain) writes: >I have an 80 MB drive. I don't have the money right now to invest in a >tape backup system. I need to initialize ~seventy 1.40MB floppies so >that I can back up my hard drive (no, I did not purchase already-formatted >floppies). > >Now, would you care to calculate how much of my time will be spent >formatting these seventy diskettes? Maybe _your_ average user does >not require backups. Maybe _your_ average user has a tape backup >system. However, this is the scenario presented to you by _this_ >average user, who would like to use their time as productively as >possible. I recommend you switch to a backup program that formats as it backs up, and I'd also recommend you reconsider backing up the entire drive to diskette. Unless all 80 meg is data, you can probably get by with a simple data backup, and from then on just do incrementals. If you have to back up that 80 to floppy, you better think about getting anohter 70 HD diskettes. Floppy backups can be a pain if the master disk goes bad, and I don't even want to think about recovering the sucker. >I have to keep a book at my desk to read during disk formatting, compiles, >unstuffs a StuffIt! file, etc. while my SE/30 is at the mercy of its >currently-running program. Can't help with the formatting and compile, but you might switch compression programs. Compactor does its biz just fine in the background. >Yup. I'd like to see one that compresses files as it backs them up. >The standard hard disks are not getting any smaller. A simple system >enhancement like providing a better back up utility would help many >users. No, but removeable media are getting cheaper. Note that floppy sizes aren't expanding at the same rate that hard disks are becoming affordable. (The 20 meg flopticals may throw a wrench into that curve.) Apple has limited resources. Outline fonts will benefit more users than your backup program will. You can't please all of the people all of the time. >> Can you say 3rd party product? > >Sure, I can say that. And I'll get one, too, if you'll buy it for me. If Apple is required to supply full-fledged versions of all those utility programs, YOU will pay for it. Apple already charges a premium to run its OS, and I'm amazed that someone is lining up to pay that much more for utilities that can be had inexpensively from hungry 3rd party developers.
teener@apple.com (Michael Teener) (01/16/91)
In article <1991Jan15.233452.1163@maverick.ksu.ksu.edu> jxf@orion.cis.ksu.edu (Jerry Frain) writes: > Yup. I'd like to see one that compresses files as it backs them up. > The standard hard disks are not getting any smaller. A simple system > enhancement like providing a better back up utility would help many > users. Well, I use 5th Generation's Fastback II as my primary backup system and it: 1) Compresses and formats as it backs up. 2) Runs nicely in the background, and can be scheduled to start up at a regular time .... and if you have PowerKey, you can use that to turn your system on to start the backup. 3) Uses Appleshare volumes, diskettes, tapes, or other hard disks as a backup media. Have you noticed that HDbackup isn't on the system disks any more? The 3rd parties do a great job. Why should we mess up their market? ---- Michael Teener -- 408-974-3521 ---------------------------------+ ---- Internet teener@apple.com, AppleLink TEENER | ---- Apple may know my opinions, but *I* am responsible for them | ---------------------------------------------------------------------+ Transportation by Cheetah N9900U, a loyal beast for the past 7.5 years.
n67786@lehtori.tut.fi (Nieminen Tero) (01/16/91)
In article <48134@apple.Apple.COM> heksterb@Apple.COM (Ben Hekster) writes:
These are indeed all examples of system resources. Although the OS does
manage resources, it is up to the application to use them wisely.
An analog to the processor-preemptive multitasking system, we could have
memory-preemptive multitasking too--use all the memory you want, but
keep it too long, and the OS pulls the rug out from under your feet...
Save documents on disk? Fine--but if some other application needs space
on a full volume, the OS will automatically delete enough files to make
room for it... Well, you get my drift. To me, processor non-preemption
seems to make sense.
In the same way, still my opinion of course, if an application programmer
feels that the user will be best served by completing a certain task as
quickly as possible without interference from other applications that may
happen to be present, he can implement this. If the application is
performing a lengthy task, it might relinquish processor time to allow its
user to do something else in the meantime.
Isn't it exactly same wether the OS or the programmer gets the decisision
on things like this. BTW, how is the programmer to know he's program is
more important than some other program, let alone make the decision. Let
the user choose and give us preemptive multitasking and controll over
cpu time usage.
--
Tero Nieminen Tampere University of Technology
n67786@cc.tut.fi Tampere, Finland, Europemacman@wpi.WPI.EDU (Chris Silverberg) (01/16/91)
In article <1991Jan15.233452.1163@maverick.ksu.ksu.edu> jxf@orion.cis.ksu.edu (Jerry Frain) writes: >I have an 80 MB drive. I don't have the money right now to invest in a >tape backup system. I need to initialize ~seventy 1.40MB floppies so >that I can back up my hard drive (no, I did not purchase already-formatted >floppies). I occasionally use the primitive HDBackup program to do backups... it will automatically format the floppy if it is not formatted already. I would imagine most backup programs do this... i'd advise looking at alternative backup programs if yours does not have this capability. >Now, would you care to calculate how much of my time will be spent >formatting these seventy diskettes? Maybe _your_ average user does >not require backups. If you backup a hard drive, your disks will be formatted ONCE. Subsequent backups do NOT require reinitializing the disk. This seems to be a pretty shallow argument. Oh yes, i format 70 disks a day. >Yup. I'd like to see one that compresses files as it backs them up. >The standard hard disks are not getting any smaller. A simple system >enhancement like providing a better back up utility would help many >users. Try Compactor... never used it as a backup program myself, but I've heard that it works pretty well. - Chris =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Chris Silverberg INTERNET: macman@wpi.wpi.edu Worcester Polytechnic Institute Main Street USA 508-832-7725 (sysop) America Online: Silverberg WMUG BBS 508-832-5844 (sysop) "Ask me about TeleFinder... A Macintosh BBS with a Macintosh interface"
ml27192@uxa.cso.uiuc.edu (lanett mark) (01/17/91)
jxf@altair.cis.ksu.edu (Jerry Frain) writes: >It is such a pain to reboot simply because I had a bad pointer in a >program that went out and scrambled the OS. Protected mode would >solve this problem. The lack of protected mode is extremely primitive, >to say the least. I agree completely! Forget pre-emptive stuff (at least for a while), just get to the point where you can isolate programs so they don't screw up the rest of the system. I would love to get A/UX just for this ability. Mark Lanett
long@mcntsh.enet.dec.com (Rich Long) (01/17/91)
In article <0B010004.4ldrhg@outpost.UUCP>, peirce@outpost.UUCP (Michael Peirce) writes... >[about Apple doing well protecting software investment] > >Another point is that the current, cooperative multitasking, WORKS >VERY WELL FOR MOST USERS. Maybe it falls down if you want >to run a ray tracer and compute pi to 10000000 places and still play >solarian at the same time. But for the guy who wants to run Word >and MacDraw and PageMaker concurrently it works great. Since I'm feeling conciliatory, I'll agree. And it's great that Apple does such a good job with backward compatibility. But there are places where "less cooperative" multitasking would be appreciated, such as (as I've said before) copying files and formatting disks. It would really be nice, too, if holding down a menu didn't take over the machine. But these are relatively minor annoyances, overall. Beats having to write a CONFIG.SYS! But let's not start THAT discussion ;-). Richard C. Long * long@mcntsh.enet.dec.com * ...!decwrl!mcntsh.enet.dec.com!long * long%mcntsh.dec@decwrl.enet.dec.com
long@mcntsh.enet.dec.com (Rich Long) (01/17/91)
In article <48122@apple.Apple.COM>, heksterb@Apple.COM (Ben Hekster) writes... >Have you ever >experienced mouse operations in preemptive multitasking environments? My >experience with X Window on high-performance workstations (various window >managers), for instance has been that feedback is frequently so *awful* >(intermittent, or no reaction to mouse movements at all for periods on the >order of many seconds) as to make complicated interactions extremely >difficult. (No flame on X intended, just an observation on the workstation >environment) Surely have. I use X windows on a VAX 3100 every day. Mouse response is immediate in just about all cases. And I can hold down menus all day! Look, to some extent, we're comparing two very different environments. I was merely pointing out that some operations on the Mac could benefit from preemptive multitasking, in my opinion. This is not to say that I am dissatisfied with MultiFinder! In fact, I think Apple did a very good job in grafting multitasking into an environment that was not designed for it. For 90% of what I do, it's fine. But when I have to format a bunch of disks...arrgh! Richard C. Long * long@mcntsh.enet.dec.com * ...!decwrl!mcntsh.enet.dec.com!long * long%mcntsh.dec@decwrl.enet.dec.com
lsr@Apple.com (Larry Rosenstein) (01/17/91)
In article <42602@ut-emx.uucp>, awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > > Can't help with the formatting and compile, but you might switch compression > programs. Compactor does its biz just fine in the background. MPW tools (including the compiler) run nicely in the background. In fact, it is very easy to take some generic C utility and make it run in the background under MPW.
peter@viewlogic.COM (Peter Colby) (01/17/91)
In article <N67786.91Jan16074115@lehtori.tut.fi>, n67786@lehtori.tut.fi (Nieminen Tero) writes: |> Isn't it exactly same wether the OS or the programmer gets the decisision |> on things like this. BTW, how is the programmer to know he's program is |> more important than some other program, let alone make the decision. Let |> the user choose and give us preemptive multitasking and controll over |> cpu time usage. It's important to remember that a preemptive scheduler has a definite idea on the importance of particular program getting the CPU - and that this prioritization has actually been determined by the implementor of the scheduler. No scheduler is the best of all things to all programs and most implementations can only deal efficiently with certain types of utilization profiles. The whole idea behind MultiFinder is in fact that the USER determine what program gets to run the must - by bringing that program to the forground. And the whole concept of being MultiFinder friendly is that your program check frequently for user input. Even if only one program is running is still has to respond to user generated events at reasonable intervals. Forground<=>Background switching is merely a side effect of the event-loop process. Peter C -- (O)(O)(O)(O)(O)(O)(O)(O)(O) (O)(O)(O)(O)(O)(O)(O)(O)(O) (O) !the doctor is out! (O) (0) peter@viewlogic.com (0) (O)(O)(O)(O)(O)(O)(O)(O)(O) (O)(O)(O)(O)(O)(O)(O)(O)(O)
doner@henri.ucsb.edu (John Doner) (01/18/91)
In article <19063@shlump.nac.dec.com> long@mcntsh.enet.dec.com (Rich Long) writes: > But there are places where "less > cooperative" multitasking would be appreciated, such as (as I've said before) > copying files and formatting disks. I'll allow that pre-emptive multitasking might be useful for some things. But I wonder how much help it would be when it comes to disk activity. The disk driver must turn off interupts for fairly long periods for physical reasons. This is why mouse movement becomes erratic while the floppy drive is running. I don't know the details of how formatting programs work, but couldn't asynchronous calls be used to make the process more friendly? If that isn't true, then I don't believe preemptive multitasking would make any difference. John E. Doner doner@henri.ucsb.edu (805)893-3941 Dept. Mathematics, UCSB, Santa Barbara, CA 93106
drew@everexn.com (Drew Rogge) (01/19/91)
In article <11745@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: >MPW tools (including the compiler) run nicely in the background. In fact, >it is very easy to take some generic C utility and make it run in the >background under MPW. Does anyone know if there is a function that an MPW tool can call which will yield control of the CPU for a while to give other tasks a chance to run? I ported Dave Buck's raytracer, DKBTrace, to run as an MPW tool but the response time of the system was horrible when it was running. The program is very compute bound and doesn't call out to the system very often. On the issue of preemptive vs. cooperative multitasking, it seems to me that only the OS really knows what's going on in the entire system. I imagine that there's a lot of time wasted by tasks interrupting their operation just to give the operating system a chance to check if there's anything else to do. One thing to remember is that preemptive multitasking does not necessarily mean that every task gets allotted equal slices of time in a round-robin fashion. There are many methods for tasks which don't have anything to do to cause themselves to be temporarily removed from the scheduling queue. It is also possible for "foreground" task(s) to be allocated a larger percentage of the system resources. I could be wrong, but I think that one problem with implementing preemptive multitasking on a Mac are sections of "critical" code in applications which occur when the low memory globals are being accessed or modified. Drew Rogge drew@everexn.COM
roger@grenada.UUCP (Roger Corman) (01/19/91)
In article <1991Jan15.191249.28750@maverick.ksu.ksu.edu> jxf@altair.cis.ksu.edu (Jerry Frain) writes: >I'd _really_ like to be able to compile my programs in the background. > >Fat chance. > I compile my MPW (C, C++) programs in the background all the time. Being able to run other programs allows me to keep my sanity through *long* C++ compiles. ------------------------------ Roger Corman Island Graphics 149 Stony Circle, Suite 200 Santa Rosa, CA 95401 (707)523-4465 {uunet,sun,ucbcad!island!roger} class Disclaimer { private: ObscureStuff employerOpinions; public: UsefulAdvice myOpinions[MAXINT]; };
dickie@schaefer.math.wisc.edu (Garth Dickie) (01/20/91)
In article <mnlbh2.]f8@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.sys.mac.system, article <48122@apple.Apple.COM>, > heksterb@Apple.COM (Ben Hekster) writes: >< >< If you want to experiment, you might try setting up MenuHook and >< DragHook to a little routine that calls WaitNextEvent, and see if performance >< is more to your liking. >< >Won't work. > >When an application gets background time, it may want to draw on the screen. >If your menu is directly over one of its windows, your menu will get severely >clobbered. > >The application may also want to add menus, and there _might_ be reentrancy >problems with the Menu Manager. > Just a side note: I tried this sort of thing once, just for kicks. It appears in a program called gadlife that never made it very far... You are right in that you can't call waitnextevent. But your own application can do some processing during the menu drags. There is not really a problem with response time if you take no more than a tick each time you get control, and the effect can be quite striking, if you do the extra work required to display properly while there is a menu onscreen: - capture the copybits from the screen done by the menu manager, so that you know the rectangle containing the menu. - every time you display, clip to the menu which is visible - capture the copybits *to* the screen, and update the contents of the bit/pix map to reflect your modified windows. there are two problems with this (besides the obvious 'dont patch traps'). First, there are heierarchical menus: gadlife handled this correctly. You simply keep a stack of information, etc; it all works out. The other is more subtle: if you are low on memory, the menu manager may not call copybits, accumulating update events instead. gadlife didn't handle this correctly, but I'm sure it would be possible. There are other problems with the whole approach: if something reflected in a menu item changes status during a menu selection, the menu should change, right? much violence is done to the user interface :-) Perhaps multifinder could (on request) send 'don't touch the screen' null events during screen muckiness. This would be appropriate for faceless tasks, for instance. -- ------------------------------------------------------------- Garth A. Dickie dickie@macduffe.math.wisc.edu
peirce@outpost.UUCP (Michael Peirce) (01/20/91)
In article <1991Jan18.195343.6636@everexn.com>, drew@everexn.com (Drew Rogge) writes: > > In article <11745@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: > >MPW tools (including the compiler) run nicely in the background. In fact, > >it is very easy to take some generic C utility and make it run in the > >background under MPW. > > Does anyone know if there is a function that an MPW tool can call which will > yield control of the CPU for a while to give other tasks a chance to run? > I ported Dave Buck's raytracer, DKBTrace, to run as an MPW tool but the > response time of the system was horrible when it was running. The program > is very compute bound and doesn't call out to the system very often. Look in the files CursorCtl.p in the PInterfaces (or the C equivalent). The following routines are declared there: InitCursorCtl(newCursors) - Init CursorCtl to load the 'acur' resource RotateCursor(counter) - Sequence through cursor frames for counter mod 32 SpinCursor(increment) - Sequence mod 32 incrementing internal counter Hide_Cursor() - Hide the current cursor Show_Cursor(cursorKind) - Show the cursor Every time you call these routines, MPW yields CPU time too. It even handles command-. for canceling the tool execution. -- michael -- Michael Peirce -- outpost!peirce@claris.com -- Peirce Software -- Suite 301, 719 Hibiscus Place -- Macintosh Programming -- San Jose, California 95117 -- & Consulting -- (408) 244-6554, AppleLink: PEIRCE
gwills@maths.tcd.ie (Graham Wills) (01/21/91)
In article <1991Jan15.191249.28750@maverick.ksu.ksu.edu> jxf@altair.cis.ksu.edu (Jerry Frain) writes: >However, I would much rather see protected memory mode enabled for those >Macs which have memory management units installed, than preemptive >multiprogramming. Yes! >I'd _really_ like to be able to compile my programs in the background. > >Fat chance. What's the problem? I do this nearly all the time. There are a lot of programs that usefully work in the background apart from downloading files. Compaction programs work (good). Excel re-calculates (not often necessary) Printers print (necessary). I write simulations for my Ph.D that run in the background, and auto-start after a reboot. It's no problem. Not to mention the host of clocks, load average plotters, etc. that are just plain fun