papa@pollux.usc.edu (Marco Papa) (05/11/89)
This is quoted from the May 10th, 1989 issue of the Wall Street Journal: "Apple yesterday unveiled an ambitious plan to improve the operationg system of its popular Macintosh personal computer. ... Apple didn't give any target dates for shipping of the new software, called System 7.0 ... Apple promised to ship software-development versions of the new operating system later this year, but stopped short of setting a date when shipment to customers will begin. ... The only hitch is that owners of older machines [mac+] will have to double the standard memory to two megabytes, a modification that currently would cost $400. ... System 7.0 will allow computer users to easily plug Macintosh computers into printers and plotters made by other companies [besides Apple]. ... Many of the features of System 7.0 are direct response to widely publicized features of OS/2 and Unix. For example, OS/2 .. allows different programs, such as a spreadsheet, database and communication program, to update one another with fresh information automatically [a very "interesting" way of defining multitasking]. System 7.0 will also allow that". Interesting. I have been using a system with such features, an Amiga, since 1985. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
res12@snoopy.UMD.EDU (Matthew T. Russotto) (05/11/89)
Why were followups directed to comp.sys.amiga? In article <17148@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: > >This is quoted from the May 10th, 1989 issue of the Wall Street Journal: > > [stuff about System 7.0 multitasking] > >Interesting. I have been using a system with such features, an Amiga, since >1985. > >-- Marco Papa 'Doc' >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu > "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Interesting. I have been using such a system since 1984-- A Lisa 2/10 running Lisa Office System. -- DISCLAIMER: Not only does the University not share my opinions, they don't want me sharing my opinions. "This 'Pnews', what does it do?" Matthew T. Russotto res12@snoopy.umd.edu (this semester only)
daveh@cbmvax.UUCP (Dave Haynie) (05/12/89)
in article <11276@polyslo.CalPoly.EDU>, dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) says: > In article <17152@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >>Interesting. My spreadsheet, database and comm program support both clipboard >>and AREXX. I can fire up my comm program from the database phonebook, >>include downloaded data in the spreadsheet or database, while I am editing >>something else at the same time. > But it's their own clipboard protocol, not a standard OS protocol. There is a clipboard.device which is standard on the Amiga. Perhaps a more draconic (eg, like Apple) approach to those applications that don't use it would have been a good move way back when. Another part of the problem is that a simple, Mac-like clipboard, isn't sufficient to a system with lots of different things running, any one of which could get clipped out of asynchronously with an application being pasted into. > I can do all of the above under Multifinder, so it's really no big > deal. You can launch Excel, SmartCom, MPW, and MacWrite and have a download > going on in Smartcom while doing something in excel. AREXX is not a clipboard protocol, it's something quite different. Can you write a MacWrite macro that instructs SmartCom to fetch a table of numbers from it's host, feed 'em to Execl for computation with some other numbers, and then read them into your MacWrite session? That's the kind of thing that AREXX is good for. > At least it's planned, announced and supported. > Apple's moving forward with the OS addressing problems and limitations while > trying to maintain compatibility with over 5000 S/W packages. Well, a good number of those limitations were missing from the 1.0 release of the Amiga OS (though 1.0 was full of bugs, which should be a familiar event to anyone who uses the first release of any new Mac system). The Amiga's OS has a number of areas to work on that Apple got right the first time. For the kinds of things I, personally, need, the Amiga feature set gives me a useful computer, the Mac really doesn't. I can't answer for anyone else... > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|///////////////////////////////////////// > David M. O'Rourke____________________|_____________dorourke@polyslo.calpoly.edu > | It's only 1's & 0's, so how difficult can Computer Science be? | > |:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
papa@pollux.usc.edu (Marco Papa) (05/13/89)
In article <18268@cup.portal.com| thad@cup.portal.com (Thad P Floryan) writes: |Re: the Version 7.0 of the Macintosh System Software article in WSJ ... |Another perspective appeared on page D-1 of the San-Jose Mercury-News, |Wednesday, May 10, 1989, reprinted here in its entirety without permission and |WITH all the typos, misspellings and misteaks (sic :-) of the original article. [...] | APPLE OFFERS PEAK (sic) AT LATEST SOFTWARE | By Rory J. O'Oconnor | Mercury News Computing Editor |Apple Computer Inc., aiming to keep pace in the desk-top computer market, |disclosed Tuesday details of a new version of the principal software for its |Macintosh computer line. |The software will give the company's computers some of the advanced capabilities |of rival operating systems offered by International Business Machines Corp. and |many work-station vendors. |Version 7.0 of the Macintosh System Software will improve the computer's ability |to run several programs at once, a process known as multi-tasking. [...] |'Tis sad when publications such as the WSJ and S-J M-N print "articles" that |have NOT been well researched and are obviously more a "press release" than |a news story. The S-J M-N is notorious for its shoddy reporting during the ^^^^^^^^^^^^^^^^ |past 3 years (and 3 editors of the Computing Section); not a good image for |the "premiere" newspaper of Silicon Valley. Has it has been explained in comp.sys.mac by Apple personnel, System 7.0 does NOT provide any changes that allow true multi-tasking: System 7.0 will still rely on MultiFinder. Apple can try to fool end-users into thinking that MultiFinder provides multitasking, but I don't think anybody on Usenet will ever believe that. If you do, may I suggest you pick up ANY Operating Systems book. It might be very educational. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
mackay@iisat.UUCP (Daniel MacKay) (05/13/89)
In article <8905110108.AA02057@snoopy.UMD.EDU>, res12@snoopy.UMD.EDU (Matthew T. Russotto) writes: > > In article <17148@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: > > > > [stuff about System 7.0 multitasking] > > > >Interesting. I have been using a system with such features, an Amiga, since > >1985. > > Interesting. I have been using such a system since 1984-- > A Lisa 2/10 running Lisa Office System. Yeah, this always makes me laugh. Imagine, if you will, the day when the Mac O/S has features like... - pipes, timers, multitasking. - a soft power switch that suspends all Multifinder processes and brings them all back up when you power back up the next day, exactly as you left them. - Parameter RAM backed up onto harddisk on shutdown, and CRC checked on startup, restored from harddisk if it's damaged. - elegant recovery from system errors. - a selftest that - repairs damage to files (caused, say, by a power failure during a write) automatically on powerup. - finds damaged applications and asks for their replacement. - finds damaged chunks of the O/S and asks for the proper system floppy disks so it can repair itself. - hard-disk-icon drag to floppy that automatically segments things, and reconstructs them in the other direction. - &c. &c. Naaah. Apple could never build such an advanced system. :-) SIX YEARS AGO, PEOPLE! SIX YEARS! It's so hard to see the Mac O/S as anything but a pathetically emasculated Lisa O/S. Aah well, someday, it will catch up. -dan -- +---------+ From the IIS Public Usenet | _ | disk of Halifax, Nova Scotia | (_)===| Daniel mackay@iisat.UUCP | | ...{utai,uunet,watmath}!dalcs!iisat!mackay +---------+ MACKAY@DALAC.BITNET
amanda@intercon.UUCP (Amanda Walker) (05/14/89)
In article <17183@usc.edu>, papa@pollux.usc.edu (Marco Papa) writes: > ... Apple can try to fool end-users into thinking that > MultiFinder provides multitasking, but I don't think anybody on Usenet > will ever believe that. If you do, may I suggest you pick up ANY Operating > Systems book. It might be very educational. > > -- Marco Papa 'Doc' Oh, come off it. If you actually *read* a good OS textbook, you'll discover that (listen carefully now) multitasking is a general concept, and has nothing to do with either providing separate address spaces for each process, or providing preemptive task switching. Both of these are useful techniques in many contexts, but they are not necessary conditions for multitasking. There are machines that provide one, both, or neither of these services, while still doing multitasking. There are machines that provide preemptive task switching in one big happy address space (some Lisp machines, for example). There are some that provide both heavyweight (protected) and lightweight (non-protected) processes at the same time (can you say "threads"? I knew you could). Memory protection and preemptive task switching would help the Mac in one basic way: they would enhance reliability, since a bug in a program would only kill that particular process. This is not the same issue as whether or not MultiFinder is "real" multitasking. Grumble. -- Amanda Walker <amanda@intercon.UUCP>
norman@a.cs.okstate.edu (Norman Graham) (05/16/89)
From article <17183@usc.edu>, by papa@pollux.usc.edu (Marco Papa): > Apple can try to fool end-users into thinking that > MultiFinder provides multitasking, but I don't think anybody on Usenet > will ever believe that. If you do, may I suggest you pick up ANY Operating > Systems book. It might be very educational. May I be so bold as to suggest Harvey Deitel's "An Introduction to Operating Systems" Revised First Edition for a discussion of preemptive vs. nonpreemptive scheduling. This is a very popular operating systems text used to teach thousands of computer scientists every year. If Dr. Deitel has no problem with this issue, I see no reason why I should. BTW, I plead with all intelligent computerists to cease to use the term "TRUE MULTITASKING". If by "true multitasking" you mean multitasking with preemptive job scheduling (or preemptive multitasking) by all means say this. I'm convinced that the phrase "true multitasking" was invented by a computer-illiterate computer-journalist who didn't know how to effectively contrast preemptive and nonpreemptive scheduling. A system is either multitasking or it is not, there is no reason to qualify it with extra adjectives. Geesh... next thing you know we'll have "kinda sorta multitasking", "really true multitasking", "truly true multitasking", ad. nausea. (Next week, I'll tell you why I find the phrase "look and feel" equally repulsive :-) (BTW, if "true multitasking" is an illusion of multiprocessing, is "false multitasking" an illusion of "true multitasking" an illusion of multiprocessing?) > -- Marco Papa 'Doc' > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu > "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- Norman Graham Oklahoma State University Internet: norman@a.cs.okstate.edu Computing and Information Sciences UUCP: {cbosgd, rutgers} 219 Mathematical Sciences Building !okstate!norman Stillwater, OK 74078-0599
gillies@p.cs.uiuc.edu (05/16/89)
/* Written 8:40 am May 13, 1989 by mackay@iisat.UUCP in p.cs.uiuc.edu:comp.sys.mac */ >Yeah, this always makes me laugh. Imagine, if you will, the day when >the Mac O/S has features like... > > [Many advanced O/S features] > .. > Naaah. Apple could never build such an advanced system. :-) SIX YEARS > AGO, PEOPLE! SIX YEARS! It's so hard to see the Mac O/S as anything but > a pathetically emasculated Lisa O/S. Aah well, someday, it will catch up. You neglect to mention that Amiga is nowhere when it comes to a having an *extendible* *standardized* graphics engine with 32-bit color and a picture description language, and well-integrated networking facilities. Don't get me wrong -- I'd like to see more amiga features in the macintosh, esp. a more robust & self-repairing file system. But let's stop this whining about not having feature X when apple is clearly investing a heavy amount of development in features Y,Z and succeeding in bringing it to the marketplace.
casseres@apple.com (David Casseres) (05/18/89)
In article <4679@okstate.UUCP> norman@a.cs.okstate.edu (Norman Graham) writes: > BTW, I plead with all intelligent computerists to cease to use the term > "TRUE MULTITASKING". If by "true multitasking" you mean multitasking > with preemptive job scheduling (or preemptive multitasking) by all means > say this. I'm convinced that the phrase "true multitasking" was invented > by a computer-illiterate computer-journalist who didn't know how > to effectively contrast preemptive and nonpreemptive scheduling. Amen! I think that by "true multitasking" most people mean "like the mainframe system I used in college," or "like my thesis advisor said it ought to be." From the dim past, I seem to remember similar rhetoric about "real timesharing." David Casseres Exclaimer: Wow!
andy@cbmvax.UUCP (Andy Finkel) (05/18/89)
In article <4679@okstate.UUCP> norman@a.cs.okstate.edu (Norman Graham) writes: >say this. I'm convinced that the phrase "true multitasking" was invented >by a computer-illiterate computer-journalist who didn't know how >to effectively contrast preemptive and nonpreemptive scheduling. Personally, I think the term "true multitasking" was invented the first time a programmer tried to explain to a marketing person why an interrupt driven keyboard routine didn't qualify as "multitasking", so he really shouldn't put it in the ads. :-) You know, maybe we should widen the definitions... I can see it now...Commodore had multitasking on the first PET :-) And, counting the graphics coprocessor as well as the 6502 in the keyboard, the Amiga is fully multiprocessing as well. :-) andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Do or Do Not. There is no Try." - Yoda, explaining the loop constructs in JCL (Jedi Control Language). Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
mfi@beach.cis.ufl.edu (Mark Interrante) (05/18/89)
In article <492@iisat.UUCP> mackay@iisat.UUCP (Daniel MacKay) writes: >In article <8905110108.AA02057@snoopy.UMD.EDU>, res12@snoopy.UMD.EDU (Matthew T. Russotto) writes: >> >> In article <17148@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >> > >> > [stuff about System 7.0 multitasking] >> > >> >Interesting. I have been using a system with such features, an Amiga, since >> >1985. >> >> Interesting. I have been using such a system since 1984-- >> A Lisa 2/10 running Lisa Office System. > > - a soft power switch that suspends all Multifinder processes and brings them > all back up when you power back up the next day, exactly as you left > them. I like this is idea. Since VM is part of 7.0, it seems very easy to leave disk based memory alone during shutdown so that your applications are still active next time you restart the machine. If there is a reason to close all files then it is still reasonable to leave the aaplications turned on (save time), in fact since the live cut/paste turns on applications often why not leave them active? Boot time for applications is a nontrivial amount of time this would save lots of time. ----------------------------------------------------------------------------- Mark Interrante Software Engineering Research Center mfi@beach.cis.ufl.edu CIS Department, University of Florida 32611 ----------------------------------------------------------------------------- "X is just raster-op on wheels" - Bill Joy, January 1987
mha@batcomputer.tn.cornell.edu (Mark H. Anbinder) (05/18/89)
In article <20320@uflorida.cis.ufl.EDU> mfi@beach.cis.ufl.edu (Mark Interrante) writes: >In article <492@iisat.UUCP> mackay@iisat.UUCP (Daniel MacKay) writes: >>> >>> In article <17148@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >>> > >>> > [stuff about System 7.0 multitasking] >>> > >> >> - a soft power switch that suspends all Multifinder processes and brings them >> all back up when you power back up the next day, exactly as you left >> them. > >I like this is idea. Since VM is part of 7.0, it seems very easy to leave >disk based memory alone during shutdown so that your applications are still >active next time you restart the machine. If there is a reason to close all >files then it is still reasonable to leave the aaplications turned on (save >time), in fact since the live cut/paste turns on applications often why not >leave them active? Boot time for applications is a nontrivial amount of time >this would save lots of time. One problem with this, and perhaps the reason why a "soft power" feature isn't being implemented with System 7.0, or perhaps under the Virtual VM system from Connectix, is that there are too many things going on within the computer's memory at any given moment that CAN'T be "frozen" (or stored) and then restored indiscriminately into the system memory. You wouldn't be able to expect it to "hit the ground running," as it were. Maybe if you restored the entire memory exactly as it was at some instant in the past, the system might be able to handle it. The internal clock would be slapped in the face and would quickly need to reassert the NEW correct time (the way it does when the user changes the time while running several programs under MultiFinder already). Any inits that had installed themselves in the system before you restored memory as a block would be wiped out; many of them wouldn't go cleanly, I suspect. The inits that HAD been installed when your memory chunk was recorded would be reinstated in the vertical-trace loop... and many of them might not handle THAT well, since some of them depend on disk files that may well have changed since the memory was recorded. For that matter, what if the init's file is gone? Heck, for that matter, what if an APPLICATION file is gone? Should all of your applications check every n ticks to see whether they still exist, and if they don't, quietly say "Later, dude" and attempt to quit gracefully? :-) Basically, for something like this to work, it would depend on there being NO changes to your system between shut-down and re-injection of that block of memory. That would include remote volumes like file servers, though, and you just can't count on those remaining static for you. The whole idea sounds pretty dangerous, and while it would be nice, I just don't see it happening workably in the near future on today's multiprocess, multimedia, networked Macintosh. Please feel free to prove me wrong! I'd love to hear some ideas about solving these problems. -- Mark H. Anbinder ** MHA@TCGould.tn.cornell.edu NG33 MVR Hall, Media Services Dept. ** THCY@CRNLVAX5.BITNET Cornell University H: (607) 257-7587 ******** Ithaca, NY 14853 W: (607) 255-1566 ******* "It's not safe out here." Q
jellinghaus-robert@CS.YALE.EDU (Rob Jellinghaus) (05/19/89)
In article <1925@internal.Apple.COM> casseres@apple.com (David Casseres) writes: >Amen! I think that by "true multitasking" most people mean "like the >mainframe system I used in college," or "like my thesis advisor said it >ought to be." From the dim past, I seem to remember similar rhetoric >about "real timesharing." I agree with the silliness of the preemptive vs. non-preemptive multitasking flame war (it can't rightfully be dignified with the term "debate"), but for my money, the Mac won't be multotasking enough for me until it can: Copy a file (or a disk) in the background! While I'm doing something else, like word processing! How about it? Am I doomed to eternal frustration at the sign of a modal "18 files left" dialog box sitting stubbornly in the middle of my screen? Or will I somedya be able to get that sucker into the background? >David Casseres Rob Jellinghaus | "Next time you see a lie being spread or a jellinghaus-robert@CS.Yale.EDU | bad decision being made out of sheer ignor- ROBERTJ@{yalecs,yalevm}.BITNET | ance, pause, and think of hypertext." {everyone}!decvax!yale!robertj | -- K. Eric Drexler, _Engines of Creation_
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (05/21/89)
It shouldn't be hard, however, to implement an init that goes around and examines all of the documents you have open and stores the names somewhere, and then reopens them in the appropriate order on startup. The only problem would be with documents that are unnamed. Jon
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (05/21/89)
The mac isn't fast enough for me to care whether multitasking is preemptive or not. Jon
res12@snoopy.UMD.EDU (Matthew T. Russotto) (05/21/89)
In article <31880@sri-unix.SRI.COM> mha@batcomputer.tn.cornell.edu (Mark H. Anbinder) writes: >>>> In article <17148@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >>>> > >>>> > [stuff about System 7.0 multitasking] >>>> > >>> >>> - a soft power switch that suspends all Multifinder processes and brings them >>> all back up when you power back up the next day, exactly as you left >>> them. >> >One problem with this, and perhaps the reason why a "soft power" feature >isn't being implemented with System 7.0, or perhaps under the Virtual VM >system from Connectix, is that there are too many things going on within the >computer's memory at any given moment that CAN'T be "frozen" (or stored) and >then restored indiscriminately into the system memory. You wouldn't be able >to expect it to "hit the ground running," as it were. The best way to do this, it seems to me, is to leave the burden of remembering the setup to the applications, and have multifinder send them all a 'Power Down' event, which would make them do regular quit processing, except that they are expected to save all their info. When they were restarted by multifinder, they would restore themselves automatically. Seems to me Apple is already moving in this direction, by issuing a few tech notes telling applications developers to save positions of windows etc. For an example of what I am talking about, look at what MPW 2.0 does under UniFinder when it sublaunches an applications. When it returns, all windows, etc, are back where they belong. -- DISCLAIMER: Not only does the University not share my opinions, they don't want me sharing my opinions. "This 'Pnews', what does it do?" Matthew T. Russotto res12@snoopy.umd.edu (this semester only)
peter@sugar.hackercorp.com (Peter da Silva) (05/21/89)
In article <4679@okstate.UUCP>, norman@a.cs.okstate.edu (Norman Graham) writes: > May I be so bold as to suggest Harvey Deitel's "An Introduction to > Operating Systems" Revised First Edition for a discussion of preemptive > vs. nonpreemptive scheduling. This is a very popular operating systems > text used to teach thousands of computer scientists every year. If > Dr. Deitel has no problem with this issue, I see no reason why I should. I've got that book, an old edition. Any book on operating systems that includes extensive discussions of CP/M (or probably MS-DOS, now) is hardly something to hold up as an authority. Could I hold up Comer's "Xenix" book as an alternative? > BTW, I plead with all intelligent computerists to cease to use the term > "TRUE MULTITASKING". If by "true multitasking" you mean multitasking > with preemptive job scheduling (or preemptive multitasking) by all means > say this. True multitasking means you can take a vanilla implementation of Emacs, compile it, and run it... without interfering with your ability to concurrently run without significant degradation, during the entire process, a regular commercial program like Photon Paint or Word Perfect. A better term would, perhaps, be transparent multitasking. Something that implies that conventional non-event-loop programs can be productively run under it. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
lsr@Apple.COM (Larry Rosenstein) (05/23/89)
In article <8905210253.AA25280@snoopy.UMD.EDU> res12@snoopy.UMD.EDU (Matthew T. Russotto) writes: > The best way to do this, it seems to me, is to leave the burden of remembering > the setup to the applications, and have multifinder send them all a > 'Power Down' event, which would make them do regular quit processing, except This is exactly how the Lisa worked. The Desktop Manager would send applications a suspend request, when the user hit the soft power off switch or ejected the diskette containing a document. To suspend a document the application would write out the entire state pertaining to that document (including scroll position, selection, etc.) into a separate suspend file. The last saved version of the document was untouched. The next time you opened that document, everything would be as it was when suspended. You could choose Undo, or Revert, etc. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
stores@unix.SRI.COM (Matt Mora) (05/23/89)
In article <7981@batcomputer.tn.cornell.edu> mha@tcgould.tn.cornell.edu (Mark H. Anbinder) writes: >In article <20320@uflorida.cis.ufl.EDU> mfi@beach.cis.ufl.edu (Mark Interrante) writes: >>In article <492@iisat.UUCP> mackay@iisat.UUCP (Daniel MacKay) writes: >>>> >>>> In article <17148@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >>>> > >>>> > [stuff about System 7.0 multitasking] >>>> > >>> >>> - a soft power switch that suspends all Multifinder processes and brings them >>> all back up when you power back up the next day, exactly as you left >>> them. >> Stuff deleted about why it won't work >Please feel free to prove me wrong! I'd love to hear some ideas about >solving these problems. I don't think i can prove you wrong but doesn't RamDump/Reanitmator do this? There are probably a lot of "static" (meaning not being connected to and kind of file servers. Me not being one of them...) users that could use this feature, and if the volumes won't be jumping around it shouldn't be to hard to do. -- ___________________________________________________________ Matthew Mora SRI International stores@unix.sri.com ___________________________________________________________
alexis@ccnysci.UUCP (Alexis Rosen) (05/27/89)
In article <9344@polya.Stanford.EDU> shap@polya.Stanford.EDU (Jonathan S. Shapiro) writes: >The mac isn't fast enough for me to care whether multitasking is >preemptive or not. That's not too clever. A Mac running A/UX 1.1 looks pretty competitive with a Sun 3/60. Don't tell me it would look just as good with non-preemptive multitasking (even if the concept weren't ridiculous in a Unix context...). In fact, for all the non-optimal hardware design, the Mac isn't particularly slow. It's just that CPU gets used in a markedly different way than on most other machines. Which is not to say that I wouldn't prefer preemptive multi- tasking myself. Waiting for 8.0 :-) --- Alexis Rosen alexis@ccnysci.{uucp,bitnet} alexis@rascal.ics.utexas.edu (last resort)
ts@cup.portal.com (Tim W Smith) (05/28/89)
If you've got kernel sources for Unix, try hacking it to not use pre-emptive multitasking. It might be interesting to see what happens. The first compute bound process will, of course, hang the system, but I bet a lot of things would work well. Most processes are going to give up the CPU quite a lot because they will be doing IO, which will lead to a task switch every time they have to sleep waiting for disk IO. I've always wanted to do this, but I never remembered when I had kernel sources. There's a story that used to be told at the computer center at Caltech that the clock once broke on the PDP-10 ( that tells how old this story is ) that was used for most timesharing at 'Tech, and that no one figured out what was wrong for over a week. The system seemed a bit more sluggish than usual, but otherwise worked ok. One that other hand, this is not really relevant here, since MultiFinder does not task switch when IO is in progress. Tim Smith
jspear@gryphon.COM (Jon Spear) (05/29/89)
In article <18888@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >If you've got kernel sources for Unix, try hacking it to not >use pre-emptive multitasking. It might be interesting to see >what happens. > >The first compute bound process will, of course, hang the system, >but I bet a lot of things would work well. Most processes are >going to give up the CPU quite a lot because they will be doing >IO, which will lead to a task switch every time they have to >sleep waiting for disk IO. We're getting a bit far afield, but this reminds me of the first computer I was responsible for: a PDP 11/34 running Digital Standard MUMPS (DSM-11). DSM-11 was a single-language (MUMPS) operating system built on top of RSX-11. MUMPS is a concise interpreter-oriented language and environment convenient for building multiuser hierarchical database applications that was (is?) popular in the medical computing community. Anyway... this appeared to be non-preemptive multitasking since a single compute-bound program did indeed lock the system up solid. (Of course you can do the same thing to a VAX/VMS system if any CPU hog has a high enough CPU priority, but MUMPS on a VAX couldn't normally do that.) My point? Other commercial operating systems from big name vendors have been successful (somewhat) even with non-preemptive multitasking. Further, having preemption does not guarantee no CPU starvation. -Jon -- ----- Jon L Spear: jspear@gryphon.COM <routing site>!gryphon!jspear gryphon!jspear@elroy.jpl.nasa.gov "With computers we can make billions of mistakes every second!"
rmtodd@uokmax.UUCP (Richard Michael Todd) (05/29/89)
In article <18888@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >There's a story that used to be told at the computer center at >Caltech that the clock once broke on the PDP-10 ( that tells how >old this story is ) that was used for most timesharing at 'Tech, >and that no one figured out what was wrong for over a week. The >system seemed a bit more sluggish than usual, but otherwise >worked ok. This has actually happened to our Encore Multimax a couple of times. It does make the system somewhat more sluggish. More noticable, however, is the fact that all the system daemons that are designed to sleep for a period of time waiting for work *never* wake up again, which causes all sorts of interesting problems.... -- Richard Todd Fido:1:147/1 USSnail:820 Annie Court,Norman OK 73069 Try one of these: rmtodd@chinet.chi.il.us, rmtodd@killer.dallas.tx.us, rmtodd@uokmax.ecn.uoknor.edu or ...!sun!texsun!uokmax!rmtodd. "MSDOS is a Neanderthal operating system" - Henry Spencer
mls@cbnewsm.ATT.COM (michael.l.siemon) (05/30/89)
In article <18888@cup.portal.com>, ts@cup.portal.com (Tim W Smith) writes: > If you've got kernel sources for Unix, try hacking it to not > use pre-emptive multitasking. It might be interesting to see > what happens. Admittedly, the last time I looked at the UNIX kernel was in graduate school some 15 years ago, and it was 6th edition, but UNIX multitasking has been based on time-slices and not on preemtption in all versions I know about. -- Michael L. Siemon "O stand, stand at the window contracted to AT&T Bell Laboratories As the tears scald and start; att!mhuxu!mls You shall love your crooked neighbor standard disclaimer With your crooked heart."
norman@a.cs.okstate.edu (Norman Graham) (05/30/89)
From article <3846@sugar.hackercorp.com>, by peter@sugar.hackercorp.com (Peter da Silva): > In article <4679@okstate.UUCP>, norman@a.cs.okstate.edu (Norman Graham) writes: >> May I be so bold as to suggest Harvey Deitel's "An Introduction to >> Operating Systems" Revised First Edition ... > > I've got that book, an old edition. Any book on operating systems that > includes extensive discussions of CP/M (or probably MS-DOS, now) is > hardly something to hold up as an authority. > > Could I hold up Comer's "Xenix" book as an alternative? That's a pretty cheap shot at Deital's book Peter. Yes, it contains a case study of CP/M (in addition to case studies of UNIX, VMS, and IBM's MVS and VM operating systems). But this does not detract from the execellence of the preceeding 500 pages of operating systems theory. BTW, Comer's book is on XINU... not Xenix. And I found his book a little short on operating systems theory, although it is an execellent discussion of the XINU system and I highly recommend it to those who are interested in wading around in the actual source for an operating system. >> BTW, I plead with all intelligent computerists to cease to use the term >> "TRUE MULTITASKING". If by "true multitasking" you mean multitasking >> with preemptive job scheduling (or preemptive multitasking) by all means >> say this. > > True multitasking means you can take a vanilla implementation of Emacs, compile > it, and run it... without interfering with your ability to concurrently run > without significant degradation, during the entire process, a regular > commercial program like Photon Paint or Word Perfect. > > A better term would, perhaps, be transparent multitasking. Something that > implies that conventional non-event-loop programs can be productively run > under it. No No No! A better term is the one used for the past 15 or 20 years... 'Multitasking with Preemptive Task Scheduling' or 'Preemptive Multitasking'. Transparent multitasking is still ambiguous: Is it transparent to the programmer, program, or user? People could see the term and still not know that you were speaking of a preemptive system. Ah *ell, call it whatever you want... I'm weary of my little crusade. > Peter "Have you hugged your wolf today" da Silva `-_-' > ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` +Norm -- Norman Graham Oklahoma State University Internet: norman@a.cs.okstate.edu Computing and Information Sciences UUCP: {cbosgd, rutgers} 219 Mathematical Sciences Building !okstate!norman Stillwater, OK 74078-0599
cramer@athens.iex.com (Bill Cramer) (05/30/89)
In article <16225@gryphon.COM> jspear@gryphon.COM (Jon Spear) writes: [ etc about multitasking omitted ...] >We're getting a bit far afield, but this reminds me of the first >computer I was responsible for: a PDP 11/34 running Digital Standard >MUMPS (DSM-11). DSM-11 was a single-language (MUMPS) operating system >built on top of RSX-11. MUMPS is a concise interpreter-oriented >language and environment convenient for building multiuser hierarchical >database applications that was (is?) popular in the medical computing >community. > >Anyway... this appeared to be non-preemptive multitasking since a single >compute-bound program did indeed lock the system up solid. (Of course >you can do the same thing to a VAX/VMS system if any CPU hog has a high >enough CPU priority, but MUMPS on a VAX couldn't normally do that.) > >My point? Other commercial operating systems from big name vendors have >been successful (somewhat) even with non-preemptive multitasking. >Further, having preemption does not guarantee no CPU starvation. > >-Jon I've been amused at the whining in the MacRags over the issue of *real* multitasking for the Mac, and Jon makes a good observation here. For a realtime application, the form of multitasking performed by DEC's RSX-11, as well as real time executives (MTOS, PSOS, VRTX, and the like) is infinitely better than the fair-share timeslicing most often called *real* multitasking. In a realtime environment, it is a REQUIREMENT that tasks have the opportunity to complete processing of some event before they give up the CPU. While the task is waiting on the next event (or I/O completion) the scheduler is free to give the CPU to another task. Sounds to me alot like MacOS/Multifinder. The biggest difference with a realtime multitasker and MacOS is that the former allows you to give priorities to different tasks. Given these priorities, the scheduler can pre-empt a lower priority task when the higher priority task needs the CPU -- even when the lower priority task hasn't completed the event it is processing. Like MacOS, tasks running at the same priority CANNOT pre-empt each other. (Priority manipulation, by the way, in the hands of the naive, often leads to very unhappy users -- "My Edit is infinitely more important than your Compile" etc). Folks writing realtime tasks understand their OS -- they don't write tight loops in high priority tasks without knowing that some other task may starve. Folks writing MacOS programs [usually] understand their OS -- they don't write tight loops without an occasional breather. So what is it that everyone seems to want? Beats the **** out of me. What is it that everyone seems to need? Well, I've been wrong before (twice already this year :-), but IMHO, we need well written programs that understand the concept of how MacOS works. (And IPC, and email, and virtual memory, and protected memory, and ...) Bill Cramer IEX Corporation Plano, Texas {uunet,convex,killer}!iex!cramer
jay@mitisft.Convergent.COM (Jay O'Conor) (05/30/89)
In-reply-to: your article <2097@ccnysci.UUCP> News-Path: ctnews!pyramid!decwrl!shelby!rutgers!cmcl2!ccnysci!alexis > In article <9344@polya.Stanford.EDU> shap@polya.Stanford.EDU > (Jonathan S. Shapiro) writes: > >The mac isn't fast enough for me to care whether multitasking is > >preemptive or not. > > That's not too clever. A Mac running A/UX 1.1 looks pretty competitive with > a Sun 3/60. Don't tell me it would look just as good with non-preemptive > multitasking (even if the concept weren't ridiculous in a Unix context...). > > In fact, for all the non-optimal hardware design, the Mac isn't particularly > slow. It's just that CPU gets used in a markedly different way than on most > other machines. Which is not to say that I wouldn't prefer preemptive multi- > tasking myself. > > Waiting for 8.0 :-) > --- > Alexis Rosen > alexis@ccnysci.{uucp,bitnet} > alexis@rascal.ics.utexas.edu (last resort) Given a choice between having preemptive multitasking, and hardware/system changes to allow more background time in a cooperative multitasking environment, give me the better support for cooperative multitasking! Gimme DMA and a graphics coprocessor!!! Cooperative scheduling can work VERY well as long as the apps do just that - cooperate. Today, as it stands, GetNextEvent/WaitNextEvent just doesn't hack it. I'd like to see the system be able to take advantage of disk and display I/O time for background processes. I'd also like to see developers come out with new versions of their programs that provide better support for MultiFinder. Sorry, just because an app has a SIZE -1 resource and uses WaitNextEvent doesn't mean it has good MultiFinder support. As an example, compare background downloading between VersaTerm (version 3.02, I think) and Compuserve Navigator. As much as I like VersaTerm, Navigator does a much better job of background downloading. After working 10 years for a company with a proprietary cooperative multitasking OS, I just had to jump into this discussion! Jay O'Conor
peter@sugar.hackercorp.com (Peter da Silva) (05/31/89)
[I claim that Deitel isn't such a great authority on operating systems because one of his main examples is CP/M] In article <4704@okstate.UUCP>, norman@a.cs.okstate.edu (Norman Graham) writes: > That's a pretty cheap shot at Deital's book Peter. I don't know about that. I couldn't see any constructive reason for including CP/M. If Deitel considers CP/M sufficiently interesting as an operating system to include it is one of his 6 major examples, his definition of an operating system leaves something to be desired. CP/M is little more than a program loader. Since that's precisely what you're using his book as a source for, I think it's entirely relevant to this discussion. [I make a typo, and bring up Comer's XINU book ] In article <4704@okstate.UUCP>, norman@a.cs.okstate.edu (Norman Graham) writes: > BTW, Comer's book is on XINU... not Xenix. You're right. I hate it when my brain gets ahead of my fingers and I make a fool of myself. Still, the description of what a modern operating system is composed of in the preface (memory manager, scheduler, file system, etc...) is one of the most concise descriptions I've run across. [I suggest transparent multitasking as a better term than 'real' multitasking] In article <4704@okstate.UUCP>, norman@a.cs.okstate.edu (Norman Graham) writes: > No No No! A better term is the one used for the past 15 or 20 years... > 'Multitasking with Preemptive Task Scheduling' or 'Preemptive Multitasking'. Since pre-emptive multitasking is not necessary for transparency (see, as a counter example, the Polyforth development system of the mid-70s) I don't think that's a better term. > Transparent multitasking is still ambiguous: Is it transparent to the > programmer, program, or user? Yes. Yes. Yes. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (06/01/89)
In article <3895@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >I don't know about that. I couldn't see any constructive reason for >including CP/M. If Deitel considers CP/M sufficiently interesting as >an operating system to include it is one of his 6 major examples, his >definition of an operating system leaves something to be desired. Simply on the grounds of the number of machines in the world that have run CP/M, any operating system text that fails to include it and attempts to survey is not doing the job. CP/M is not fancy, but it served 10's of thousands of people very well for a long time, including some multitasking versions. Let's cool down a bit... Jon
larryh@tekgvs.LABS.TEK.COM (Larry Hutchinson) (06/02/89)
In article <870@iex.UUCP> cramer@iex.UUCP (Bill Cramer) writes: > >I've been amused at the whining in the MacRags over the issue of *real* >multitasking for the Mac .... . . >So what is it that everyone seems to want? Beats the **** out of me. What >is it that everyone seems to need? Well, I've been wrong before (twice >already this year :-), but IMHO, we need well written programs that >understand the concept of how MacOS works. .... Well Bill, would you like to volunteer to go through the megabyte fortran soucre code that I have and analyze it for timing and then put calls to WaitNexEvent in just the right places? It kinda needs to run in the backgound since it takes hours to days to complete its task on a VAX -- presumably the same on my SE/30 but I haven't tried it yet since there is no preemtive multitasking on the Mac. I sure as Hell don't want to do the munging myself since (1) I didn't write the program, (2) I don't understand the program and (3) I hate fortran. But you get the Idea. It is an incredible pain in the ass to take 'dusty decks' and put WaitNextEvents in just the right places (and without slowing the program down). I *need* preemptive multitasking. I do admit that it is not that big of a deal for more typical Mac programs. Larry Hutchinson, Tektronix, Inc. PO Box 500, MS 50-383, Beaverton, OR 97077 UUCP: [uunet|ucbvax|decvax|hplabs]!tektronix!tekgvs!larryh ARPA: larryh%tekgvs.LABS.TEK.COM@RELAY.CS.NET CSNet: larryh@tekgvs.LABS.TEK.COM
time@oxtrap.UUCP (Tim Endres) (06/15/89)
Those making convincing arguments for *absolutely* needing pre-emptive multi-tasking (i.e. I have a 300000 line Fortran program), should be using A/UX. The small gain in MacOS for pre-emptive multi-tasking is not worth the effort, or the affects on what makes MacOS so good. Do you want to wait two seconds before the Mac takes your mouse click and starts resizing your window? I think not. Multi-Finder combined with virtual memory is about the diminished limit of return for MacOS.
ts@cup.portal.com (Tim W Smith) (06/21/89)
>> If you've got kernel sources for Unix, try hacking it to not >> use pre-emptive multitasking. It might be interesting to see >> what happens. > >Admittedly, the last time I looked at the UNIX kernel was in graduate school >some 15 years ago, and it was 6th edition, but UNIX multitasking has been >based on time-slices and not on preemtption in all versions I know about. "A scheduling discipline is nonpreemptive if, once a process has been given the CPU, the CPU cannot be take away from that process. A scheduling discipline is preemptive if the CPU can be taken away." from "An Introduction to Operating Systems", revised first edition, by Harvey M. Deitel, page 252. Unix is preemptive. Time-slices are used to determine *when* to preempt. In other words, time-slices are one way to implement a preemptive scheduler. This is all from the point of view of user mode code, of course. To kernel mode code, Unix is nonpreemptive. Tim Smith
mls@cbnewsm.ATT.COM (michael.l.siemon) (06/22/89)
In article <19720@cup.portal.com>, ts@cup.portal.com (Tim W Smith) writes: > Unix is preemptive. Time-slices are used to determine *when* to > preempt. yes; some while after my bleary eyed posting, I realized I had been off in verbal limbo somewhere. (I hoped that no one noticed, but of course that was a vain hope.) -- Michael L. Siemon Psalm 82:6: "I say, 'You are gods, contracted to AT&T Bell Laboratories sons of the Most High, all of you; att!mhuxu!mls nevertheless, you shall die like men, standard disclaimer and fall like any prince.'"