dent@unocss.UUCP (Dave Caplinger) (12/08/88)
If the December 6th MacWEEK is correct (specifically, Mac the Knife), then there will be no more Desk Accessories, starting with System 8.0 (Yeah, but will they do multi-tasking, and virtual memory by then? :-). Sure, I can see the point; multitasking removes the need for them. But, what are they going to do with Control Panel, and the many many CDEV files lying around? (And while (some of us) are talking about improvements does anyone else feel that the current Control Panel scheme of "throw the file in the System Folder and it works" is a little kludgy? I have so many files in my system folder that I can't see them all on an SE's screen. INIT's are equally a pain. (Though I see there's a new CDEV to handle INITs?) I guess we won't need DiskTop by then, because we really will have the REAL Finder to jump to. :-) [ This may be rambling, but has anyone else seen DEC's XUI (X-Windows User Interface)? Why aren't Apple's lawyers having a conniption over that one? ] -/ Dave Caplinger /--------------+--------------------------------------- Microcomputer Specialist | Internet: UNOCC07%ZEUS@CRCVMS.UNL.EDU Campus Computing | UUCP: uunet!btni!unocss!dent University of Nebraska at Omaha | Bitnet: UNOCC07@UNOMA1 Omaha, NE 68182 | or dc3a+@andrew.cmu.edu
jnh@ece-csc.UUCP (Joseph Nathan Hall) (12/09/88)
In article <552@unocss.UUCP> dent@unocss.UUCP (Dave Caplinger) writes: >[ This may be rambling, but has anyone else seen DEC's XUI (X-Windows User >Interface)? Why aren't Apple's lawyers having a conniption over that one? ] Primarily because Apple and DEC are in bed together on this one. Don't you remember the networking deal between Apple and DEC a while back? What did DEC get out of that ... ? I dunno. What would YOU be willing to trade in return for the right to double-click in your user interface? -- v v sssss|| joseph hall || 201-1D Hampton Lee Court v v s s || jnh@ece-csc.ncsu.edu (Internet) || Cary, NC 27511 v sss || the opinions expressed herein are not necessarily those of my -----------|| employer, north carolina state university . . . . . . . . . . .
merchant@eleazar.dartmouth.edu (Peter Merchant) (12/09/88)
In article <552@unocss.UUCP> dent@unocss.UUCP (Dave Caplinger) writes: >If the December 6th MacWEEK is correct (specifically, Mac the Knife), >then there will be no more Desk Accessories, starting with System 8.0 > >Sure, I can see the point; multitasking removes the need for them. But, >what are they going to do with Control Panel, and the many many CDEV >files lying around? (And while (some of us) are talking about improvements >does anyone else feel that the current Control Panel scheme of "throw the >file in the System Folder and it works" is a little kludgy? I have so many >files in my system folder that I can't see them all on an SE's screen. They'll probably turn the control panel into an application. In fact, it might work out for the best because CDEVs could be put in a folder and accessed through the File menu of the application. Here's a request, though, for a way to deal with desk accessories. It would be really keen if there were some way to, on system start up, put a collection of applications onto your Apple menu without necessarily starting them up. This would give me the same thing as a desk accessory. One of the features of a desk accessory under MultiFinder is that it's conveniently there. If I'm talking to someone and I need a phone number, I go to the Apple menu and choose Phone Book and, within a few seconds, I have my phone book. I don't have to go to the Apple menu and choose Finder, then open the particular folder with DA-like applications, then start the paricular application. Try doing all that while you're on the phone with someone. One feature that (GASP!) Microsoft Windows has is the ability to take applications and put them down on the icon bar down at the bottom of the screen. This gives you immediate access. The only grumble I have with it is that I believe that those applications are considered "running" and, therefore, eating precious memory. Some way to say "I want to be able to start this application and leave this application and all I should have to do is choose it's name from a menu to do it" would be nice... ...At least, I think it'd be nice. --- "Cover me, Peter Merchant (merchant@eleazar.UUCP) Comfort me, (Peter.G.Merchant@dartmouth.EDU) Hold me..."
mfi@beach.cis.ufl.edu (Mark Interrante) (12/10/88)
In article <552@unocss.UUCP> dent@unocss.UUCP (Dave Caplinger) writes: >If the December 6th MacWEEK is correct (specifically, Mac the Knife), >then there will be no more Desk Accessories, starting with System 8.0 If my desk accessories are going away then I want a method of instantly accessing an application that I have put on a "cache" menu someplace. I do not want to have to go to the finder; watch the screen update; open up N directories; just to access my miniWriter. ----------------------------------------------------------------------------- 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
pratt@boulder.Colorado.EDU (Jonathan Pratt) (12/10/88)
In article <11426@dartvax.Dartmouth.EDU> Peter.G.Merchant@dartmouth.edu (Peter Merchant) writes: > >Here's a request, though, for a way to deal with desk accessories. It would >be really keen if there were some way to, on system start up, put a collection >of applications onto your Apple menu without necessarily starting them up. >This would give me the same thing as a desk accessory. There is a nifty INIT called On Que that does essentially this. A pop-up menu is installed into the upper right hand corner of the menu bar. You can configure the menu to contain any number of applications to be acces- sible for instant launch. Documents for the applications are installed in submenus so that they will automatically be opened if selected. With- out Multifinder On Que attempts to quit the current application in the usual way, allowing you to save changes, etc. Under Multifinder the cur- rent application is sent to the background when a new app is launched. My opinions only... Jonathan Pratt pratt@boulder.colorado.edu
pratt@boulder.Colorado.EDU (Jonathan Pratt) (12/10/88)
As long as I'm putting in a plug for On Cue (note corrected spelling) I may as well give some more info. On Cue is a commercial INIT that allows launching of applications and documents from just about anywhere. It's Multifinder compatible and is available from: IMI Software 121 14th Street Seal Beach, CA 90740 1-800-284-4647 or 1-213-596-0399 Disclaimer: My only connection with IMI is as a satisfied user of their product. Jonathan Pratt pratt@boulder.colorado.edu
jchiu@mcdurb.Urbana.Gould.COM (12/12/88)
> >INIT's are equally a pain. (Though I see there's a new CDEV to handle INITs?) > Could anyone provide me more details on this? Thank you in advance. Jeff Chiu Gould Inc. Computer System Division jchiu@gould.com or jchiu@xenurus.gould.com or jchiu@urbana.mcd.mot.com or uunet!uiucdcs!mcdurb!jchiu
srpenndo@uokmax.UUCP (Sean Richard Penndorf) (12/13/88)
In article <552@unocss.UUCP> dent@unocss.UUCP (Dave Caplinger) writes:
=>If the December 6th MacWEEK is correct (specifically, Mac the Knife),
=>then there will be no more Desk Accessories, starting with System 8.0
=>(Yeah, but will they do multi-tasking, and virtual memory by then? :-).
=>
=>Sure, I can see the point; multitasking removes the need for them. But,
=>what are they going to do with Control Panel, and the many many CDEV
=>files lying around? (And while (some of us) are talking about improvements
=>does anyone else feel that the current Control Panel scheme of "throw the
=>file in the System Folder and it works" is a little kludgy? I have so many
=>files in my system folder that I can't see them all on an SE's screen.
Well, totally getting rid of DA's is not a smart move. There should be a
means where you can still access the DA's (either via Multi-Finder or
Finder) from the Apple Menu. DA's are an integral part of the Mac User
Interface.
Granted, the "throw it in the System Folder" theory needs some work.
Here's my two pence... Under Mutlti-Finder, it would be nice to have an
application that is a DA Manager, where either under the File Menu or otherwise
you can access the DA's and the DA Manager will work as the shell. In this
way, the DA's could be anywhere on the disk, and would be loaded into memory
only when called. Optionally, Apple could make a INIT or program similar
to SuitCase which would load up the DA's, Fonts, etc, based on user input
or macros. Say when working in Application X, you prefer to have Fonts
1, 2, and 3, but when in Application Y, you prefer 3, 6, and 9.
The problem comes when the user decides not to use Multi-Finder.
(Or are we assuming that the Mac system will run only in a Multi-Finder mode?)
Summary, the user should still be able to access his/her DA's through the
Apple menu in some way under the "New System" with better flexibility and
control over where they reside on the disk. I can see the makers of SuitCase
taking advantage of this.
...A little off the subject, but rather than post another message...
Shouldn't there be a "Master Key" to press to override any and all INITS
from loading? Sure would be nice.
--
Sean 'Longstride' Penndorf
!texsun!uokmax!srpenndo . . .-----------
GEnie: S.PENNDORF | | `---.
---- The WEASEL Project ---- `--'LTIMATUM----'OFTWARE
c60a-2ce@e260-2b.berkeley.edu (Mikey) (12/14/88)
Whoa, whoa, WHOA! What's this talk about System 8.0 when we're only at 6.0.2? I would appreciate any enlightenment on this subject. Also, someone mentioned multitasking? Will system 8.0 support TRUE multi- tasking? I thought this was only possible with a Mac IIx or an appropriately upgraded Mac that supports virtual memory. I'm sorry if I seem ignorant....I haven't followed this entire strand... -------------------------------------------------------------------------- I'd appreciate it if you could reply via EMAIL. I'm not able to access the net that often. Thanks a lot!! c60a-2ce@web.berkeley.edu............................................Mikey *** Call Tanelorn III! (415) 540-1180. The Apple/Mac BBS of Berkeley. ***
zimerman@phoenix.Princeton.EDU (Jacob Ben-david Zimmerman) (12/14/88)
In article <2134@uokmax.UUCP> srpenndo@uokmax.UUCP (Sean Richard Penndorf) writes: >[stuff deleted] >Summary, the user should still be able to access his/her DA's through the >Apple menu in some way under the "New System" with better flexibility and >control over where they reside on the disk. I can see the makers of SuitCase >taking advantage of this. COMPLETE AGREEMENT. >...A little off the subject, but rather than post another message... >Shouldn't there be a "Master Key" to press to override any and all INITS >from loading? Sure would be nice. MORE complete agreement! Apple, you listening? I have SO many times wished I could just boot with a key down instead of having to go through my system folder and carefully pick out all offending inits when I am testing software to see if it is Mac II Incompatible or merely incompatible with one of my many inits. A question on this subject: I have noticed that some INITs do check for one key or other upon loading. Has Apple announced a standard check taht everyone is ignoring? Or is the subject simply ignored? EndUser the NonHacker a.k.a JBZimmerman! -soon to be hacker (after finals, I'll learn C. Yeah.) > >-- >Sean 'Longstride' Penndorf >!texsun!uokmax!srpenndo . . .----------- >GEnie: S.PENNDORF | | `---. > ---- The WEASEL Project ---- `--'LTIMATUM----'OFTWARE -- ___________ | "If there's anything around here more important || | than my ego, I want it caught and shot now."-ZB || ||acob Zimmerman!+> <zimerman@phoenix.Princeton.EDU> INTERNET === | <zimerman@PUCC> BITnet
ts@cup.portal.com (Tim W Smith) (12/14/88)
In several articles, people have said that when DAs go away in a future version of the system, they want some way to put several applications in some easy to access place, like DAs are now placed. How about using PowerStation? You can get to about 50 applications with two mouse clicks under MultiFinder, and about 700 with three mouse clicks. Og course, running on a one meg Mac II, I haven't tried this other than a brief experiment so that I would not make a total fool out of myself with this posting... Tim Smith
ephraim@think.COM (Ephraim Vishniac) (12/14/88)
In article <18277@agate.BERKELEY.EDU> c60a-2ce@e260-2b.berkeley.edu (Mikey) writes: >Whoa, whoa, WHOA! What's this talk about System 8.0 when we're only at >6.0.2? I would appreciate any enlightenment on this subject. Wild speculation, mostly. If you trace the discussion back, you'll find it started with a rumor in Mac the Knife's MacWEEK column. Even if the rumor truly reflects Apple's current plan, there's a lot of time between now and 8.0. Anything could change. Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 "He shook his head to clear a momentary system error."
@DOUGHNUT.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU (12/15/88)
From: Brad Miller <miller@CS.ROCHESTER.EDU> Date: 14 Dec 88 05:34:43 GMT From: c60a-2ce@e260-2b.berkeley.edu (Mikey) Also, someone mentioned multitasking? Will system 8.0 support TRUE multi- tasking? I thought this was only possible with a Mac IIx or an appropriately upgraded Mac that supports virtual memory. You can multitask without virtual memory. The problem with the 68000 is that it doesn't save enough internal state to be able to handle page faults, thus you can't do virtual memory. The ability to run more than one process (ie. multitasking) is a different issue entirely. Of course, it is an environment much as multifinder is, all processes must be resident, and one can only task switch at "safe" points, as opposed to an arbitrary interrupt, (e.g. during i/o the process purposely saves it's state to be resumed later) again because of limitations on the 68000 and its internal state. But people were doing multitasking before they were doing virtual memory... It's something of a pity multifinder doesn't already do this; one could have a reasonable yet small IPC standard based on pointers to heap objects... and then consumers of a stream could run simultaneously with the producer, rather than the current braindamage of producing a file, switching to the next program, reading the file... Ah well, PCs for the most part haven't entered into late 70s technology... ---- Brad Miller U. Rochester Comp Sci Dept. miller@cs.rochester.edu {...allegra!rochester!miller}
dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (12/16/88)
In article <1988Dec14.223739.16280@cs.rochester.edu> @DOUGHNUT.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU writes: >Ah well, PCs for the most part haven't entered into late 70s technology... No they tried to leap frog that period of time, and do Better. ;-) Just kidding, but in many ways PC exceed the capabilities of the 1970's. Mostly in User Interface and response time, but in many ways they haven't yet caught up. Just my .02 cents worth since I'm on break and had nothing else better to do. -- David M. O'Rourke dorourke@polyslo.calpoly.edu "If it doesn't do Windows, then it's not a computer!!!" Disclaimer: I don't represent the school. All opinions are mine!
goldman@Apple.COM (Phil Goldman) (12/16/88)
In article <1988Dec14.223739.16280@cs.rochester.edu> @DOUGHNUT.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU writes: >It's something of a pity multifinder doesn't already do this; one could have >a reasonable yet small IPC standard based on pointers to heap objects... and >then consumers of a stream could run simultaneously with the producer, >rather than the current braindamage of producing a file, switching to the >next program, reading the file... This has nothing to do with whether the multitasking is preemptive or not. In fact, doing producer/consumer on shared memory *is* possible with MultiFinder. It is absolutely not necessary to do IPC thru files. It is true that Apple is not yet officially supporting a full-blown IPC mechanism, but there are numerous ways to do it already anyway. As an aside to the person asking about TRUE multitasking in 8.0, MultiFinder already supports true multitasking. That is, it divvies up CPU time between multiple applications. If the reference is to preemptive multitasking, then there is really no reason to get excited. Preemptive multitasking will make life a bit easier on developers, but not much, and have no typical effect on users. The only point at which preemptive multitasking is more useful to a Mac end user is when he is using a buggy app. -Phil Goldman Apple Computer
srpenndo@uokmax.UUCP (Sean Richard Penndorf) (12/16/88)
In article <12591@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes:
=>In several articles, people have said that when DAs go away in a future
=>version of the system, they want some way to put several applications in
=>some easy to access place, like DAs are now placed.
=>
=> Tim Smith
Actually, you can use On Cue. However, if you are running Multi-Finder,
the applications running are placed in the Apple Menu(as you know) so there
is not a real need to have the Applications in an easily accessable place.
However, what I think would be nice is to have an application or INIT
which will allow you to still use your DA's under the new System
(assuming it won't support DA's like we have been talking about.)
There are a few DA's which I use daily and are very important to me for
operation of my Mac. Totally getting rid of DA's is a bad move.
SuiteCase would be a nice thing to have, should DA's not be supported.
Another thing which got lost in our mumbo-jumbo is that we want this
"DA Application Manager" to allow a greater flexibility in where the DA's
(INITS, CDEV's, and anything else used in the System Folder right now) reside
on the disk.
--
Sean 'Longstride' Penndorf
!texsun!uokmax!srpenndo . . .-----------
GEnie: S.PENNDORF | | `---.
srpenndo@uokmax.UUCP `--'LTIMATUM----'OFTWARE
peirce@claris.com (Michael Peirce) (12/16/88)
In article <321@internal.Apple.COM> goldman@Apple.COM (Phil Goldman) writes: >In article <1988Dec14.223739.16280@cs.rochester.edu> @DOUGHNUT.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU writes: >>It's something of a pity multifinder doesn't already do this; one could have >>a reasonable yet small IPC standard based on pointers to heap objects... and >>then consumers of a stream could run simultaneously with the producer, >>rather than the current braindamage of producing a file, switching to the >>next program, reading the file... > >This has nothing to do with whether the multitasking is preemptive or not. >In fact, doing producer/consumer on shared memory *is* possible with >MultiFinder. It is absolutely not necessary to do IPC thru files. > I've got to throw in my two cents here. There IS a form of "IPC" on that Mac already that is fully supported by Apple: AppleTalk. It's true that you have to have it turned on and that it may not be as efficient as something that comes along later, but it does have the benefit that it can span multiple machines with no added effort. I've written a number of programs that talk back and forth between each other on the same machine using MultiFinder. It works fine. I AM looking forward to formal IPC supported on the Mac (some form of shared global sections mapped between multiple process address spaces would make a certain class of program possible on the mac), but you can do a reasonably useful form of IPC using legitimate techniques today. -- michael Claris Corp. | Michael R. Peirce -------------+-------------------------------------- | 440 Clyde Avenue | Mountain View, CA 94043 | (415) 960-4011 | MCI-Mail: mpeirce | AppleLink: peirce1 | Internet: peirce@claris.com | uucp: {ames,decwrl,apple,sun}claris!peirce
dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (12/17/88)
In article <321@internal.Apple.COM> goldman@Apple.COM (Phil Goldman) writes: >As an aside to the person asking about TRUE multitasking in 8.0, MultiFinder >already supports true multitasking. That is, it divvies up CPU time >between multiple applications. If the reference is to preemptive multitasking, >then there is really no reason to get excited. Preemptive multitasking >will make life a bit easier on developers, but not much, and have no >typical effect on users. The only point at which preemptive multitasking is >more useful to a Mac end user is when he is using a buggy app. I don't typically like to disagree with Apple or it's employee's, because they're closer to the action than I am and seem to know whats going on. But to make the statement that pre-emptive multitasking won't make a difference is ridiculas {sp??}. Right now the application has to give up the processor thru one of a few limited calls, if applications don't make these calls the computer essentially becomes single-tasking. As an example start Smartcom downloading and stuffit uncompressing, stuffit doesn't make these calls fast enough and causes Smartcom to timeout on the download. Now if you're trying to tell me that pre-emptive multitasking won't make a difference, then I need to re-take my OS course and explain to my teacher why everyone should use non-pr-emptive M/T because there really is no difference. The problem with non-pre-emptive M/T is that the CPU can be hoged by one process and in theory never given up. Pre-emptive M/T doesn't allow a process to do this and gives each process the same amount of time when the process is considered active. This allows for processes to "slow" down in execution, but it would be nothing compared to the slow-->fast-->slow-->what's-going-on performance under the current Multi-Finder system. Pre-emptive M/T is more than a fix for developers, it will allow the user to run several applications without having to worry if the "background" applications are doing too much and will slow down the foreground applications. Sorry this got longer than I intended, and I don't mean to flame Apple or Mr. Goldman for taking to time to read and post on the net. But I think that pre-emptive M/T is more than a fix for developers, and Mr. Goldmans statements about there not being "much" difference need some more thought. -- David M. O'Rourke dorourke@polyslo.calpoly.edu "If it doesn't do Windows, then it's not a computer!!!" Disclaimer: I don't represent the school. All opinions are mine!
clive@drutx.ATT.COM (Clive Steward) (12/17/88)
From article <321@internal.Apple.COM>, by goldman@Apple.COM (Phil Goldman): > > As an aside to the person asking about TRUE multitasking in 8.0, MultiFinder > already supports true multitasking. That is, it divvies up CPU time > between multiple applications. If the reference is to preemptive multitasking, > then there is really no reason to get excited. Preemptive multitasking > will make life a bit easier on developers, but not much, and have no > typical effect on users. The only point at which preemptive multitasking is > more useful to a Mac end user is when he is using a buggy app. > > -Phil Goldman > Apple Computer Just a vote. Thank you for finally saying this. It must have been difficult to listen to the constant flow of abuse, for what is indeed a completely useful and satisfactory product; one of clearly a great deal of careful effort. Clive Steward x x x x x x x x x x x x x x x x x x
barmar@think.COM (Barry Margolin) (12/17/88)
In article <6692@polyslo.CalPoly.EDU> dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) writes: >In article <321@internal.Apple.COM> goldman@Apple.COM (Phil Goldman) writes: > The only point at which preemptive multitasking is >>more useful to a Mac end user is when he is using a buggy app. > As an example start Smartcom downloading and stuffit uncompressing, stuffit >doesn't make these calls fast enough and causes Smartcom to timeout on the >download. Stuffit is a "buggy app" according to Apple's (or at least Phil's) definition. Applications are supposed to call into the system frequently, even if they aren't looking for an event for themselves. Stuffit isn't calling often enough. Mac programming has always required more attention to these kinds of details than programming other systems, so these kinds of bugs are pretty common. But is it Apple's fault that the application developers have trouble getting this right? This requirement has been in Inside Mac since day 1, long before there was any significant amount of multitasking (it was needed for DA's that ran in the background, such as BackDown and background print spoolers). Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
anson@spray.CalComp.COM (Ed Anson) (01/03/89)
In article <33613@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes: > >Stuffit is a "buggy app" according to Apple's (or at least Phil's) >definition. Applications are supposed to call into the system >frequently, even if they aren't looking for an event for themselves. There are probably lots of "buggy" applications, by this definition. One of the problems is this: There are some ROM calls which can require more time to execute than the maximum time that should be allowed between opportunities for task switches. DrawPicture comes to mind. Or any I/O call to a slow device, or one which may pause between characters. I have had to modify drivers to provide time-outs, just to work around this latter problem. On the other hand, adding preemptive multi-tasking would make subtle but important changes to the programming model. I'm not sure we're ready for the effects that would have on existing applications. Most applications have come to rely on the fact that certain global system state elements don't change except at well-defined times. Preemptive multi-tasking would break such applications. When it does come, preemptive multi-tasking will probably require specific enabling by each participating application, much as background operation does now. -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM
drc@claris.com (Dennis Cohen) (01/05/89)
StuffIt is "buggy" by other definitions inside Apple besides the one Phil quoted. The easiest way to see this is to try to run it under AUX. It ain't "32-bit clean". From what the folks in DTS say, if it isn't 32-bit clean, it probably won't run six months from now when the new system is released (that six month figure is one they used and I take it to mean "whenever we get around to releasing our next System version"). Dennis Cohen Claris Corp. ------------ Disclaimer: Any opinions expressed above are _MINE_!