gnu@hoptoad.uucp (John Gilmore) (02/27/88)
phil@apple.UUCP (Phil Ronzone, A/UX Technical Manager) wrote: > Remember - it is a Mac. Under A/UX or the Mac OS, you have the Toolbox > and the Mac look and feel. Ain't nobody else got that ... This claim requires some looking behind the hype. Under the MacOS, you indeed get the Toolbox and the Mac look and feel. Under A/UX, you can run a small subset of Mac applications -- the ones that strictly follow the latest guidelines for cleanliness. However, there is no convenient way to transfer a Mac application from its home on Mac floppies or hard disk, into the Unix file system. There is a program that will read 400K, non-HFS floppies and extract the files therein. There is *no* way to read standard 800K MacOS floppies, or an HFS floppy, or an HFS disk partition, from Unix. I suppose you could get a second mac, and transfer the programs and all their data files over with xmodem, but I doubt many people will bother. It's easier to shutdown A/UX and reboot the MacOS. Under A/UX, you have access to the Toolbox. It's a library in /lib. If you have source for a Mac application, you can do some of the Toolbox calls, compile it, link it with this library, and they work. However, you can only run one such application at a time -- it takes over the whole screen, and you can't get to Unix any more, except over the serial ports or Ethernet. No control-Z. No multiple windows. You are either in the application or you are talking to a Unix shell, not both. There is no equivalent to "switcher" or "multifinder". When you boot up A/UX, you get a "terminal emulator" on your screen. This is just like the terminal emulator you get on a Sun before you bring up the window system -- it looks like an ANSI terminal, with 35 lines and 89 columns, like a slightly bigger VT100. However, they have cleverly painted a mac-looking box around the outside of the terminal emulator. There's a menu bar at the top -- with all the words in grey. You can't hit any of them. There's a box around the terminal "window", with a title bar. You can't hit it. There isn't even a mouse cursor. This is a cute trick, but that's all it is. It doesn't do any kind of graphics, it's just a terminal. So you say you want windows! Well, Apple has provided them. The single Toolbox application, term, that comes with your A/UX port provides multiple windows. However, this is just more VT100's on your screen. You can have up to 4 ANSI terminal emulators in a variety of sizes. They can even overlap. (They have to, unless you bought a third party large monitor, or you like dinky VT100s.) There is no graphics support, however, and you can't run any Mac applications because you are already running a Toolbox program and you can only run one at a time. I would not call this a window system, certainly not in the sense of NeWS or X or SunView or Andrew or the Apollo window system. It's more like "uw". Also, "term" is not a supported part of A/UX. If you find bugs in it, it's your problem. Don't burn up a lot of money buying color graphics boards for your Mac-II yet; A/UX doesn't support them. If your color board supports monochrome, A/UX can use it -- until you try a Toolbox application. It seems that frame buffer manufacturers have to alter the configuration ROMs on their boards before A/UX can put up a mouse cursor. Of course, if your color board does not support a 1-bit mode, A/UX can't use it at all. And it can only handle one screen right now, even if you have several. They have promised to fix this Real Soon Now. The Apple marketing effort here is a masterpiece of hype. I have the brochure they distributed at UniForum. The outer folder ("There are currently more than 50 types of UNIX in the world.") has four pictures of Mac screens. Three of them are running MacOS applications (one from MultiFinder; the others we can't tell), and are photographed from straight above the Mac, so you can barely see the screen. The fourth is running unavailable software from Brown University that brings up pictures and text from British novels, using the Toolbox. (By the way, they are calling the Brown stuff "hypertext" and taking Ted Nelson's name in vain. It ain't hypertext, it's just hype.) Contained in the folder is a short letter and three flyers. The "Apple A/UX Operating System" flyer has a single large picture: the Brown U. software again (which is, of course, *not* in A/UX and not commercially available either). The "Macintosh II Personal Computer" flyer, for once, is free of hype. The "A/UX Support Services" flyer is headed by a big picture of a mailing envelope with an "A/UX Update" tape hanging out of it. Of course, this tape is in the 40MB Apple SCSI tape format, which is not supported by A/UX. In their booth, Apple was demonstrating a version of X windows. However, if pressed, they revealed that it was X.10, not X.11, that it was not available for purchase, and would never be available; and that they could not talk about possible release dates for X.11. I'd hate to be totally negative in this article, so let me just say that there *is* a window system for A/UX. You just can't buy it from Apple. We sell it; it's called MacNews, and it's a straight port of Sun's NeWS, with all of NeWS's problems and all of NeWS's virtues. The first test copy went out last night, and it has a firm release date and a firm price. I'm a techie through and through and I hate to see people get away with marketing bullshit. If you buy A/UX, buy it because you know what you are getting, not because you believed an Apple snow job. -- {pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com "Watch me change my world..." -- Liquid Theatre
bin@rhesus.primate.wisc.edu (Brain in Neutral) (02/28/88)
phil@apple.UUCP (Phil Ronzone, A/UX Technical Manager) wrote: > Remember - it is a Mac. Under A/UX or the Mac OS, you have the Toolbox > and the Mac look and feel. Ain't nobody else got that ... Which is hardly to demonstrate that it would be impossible or difficult to put the Mac look and feel up under some other windowing system. It's just that, if you do, Apple's lawyers will be on your doorstep. Which has nothing to do with the superiority of A/UX or the Mac OS. It is hardly valid to say that system ABC can do something no other system can do, when the reason is that you'll sue anybody else who builds a system that can do what ABC does. --- Paul DuBois UUCP: {allegra,ihnp4,uunet}!uwvax!rhesus!dubois | ARPA: dubois@rhesus.primate.wisc.edu --+-- | "Live by the sword, die by the sword." | s/the sword/promiscuity/g
benoni@ssc-vax.UUCP (Charles L Ditzel) (02/28/88)
In article <4129@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > This claim requires some looking behind the hype. > The fourth is running unavailable software from Brown University > that brings up pictures and text from British novels, using the Toolbox. > (By the way, > they are calling the Brown stuff "hypertext" and taking Ted Nelson's > name in vain. It ain't hypertext, it's just hype.) Apple shouldn't have to resort to all the stuff you mention.. A friend of mine listened to an interview with Ted Nelson on a local radio station, apparently Mr. Nelson seemed more enamored with Sun than the Mac. She said he criticized MacOS as having "design flaws". Maybe Apple doesn't pay homage to those that pay no homage to Apple. > I'd hate to be totally negative in this article, so let me just say > that there *is* a window system for A/UX. You just can't buy it from > Apple. We sell it; it's called MacNews, and it's a straight port of > Sun's NeWS, with all of NeWS's problems and all of NeWS's virtues. The > first test copy went out last night, and it has a firm release date and > a firm price. If you have been following the NeWS/X debate in comp.sys.windows recently then you are aware that a number of responses dealing with actual hands on NeWS experience haveing been extremely positive. One in particular recounted that his only previous window/graphics experience was with the Mac Toolbox- he stated he would take NeWS *any day*. Another recounted that two experienced C programmers undertook X and NeWS efforts . The X fellow switched to NeWS after the project was over. NeWS on the Mac is good news (no pun intended) for Apple. It should be noted that this is all contrary to Mr Jean Louis-Gassee naive sense of economics (Mr. Gassee is a proponent of retaining - not licensing - technology ...). Apple has turned to Unix - an OS which they do NOT own and are now able to take advantage of windowing systems (NeWS/X) which they do NOT own, networking systems (NFS/yellowpages) they do NOT own...Ethernet a technology they do NOT own. Gassee has gone out of his way lately to pronounce on the gullible that licensing technology is bad and proprietary technology is good. However, one need only look at what Apple *does* to understand the limitations of his views. Let's face it licensing technology is something that enriches *all* of us. Sun has allowed others to license (and Apple is using much of this technology NOW) : * NeWS (which is now on the Apple - thanks to Grasshopper), * NFS/Yellowpages (which is how Apple will do their ethernet networking, * SunOS SVID Unix which they are licensing and will deliver to AT&T (and which Apple will eventually license :) * 7-10 MIP SPARC processor (who knows maybe their is a SPARC in Apple's future. It would make sense they would be binary compatible with Sun and AT&T...I think not tho' given their recent alliance with DEC ) No amount of paranoia about Sun licensing it's products to American and Japanese vendors can deny the simple fact that a product like NeWS is good for the Mac consumer... > If you buy A/UX, buy it because you know what you are > getting, not because you believed an Apple snow job. good point. their seems to be to much of it going around these days by all these computer companies. Some of it borders on outright deliberate deception. Incidentally two articles Mac II/ A/UX users might be interested in : *Unix World has a bunch of articles on A/UX *Feb. '88 MacWorld page 17 - Sushi, American Style -------------------------------------------- My thoughts are my own. No one else would have them.
benoni@ssc-vax.UUCP (Charles L Ditzel) (02/29/88)
In article <283@rhesus.primate.wisc.edu>, bin@rhesus.primate.wisc.edu (Brain in Neutral) writes: > phil@apple.UUCP (Phil Ronzone, A/UX Technical Manager) wrote: > > Remember - it is a Mac. Under A/UX or the Mac OS, you have the Toolbox > > and the Mac look and feel. Ain't nobody else got that ... The toolbox is hardly something to be touting ... the Mac Toolbox lacks the sophistication of other systems that incorporate network window management and extensible window servers. Three years ago this might have been an appropriate point. As for the look and feel ... the Mac certainly has made it's contribution but since it is not licensable and others can't use it... it is being by-passed by the remainder of the industry...e.g. SunTools, Presentation Manager, Apollo's DM, etc. Rather it is Apple that is moving more toward industry standards with NeWS and X sitting on their system. Writing an A/UX application using the Mac Toolbox specifically precludes the application migrating elsewhere (which in some cases makes sense, but in most does not if you are interested in portability). > Which is hardly to demonstrate that it would be impossible or difficult > to put the Mac look and feel up under some other windowing system. it's been done...why else did Apple sue DRI for GEM.
sbb@esquire.UUCP (Stephen B. Baumgarten) (03/01/88)
In article <1709@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >It should be noted that this is all contrary to Mr Jean Louis-Gassee naive >sense of economics (Mr. Gassee is a proponent of retaining - not licensing - >technology ...). >Apple has turned to Unix - an OS which they do NOT own and are now able to >take advantage of windowing systems (NeWS/X) which they do NOT own, networking >systems (NFS/yellowpages) they do NOT own...Ethernet a technology they do NOT >own. Gassee has gone out of his way lately to pronounce [to] the gullible >that licensing technology is bad and proprietary technology is good. However, >one need only look at what Apple *does* to understand the limitations of his >views. I'm glad someone brought this up. Mr. Gassee is a very convincing speaker, and when he says that the only way we can stay ahead of Japan, Inc. is to use proprietary technology and create our own standards, it sounds right. But licensing technology isn't always bad (the example of RCA licensing television technology and then losing to the Japanese). Look at VCRs. JVC is happy to let any American firm use their technology and we're still getting blown out. Sony is too (since their proprietary Beta technology just officially flopped). And at some point standards are necessary. Apple has a superior user-interface; but the graphics engine behind it (QuickDraw) isn't worth extending too much longer. PostScript is better (even Apple had to admit it when they put in the original LaserWriters), and it's where the world is headed. By licensing much of their technology, Sun has single- handedly changed the direction of Unix (from System V back to Berkeley/SunOS). If Apple really wants to change the future of computing, they'd better do the same. -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." ...!cmcl2!esquire!sbb | - David Letterman
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (03/01/88)
In article <1710@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: |The toolbox is hardly something to be touting ... the Mac Toolbox lacks the |sophistication of other systems that incorporate network window management |and extensible window servers. Three years ago this might have been an |appropriate point. My naive impression of the Mac Windows was that is was a useful window system given a single process and a small screen. But I don't understand how Apple can provide the same interface in a multi application environment. How would pull-down menus work with multiple applications? They can't all grab the top of the screen. Context-sensitive pop-up menus make much more sense to me. But then you would need more than one button on the mouse. Someone once made the point that it is easy to grow downward than to grow upward. That is, it is easier to convert a multi-application, multi-tasking, color window system into a single color, single user system than vice versa. I bet Apple is finding out that converting the Mac toolbox to Unix is more complicated than they thought. | Rather it is Apple that is moving more toward |industry standards with NeWS and X sitting on their system. Moving? I think "dragged kicking and screaming" is more appropriate :-) NeWS for the Mac II is looking better and better. Too bad that NeWS wouldn't be practical for a non-A/UX system. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
elwell@tut.cis.ohio-state.edu (Clayton Elwell) (03/01/88)
barnett@steinmetz.ge.com (Bruce G. Barnett) writes:
I bet Apple is finding out that converting the Mac toolbox to Unix
is more complicated than they thought.
Well, Phil Ronzone is entitled to the funny war stories on this one,
but from what he said to me when I picked up our seed EtherTalk card
last year, it was somewhat the other way--everyone was surprised at
just how well it *did* work. (A/UX groupie trivia question here--what
was the first program to use use the toolbox under A/UX?)
As far as I am concerned, I'm willing to bet that now that A/UX and
Multifinder are now actually out the door, the A/UX folks and the Mac
OS folks will finally sit down and get the Printing Manager and the
Layer Manager working across the board. It sure would be nice to have
something that looked like Multifinder on top and A/UX on the bottom.
NeWS has a very high niftitude, but I would love to see the Apple
Desktop Interface on top of it. The demo user interface that comes
with NeWS is better than X, but it's still a hack.
What version of X are we up to now? 11? I'm willing to give Apple
one or two more on the A/UX toolbox...
--
Clayton M. Elwell / elwell@tut.cis.ohio-state.edulad@eplrx7.UUCP (Lawrence A. Dziegielewski) (03/01/88)
From article <1710@ssc-vax.UUCP>, by benoni@ssc-vax.UUCP (Charles L Ditzel): > In article <283@rhesus.primate.wisc.edu>, bin@rhesus.primate.wisc.edu (Brain in Neutral) writes: >> phil@apple.UUCP (Phil Ronzone, A/UX Technical Manager) wrote: >> > Remember - it is a Mac. Under A/UX or the Mac OS, you have the Toolbox >> > and the Mac look and feel. Ain't nobody else got that ... > > The toolbox is hardly something to be touting ... the Mac Toolbox lacks the > sophistication of other systems that incorporate network window management > and extensible window servers. Three years ago this might have been an > appropriate point. Nothng to be touting, eh? The Mac Toolbox and the Mac user interface has set the standard for other PC's to follow for three years now. Sure, it's not network extensible, but it wasn't designed to be either. It *is* THE most consistant user interface on any computer today, and always will be. On no other computer can you find the same commands in the same place on hundreds of different applications. It never ceases to amaze me that the majority of people who malign the Mac are the same people who have never used one. > As for the look and feel ... the Mac certainly has made it's contribution > but since it is not licensable and others can't use it... it is being > by-passed by the remainder of the industry...e.g. SunTools, Presentation > Manager, Apollo's DM, etc. Rather it is Apple that is moving more toward How can you say that the look and feel are being bypassed when nearly every windowing system has either 'borrowed from' or flat out copied the Mac user interface. There's MS Windows, GEM, and countless others who are riding the coat tails of Apple foresight. > industry standards with NeWS and X sitting on their system. Writing > an A/UX application using the Mac Toolbox specifically precludes the > application migrating elsewhere (which in some cases makes sense, but in > most does not if you are interested in portability). Says who? I'm an Apple developer writing applications for the Mac under A/UX. My applications are being written so that they are not only portable to the MacOS, (that's Finder to you), but to vanilla UNIX. too Stuff that in your 3 button mouse. And why shouldn't Apple have NeWS and X on their system? Why should that bother you? Apple has recognized the need to run standard windowng systems in addition to the Finder. I feel that will increase the number of applications that will be ported to the Mac II. > it's been done...why else did Apple sue DRI for GEM. Apple sued DRI for blatantly ripping off the Mac user interface, something it has the right to do. As I have said before, others have borrowed heavily from the Mac OS. And as I recall, didn't Apple grant Microsoft a license to the Apple look and feel for Windows? "All in all, I'd rather use a Macintosh" - W.C. Fields (paraphrased) -- Lawrence A. Dziegielewski | E.I. Dupont Co. uunet!eplrx7!lad | Engineering Physics Lab Cash-We-Serve 76127,104 | Wilmington, Delaware 19898 MABELL: (302) 695-1311 | Mail Stop: E357-318
han@Apple.COM (Byron Han, fire fighter) (03/02/88)
In article <3996@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: >In article <1710@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >|The toolbox is hardly something to be touting ... > >My naive impression of the Mac Windows was that is was a useful window >system given a single process and a small screen. But I don't >understand how Apple can provide the same interface in a multi >application environment. How would pull-down menus work with multiple >applications? They can't all grab the top of the screen. >Context-sensitive pop-up menus make much more sense to me. But then >you would need more than one button on the mouse. Why don't you try out MultiFinder and see how well (in my unbiased :-) opinion) it works? The menu bar reflects the menu appropriate to the topmost application. All the windows that belong to an application reside in a layer. When an application is brought to the front/foreground, all the windows in its layer are brought forward and the menu bar is switched. > Someone once made the point that it is easy to grow downward than to > grow upward. That is, it is easier to convert a multi-application, > multi-tasking, color window system into a single color, single user > system than vice versa. Incidentally, the Macintosh windowing user interface evolved from the Lisa Office System which was a multitasking multiple window, multiple application environment. I don't think that there is much difference between a color and a monochrome windowing system. Disclaimer: This is NOT an official Apple position, just some comments by me. I do work for Apple and happen to love it so take my comments with a grain of NaCl. -- ------------------------ Byron Han, Communications Tool ---------------------- Apple Computer, Inc. 20525 Mariani Ave, MS 27Y Cupertino, CA 95014 ATTnet:408-973-6450 applelink:HAN1 domain:han@apple.COM MacNET:HAN GENIE:BYRONHAN COMPUSERVE:72167,1664 UUCP:{sun,voder,nsc,decwrl}!apple!han
ali@polya.STANFORD.EDU (Ali Ozer) (03/02/88)
In article <3996@vdsvax.steinmetz.ge.com> Bruce G. Barnett writes: >My naive impression of the Mac Windows was that is was a useful window >system given a single process and a small screen. But I don't >understand how Apple can provide the same interface in a multi >application environment. How would pull-down menus work with multiple >applications? They can't all grab the top of the screen. They provide the same sort of interface the Amiga's provided since the beginning --- The menu bar shows the menu options of the application which is active. You just click on another window, and the menu options belonging to the application that owns that window appear in the menu bar. An Amiga feature which I'm sure Mac owners would love to see on their machine is the ability for tasks to open up their own screens. Thus a task requiring 2 colors can open up a single-bit plane screen while a task requiring 4096 colors can open up another --- They both exist in their own screens, which the user can drag up and down and depth arrange. (Of course, each screen can have its own set of windows, and its own set of menus --- after all, each screen has its own menu bar!) This reduces the clutter of having too many windows on the desktop. What happens on the Mac II when a task wants 8 bit planes --- Does the whole desktop change into 8-bit plane mode? Ali Ozer, ali@polya.stanford.edu
lsr@Apple.COM (Larry Rosenstein) (03/02/88)
In article <4129@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >is running unavailable software from Brown University that brings up >pictures and text from British novels, using the Toolbox. (By the way, >they are calling the Brown stuff "hypertext" and taking Ted Nelson's >name in vain. It ain't hypertext, it's just hype.) The name of the system is Intermedia, and it has been described in several papers. I would like to know why you say that Intermedia is not hypertext. (The only thing I can think of is that Intermedia deals with graphics as well as text, and might better be described as hypermedia.) -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
lsr@Apple.COM (Larry Rosenstein) (03/02/88)
In article <3996@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: > >understand how Apple can provide the same interface in a multi >application environment. How would pull-down menus work with multiple >applications? They can't all grab the top of the screen. >Context-sensitive pop-up menus make much more sense to me. But then >you would need more than one button on the mouse. One can switch the menu bar, as is done in MultiFinder. One could have application-specific menus in a bar within the window (as is done in Microsoft Windows). One can have a moveable menu bar, or menus that can be torn off and positioned on the screen (as in HyperCard). One can work around the single mouse button by making a mouse sensitive area that brings up the menus. >Someone once made the point that it is easy to grow downward than to >grow upward. That is, it is easier to convert a multi-application, >multi-tasking, color window system into a single color, single user >system than vice versa. I don't think one direction is easier than another. If you design for the more powerful environment you probably will take advantage of features that aren't available in the other environment. >I bet Apple is finding out that converting the Mac toolbox to Unix >is more complicated than they thought. The difficulty (as I understand it -- I'm not associated with the A/UX project) is getting the exact same code, which is in ROM, and was written for the Mac O/S, to run under A/UX. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
sbb@esquire.UUCP (Stephen B. Baumgarten) (03/02/88)
In article <3996@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: >My naive impression of the Mac Windows was that is was a useful window >system given a single process and a small screen. But I don't >understand how Apple can provide the same interface in a multi >application environment. How would pull-down menus work with multiple >applications? They can't all grab the top of the screen. >Context-sensitive pop-up menus make much more sense to me. But then >you would need more than one button on the mouse. I don't know. Having used 1, 2, and 3 buttons, I find I like 1 button most of all (even though on the Mac we have to remember to hold down certain modifier keys at various times). And as to menus for multiple applications, I really dislike the MS-Windows/Presentation Manager approach of putting the menus in the window themselves -- who wants to see all those menus all the time? Likewise, the popup approach, where you don't see *any* menus until you press a mouse button. I like the Multifinder approach, where although there may be many different applications on the screen (each in their own windows), only one application has control of the menu bar. That way I always know what menus are available, but when I'm in Versaterm (like I am now), I don't see the Finder's menus. On the other hand, what do multi-button, popup menu people think about the new tear-off menus in Hypercard (I like them)? -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." ...!cmcl2!esquire!sbb | - David Letterman
bob@tut.cis.ohio-state.edu (Bob Sutterfield) (03/02/88)
In article <579@eplrx7.UUCP> lad@eplrx7.UUCP (Lawrence A. Dziegielewski) writes: >Apple sued DRI for blatantly ripping off the Mac user interface, >something it has the right to do. Nobody has yet been able to explain to me why Xerox didn't sue Aple for "blatantly ripping off" the UI features developed, or at least solidified, during PARC's glory days. You know the ones: pull-down menus, icons, and such-like stuff. I know that stuff wasn't unique to Xerox; but apparently Jobs got inspired for The Look And Feel while taking a tour of PARC, and they do look awfully darned similar. It seems awfully strange that Apple borrows PARC's work, then gets uptight enough to sue when DRI borrows Apple's instantiation of PARC's work. -- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@cis.ohio-state.edu or ...!cbosgd!osu-cis!bob
benoni@ssc-vax.UUCP (Charles L Ditzel) (03/02/88)
In article <3996@vdsvax.steinmetz.ge.com>, barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) writes: > NeWS for the Mac II is looking better and better. Too bad that > NeWS wouldn't be practical for a non-A/UX system. Actually, funny you mention that, my latest MacWeek sez that the : Grasshopper Group of SF is unveiling and A/UX version of NeWS. and Wedge Computers Inc, of Waltham, Mass. is completing a MacOS version of NeWS. and eXP Inc. of Cambridge, Mass. is also doing NeWS ports.
benoni@ssc-vax.UUCP (Charles L Ditzel) (03/02/88)
In article <7471@tut.cis.ohio-state.edu>, elwell@tut.cis.ohio-state.edu (Clayton Elwell) writes: > NeWS has a very high niftitude, but I would love to see the Apple > Desktop Interface on top of it. The demo user interface that comes > with NeWS is better than X, but it's still a hack. Their is no technical reason that I know of, why the Apple desktop interface couldn't sit on top of NeWS.
benoni@ssc-vax.UUCP (Charles L Ditzel) (03/02/88)
In article <7523@apple.Apple.Com>, han@Apple.COM (Byron Han, fire fighter) writes: > Why don't you try out MultiFinder and see how well (in my unbiased :-) opinion) > it works? The menu bar reflects the menu appropriate to the topmost > application. All the windows that belong to an application reside in a > layer. When an application is brought to the front/foreground, all the windows > in its layer are brought forward and the menu bar is switched. Still sounds awfully serial to me. What happens if you have two windows at the top (i do this on a sun, usually two editting sessions) maybe different editors side by side...? Your menu bar would be constantly changing as you go back and forth (cutting and pasting)... (all that wasted mouse travel time and a wasted mouse click ) I think context-sensitive menus make more sense (try SunView applications and see how well they work) :-) (Seriously, I think a menu bar starts making less sense in a multitasking environment were more than one application is running at a time in a number of different windows )
landauer@morocco.Sun.COM (Doug Landauer) (03/03/88)
> How can you say that the look and feel are being bypassed when nearly every > windowing system has either 'borrowed from' or flat out copied the Mac user > interface. No, most modern window systems borrowed from work done at Xerox PARC, just like Apple did for most of the features of the Mac's user interface. > > why else did Apple sue DRI for GEM. > Apple sued DRI for blatantly ripping off the Mac user interface OK, folks, it's time once again to correct this misinformation. Apple never sued DRI. Apple only threatened to sue, and DRI, which was having financial trouble due to several years of marketing mistakes, prudently chose to change GEM to alter the behavior of the features that Apple's lawyers felt that Apple owned. I believe that the primary Macintosh user-interface feature that Apple felt the legal right to object to in GEM was the top-of-the-screen pull-down menus, which are appropriate only to the tiny screen that the original Mac was saddled with (and to the IBM-PC's CGA). Xerox PARC had used pop-up menus, which are much better suited to the larger screen sizes now (finally!) becoming common. This is one reason why Sun never felt any similar heat from Apple. Not coincidentally, that feature is one of the ones being bypassed by window systems designed for larger screens. - Doug Landauer Sun Microsystems, Inc. ARPA Internet: landauer@sun.com Software Products Division UUCP: ...!sun!landauer
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (03/03/88)
I wrote: | I bet Apple is finding out that converting the Mac toolbox to Unix | is more complicated than they thought. In article <7471@tut.cis.ohio-state.edu> elwell@tut.cis.ohio-state.edu (Clayton Elwell) writes: |[...] it was somewhat the other way--everyone was surprised at |just how well it *did* work. I didn't mean emulating a single application using A/UX, but extending the user interface to handle multiple applications simultaneously. I want to use several Mac applications simultaneously. I have trouble visualizing the bar along the top and the functions in a multi-application environment. Every application needs it's own bar. But the standard Mac interface would put them all in the same place. Someone suggested to me that the window/application on the top would 'own' the top bar. But you would have to keep changing which application is on top of which to use the functions provided by a bar. In this case, a pop-up menu would be much more convenient. Less mouse travel on a large screen. No change in the window overlapping. Window systems that force the active window to be on top on the stack are a real pain. Just an opinion, of course. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
benoni@ssc-vax.UUCP (Charles L Ditzel) (03/03/88)
In article <579@eplrx7.UUCP>, lad@eplrx7.UUCP (Lawrence A. Dziegielewski) writes: > From article <1710@ssc-vax.UUCP>, by benoni@ssc-vax.UUCP (Charles L Ditzel): > Nothng to be touting, eh? The Mac Toolbox and the Mac user interface has > set the standard for other PC's to follow for three years now. Sure, it's > not network extensible, but it wasn't designed to be either. It *is* THE > most consistant user interface on any computer today, and always will be. > On no other computer can you find the same commands in the same place on > hundreds of different applications. If you like the monochromatic look that's fine...and I do generally... but it is the heighth of hubris to believe that some applications would not operate better without this interface...so before getting excited ... I would hope you would see that in *fact* with each new addition of a feature the Mac look and feel is *changing*. Hypercard's "home" for example is hardly in keeping with the "look and feel" you talk about...what will multi-tasking do to it? The Mac is evolving ... and hopefully to something better. > It never ceases to amaze me that the majority of people who malign the Mac > are the same people who have never used one. Interesting, I have spent *alot* of time on the Mac...so I hope you are talking about someone else. ... incidentally I was not maligning the Mac at all...I was stating the user interface practices have moved on since the Mac's introduction . Instead of religious flaming why not look at what Apollo, Sun, Xerox and Symbolics are doing. I am familiar with these machines and they have alot to offer. > > As for the look and feel ... the Mac certainly has made it's contribution > > but since it is not licensable and others can't use it... it is being > > by-passed by the remainder of the industry...e.g. SunTools, Presentation > > Manager, Apollo's DM, etc. Rather it is Apple that is moving more toward > How can you say that the look and feel are being bypassed when nearly every > windowing system has either 'borrowed from' or flat out copied the Mac user > interface. There's MS Windows, GEM, and countless others who are riding > the coat tails of Apple foresight. Funny...I didn't know Apple invented "the menu"(nor "the icon")..and they did not...GEM certainly did copy Apple (in my opinion)...as for SunTools and DM not at all. Unless you also think that Apple invented the "icon"...? :) SunTool has context-sensitive menus that can be customized by the user (or they can accept the default). Sun's Windows and user interface is *completely* customizable (like the control panel but much more extensive) (one can for example set a visual bell or an a audible bell, tabs, gravity (where the cursor will appear when a new window is generated), pull-right menus can be customized (whole trees can be created if you desire...)...the DM and SunTool environments allow you to for example to cut and paste the command line arguements (as well as among editors) and these operations can become object oriented....for example...in DM you can select the word "file.x" and click the mouse...you then pull up a view or editor with file.x in it. Incidentally...you seem to think that Apple worked from a vacuum...you don't mention Xerox or Xerox licenses. > > industry standards with NeWS and X sitting on their system. Writing > > an A/UX application using the Mac Toolbox specifically precludes the > > application migrating elsewhere (which in some cases makes sense, but in > > most does not if you are interested in portability). > Says who? I'm an Apple developer writing applications for the Mac under > A/UX. My applications are being written so that they are not only portable > to the MacOS, (that's Finder to you), but to vanilla UNIX. too Stuff that (Obviously you are incensed by what you view as heretical ideas) good for you ... i don't think too many Unix systems have Mac Toolbox calls...sorry to break the news ... you make my point quite nicely...you will not be using the Mac Toolbox on other systems. So what "industry standard" will you be using NeWS or X? :) > And why shouldn't Apple have NeWS and X on their system? Why should that > bother you? Apple has recognized the need to run standard windowng systems doesn't bother me a bit. tho' It seems to bother you more. Personally, i think NeWS and X are *good* for the Mac II. My problem is with attitudes that permeate your posting...if for example NeXT or some other company came out with a more elegant user interface...i get the feeling you would ignore it. ----------------- My opinions are my own. Thankfully.
benoni@ssc-vax.UUCP (Charles L Ditzel) (03/03/88)
In article <346@esquire.UUCP>, sbb@esquire.UUCP (Stephen B. Baumgarten) writes: > On the other hand, what do multi-button, popup menu people think about > the new tear-off menus in Hypercard (I like them)? Even tho' I have played with hypercard I had no idea what a tear-off menu was. ..i had to ask someone...they said..."Some Mac people think floating menus are new.... to me it's a floating menu...this is a standard part of SunTools and Apollo Dialog...nothing new at all... actually a refinement of what you call the tear off menu ... is that you click inside a window and a menu pops up...tho' if you *only* have one button on your mouse this might not be practical. (I must confess I think one button mice are obsolete...the above being just one reason...i also think mechanical mice are worthless ...On Apollo's and Sun's it is possible to "program" each mouse button ...so if you want the first button is "SELECT", second can be "OPEN AN EDIT SESSION" on the file name i am pointing at, third might be "ICONIFY" (make window into an icon) )
cswarren@gershwin.berkeley.edu (Warren Gish;133B Biochem;x3-9219) (03/03/88)
In article <7550@tut.cis.ohio-state.edu> bob@tut.cis.ohio-state.edu (Bob Sutterfield) writes: >Nobody has yet been able to explain to me why Xerox didn't sue Aple Is this their problem or yours? :^) >for "blatantly ripping off" the UI features developed, or at least >solidified, during PARC's glory days. The way I heard it, Apple licensed parts of its user interface from Xerox/PARC. And I assume the licensing agreement met with such agreement that law suits weren't suitable. Warren Gish IS&T UC Berkeley cswarren@violet.berkeley.edu cswarren@ucbviole.bitnet
MJSCHMEL@pucc.Princeton.EDU (Michael J. Schmelzer) (03/03/88)
In article <7550@tut.cis.ohio-state.edu>, bob@tut.cis.ohio-state.edu (Bob Sutterfield) writes: >Nobody has yet been able to explain to me why Xerox didn't sue Aple >for "blatantly ripping off" the UI features developed, or at least >solidified, during PARC's glory days. You know the ones: pull-down Apple cut a deal with Xerox. My recall of the details is sketchy but I believe that Xerox owns at least 2% of Apple, with an option on an even greater interest. ============================================================================== comes around Mike Schmelzer MJSCHMEL@PUCC.Princeton.Edu what goes around ==============================================================================
landauer@morocco.Sun.COM (Doug Landauer) (03/04/88)
In article <43879@sun.uucp>, I wrote: > > I believe that the primary Macintosh user-interface feature that Apple > felt the legal right to object to in GEM was the top-of-the-screen > pull-down menus ... Taken out of the context of the discussion of window systems, this was a misleading statement. Apple's other legitimate objections were to the GEM *applications* GEM-Write, GEM-Paint and GEM-Draw, whose looks were indeed copied identically (well, as well as you could do on an IBM-PC) from the corresponding Mac applications. -- Doug Landauer Sun Microsystems, Inc. ARPA Internet: landauer@sun.com Software Products Division UUCP: ...!sun!landauer
johng@ecrcvax.UUCP (John Gregor) (03/05/88)
In article <579@eplrx7.UUCP> lad@eplrx7.UUCP (Lawrence A. Dziegielewski) writes: >How can you say that the look and feel are being bypassed when nearly every >windowing system has either 'borrowed from' or flat out copied the Mac user >interface. There's MS Windows, GEM, and countless others who are riding >the coat tails of Apple foresight. Ummmm, excuse me, but wasn't a lot of that "Apple foresight" work that was pioneered by Xerox PARC about half a decade earlier? I think the "Apple foresight" you mean is that they had the foresight to 'borrow from' or flat out copy PARC's work before DRI. -- pqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpq bdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbd John Gregor johng%ecrcvax.UUCP@germany.CSNET
sbb@esquire.UUCP (Stephen B. Baumgarten) (03/05/88)
In article <1723@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >Interesting, I have spent *alot* of time on the Mac...so I hope you are >talking about someone else. ... incidentally I was not maligning the Mac >at all...I was stating the user interface practices have moved on since the >Mac's introduction . Instead of religious flaming why not look at what >Apollo, Sun, Xerox and Symbolics are doing. I am familiar with these >machines and they have alot to offer. Actually, the only thing Symbolics is doing these days is laying people off. At least they're still one step ahead of rival Lisp Machines, a company that now dearly wishes it had spent more time developing expert systems in bankruptcy litigation... [ :-), you know. I just like poking fun at AI every now and then... ] -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." ...!cmcl2!esquire!sbb | - David Letterman
ws0n+@andrew.cmu.edu (Walter Ray Smith) (03/06/88)
> What happens on the Mac II when a task wants 8 bit > planes --- Does the whole desktop change into 8-bit plane mode? Things kind happen the other way around on the Mac II. The user sets the number of bits on the screen, and the applications adjust themselves. Color Quickdraw is set up to handle this by making the display less accurate (if you want a certain color, but there aren't any more colors available, you get the closest existing one). You're right; some mechanism is always needed for dealing with the window clutter. I imagine the Mac solution will be a "Set Aside" operation that packs up a running application into an icon on the desktop. This was part of the Lisa interface, and since Macs are slowly turning into Lisas (multitasking, menu-bar switching, stationery documents, etc.), it would make sense. - Walt -- Walter Smith, CS graduate student, Carnegie-Mellon University uucp: ...!seismo!cmucspt!wrs ARPA: Walter.Smith@andrew.cmu.edu usps: 5706 Darlington Rd.; Pittsburgh, PA 15217
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (03/07/88)
In article <1718@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: |Their is no technical reason that I know of, why the Apple |desktop interface couldn't sit on top of NeWS. Absolutely right. NeWS can emulate any window system I know of. There is already a GEM emulator. In fact, you can theoretically pop up a menu and choose which window system you would like to emulate. This would even work with applications in shrink-wrap packages, due to the dynamic and flexible nature of NeWS. Even now there are people whom are emulating SunView, X, and GEM windows simultaneously. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (03/07/88)
In article <7523@apple.Apple.Com> han@apple.UUCP (Byron Han, fire fighter) writes: |In article <3996@vdsvax.steinmetz.ge.com> I wrote: |> Someone once made the point that it is easy to grow downward than to |> grow upward. That is, it is easier to convert a multi-application, |> multi-tasking, color window system into a single color, single user |> system than vice versa. | |Incidentally, the Macintosh windowing user interface evolved from the Lisa |Office System which was a multitasking multiple window, multiple application |environment. I don't think that there is much difference between a |color and a monochrome windowing system. Well, I suppose I wasn't clear. Designing a complex window system that will work with monochrome or color, single user or multi user, small hardware or big, floppy or disk, is a difficult job. Look at Sun's window systems. There was the original, then SunWindows, SunView, SunDew, NeWS and now NeWS/X11. It is even more difficult to provide a migration strategy from the old window system. In simple terms, no window system is ever complete. The better ones provide the most flexibility. I read somewhere that 35% of the current Mac software packages do not obey the guidelines that will provide portability to future window systems for the Mac. This figure in itself - I believe - lends some creedence to my claim. Then there are issues that complex window systems must address. Let's assume you have several applications running at once. Now let's assume that one application wants to track the mouse cursor as it passes through, while others are only interested in the selection of an item from a menu. SunView has a selection service that sits above all applications, and analyzes the stream of input events. It distributes to the applications the events they are interested in, in a concise and efficient manner. Mouse-ahead works even in these conditions. I don't know how the Mac handles this task. I would assume that it is a lot simpler because only one task runs at a time. Another example is the evolution from monochrome to color. How was the migration to a color system handled? Were the system calls changed, and therefore incompatible? Or were new calls created, that had similar functions to the monochrome but had new names and features? I would be extremely suprised, and extremely impressed, if the original calls to the monochrome Mac toolkit were integrated into the color version of the same. If you look at the complexity of coloring single pixels, and applying boolean masking operations to the screen, you can see that handling 1-bit deep and 2, 4, 8 or 24 bit deep pixels are very different at the hardware level. Yet the software interface should be the same, with only a few differences. I am guessing about the Mac toolkit. But Sun's PixRect package has only two special calls for color systems - setting and getting the current colormap. All of the other calls are used for both monochrome and color screens. This leads me to a third example. SunView allows applications to specify the number of colors needed for each application. If possible, the colormap will contain as many maps as possible in the 256 possible values, allowing several tasks to run using just one colormap. This sort of forethought is needed when planning something like the color toolkit that is currently stored on ROM on the Mac II. I know very little about the Mac toolkit, and have only tried to make some educated guesses. Actually, I look forward to hearing how wrong I am. But I wouldn't be suprised if the ROM on the Mac II needs a major re-write when Apple finally get's the REAL A/UX window system working. An upgrade that will be _required_ - before the new A/UX window system can be used. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
lad@eplrx7.UUCP (Lawrence A. Dziegielewski) (03/07/88)
From article <507@ecrcvax.UUCP>, by johng@ecrcvax.UUCP (John Gregor): > In article <579@eplrx7.UUCP> lad@eplrx7.UUCP (Lawrence A. Dziegielewski) writes: >>How can you say that the look and feel are being bypassed when nearly every >>windowing system has either 'borrowed from' or flat out copied the Mac user >>interface. There's MS Windows, GEM, and countless others who are riding >>the coat tails of Apple foresight. > > Ummmm, excuse me, but wasn't a lot of that "Apple foresight" work that > was pioneered by Xerox PARC about half a decade earlier? > > I think the "Apple foresight" you mean is that they had the foresight to > 'borrow from' or flat out copy PARC's work before DRI. I have never stated that Apple invented pull-down menus or icons. Steve Jobs spent a great deal of time at PARC in the early days observing their work with user interfacing and windowing systems. Alot of what Steve saw there ended up in the Finder, and I beleive that no one denies that. However, Steve and Apple (and Andy Hertzfeld) made it easier to use than the PARC interface. Andy added a "Toolbox" of routines which transformed the Mac from 'just another computer with windows' to *the* user interface standard which others would soon follow. And don't forget the Mac was the first 'commercially available' personal computer to feature a windowing interface and a secondary input device known as a mouse. The rest of the world laughed at the Mac. I bought mine home in March of 1984 and all of my esteemed computer friends wanted to come over and 'play with the toy'. It seems odd that shortly after 'the toy' hit the streets every other PC maker wanted windows, and a mouse, and started copying it. And that's what I refer to as 'borrowing from'. Apple had the foresight that the other computer companies didn't. Until, of course, Apple starting having success with the Mac. Everybody else wanted in then. -- Lawrence A. Dziegielewski | E.I. Dupont Co. uunet!eplrx7!lad | Engineering Physics Lab Cash-We-Serve 76127,104 | Wilmington, Delaware 19898 MABELL: (302) 695-1311 | Mail Stop: E357-318
stuart@ihlpf.ATT.COM (S. D. Ericson) (03/07/88)
In article <7550@tut.cis.ohio-state.edu>, bob@tut.cis.ohio-state.edu (Bob Sutterfield) writes: > In article <579@eplrx7.UUCP> lad@eplrx7.UUCP (Lawrence A. Dziegielewski) writes: > >Apple sued DRI for blatantly ripping off the Mac user interface, > >something it has the right to do. > > Nobody has yet been able to explain to me why Xerox didn't sue Aple > for "blatantly ripping off" the UI features developed, or at least > solidified, during PARC's glory days. You know the ones: pull-down > menus, icons, and such-like stuff. I know that stuff wasn't unique to [etc..] This is an argument I've seen over and over. But I think a lot of people don't realize that *Apple* invented Pull-down menus. Xerox has Pop-Up menus, a much different concept that tends to require a multiple-button mouse. Pull-down menus allow for that wonderfully simple *1* button mouse. There are other aspects of the mac environment that were significant developments of the xerox ideas, but this one happens to be my own favorite pet peeve. Stu ---------------------------- "PS/2: Yesterday's hardware today. OS/2: Yesterday's software tomorrow." -- Henry Spencer -- Stuart Ericson USnail: AT&T Bell Laboratories USENET: ...!ihnp4!ihlpf!stuart IH 6M-313 voice: (312) 979-4152 Naperville-Wheaton Rd. Naperville, Il 60566
fry@huma1.HARVARD.EDU (David Fry) (03/08/88)
In article <4015@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: [...] >Then there are issues that complex window systems must address. >Let's assume you have several applications running at once. >Now let's assume that one application wants to track the mouse cursor >as it passes through, while others are only interested in the >selection of an item from a menu. > >SunView has a selection service that sits above all applications, >and analyzes the stream of input events. It distributes to the >applications the events they are interested in, in a concise >and efficient manner. Mouse-ahead works even in these conditions. > >I don't know how the Mac handles this task. I would assume that it is >a lot simpler because only one task runs at a time. Every application can define exactly what events it wants to look at. If it is running in single application environment (i.e., the "normal" mode until now) this is not very important, but under MultiFinder this can save time. >Another example is the evolution from monochrome to color. >How was the migration to a color system handled? Were the system calls >changed, and therefore incompatible? Or were new calls created, that >had similar functions to the monochrome but had new names and >features? > >I would be extremely suprised, and extremely impressed, if the >original calls to the monochrome Mac toolkit were integrated into >the color version of the same. If you look at the complexity of >coloring single pixels, and applying boolean masking operations to the >screen, you can see that handling 1-bit deep and 2, 4, 8 or 24 bit >deep pixels are very different at the hardware level. > >Yet the software interface should be the same, with only a few >differences. I am guessing about the Mac toolkit. But Sun's PixRect >package has only two special calls for color systems - setting and >getting the current colormap. All of the other calls are used for >both monochrome and color screens. Surprise, same thing on the Mac II. The entire original Mac toolkit is still there and most routines have been updated to act in a color environment if necessary. For instance, CopyBits() now copies bitmaps of any depth, performing the necessary mapping between different color tables. >This leads me to a third example. SunView allows applications to >specify the number of colors needed for each application. If possible, >the colormap will contain as many maps as possible in the 256 possible >values, allowing several tasks to run using just one colormap. The Mac II has something better, called the Palette Manager. A program can define what colors are necessary for displaying any given window, with various contraints on the colors. For instance you can insist that such-and-such colors be present, or insist that such-and-such colors are present, plus or minus a certain tolerance, or ask for certain colors to be present, if possible. You can also ask that certain colors be present in certain color table locations exactly, but that is frowned upon by Apple since it is unfriendly to other programs in a multitasking environment. The Palette Manager makes sure that those colors are available whenever the user switches the active window. If there is a color conflict (if an inactive window wants different colors from the active window), the Palette Manager will try to determine which colors are least used and replace them. The Palette Manager also has color table animation routines. David Fry fry@huma1.harvard.EDU Department of Mathematics fry@harvma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
dwb@Apple.COM (David W. Berry) (03/09/88)
>I read somewhere that 35% of the current Mac software packages >do not obey the guidelines that will provide portability to future >window systems for the Mac. This figure in itself - I believe - >lends some creedence to my claim. This would be a reasonable belief, were it true that all the sidestepping was done to provide additional functionality to the window or menu manager or other user interface function. More often than not, it's done in the name of speed, or in not wanting to find the documented portable solution, or to add functionality to the operating system ... >I don't know how the Mac handles this task. I would assume that it is >a lot simpler because only one task runs at a time. The mac "simplfies" things for the user by denoting one application, the "current" application. It is the only application which can receive input from the user. This is an extension of the idea that only the current window receives user input. > >Another example is the evolution from monochrome to color. >How was the migration to a color system handled? Were the system calls >changed, and therefore incompatible? Or were new calls created, that >had similar functions to the monochrome but had new names and >features? From the level of windows, menus, etc. the changes were, by and large invisible. The programmatic interface remains the same but additional information could be hidden in the resources to colorize the windows. Resources, for those of you that don't know it are templates for windows, menus, etc. that users or programmers can easily change. Functionality can't be affected much but appearance can be. From the level of drawing primitives, all the old monochrome stuff still works. There are added calls to change the current drawing color and similar stuff, but the basic primitives remain the same old orthogonal set: {Fill,Erase,Frame,Invert,Paint}\ {Rect,Oval,RoundRect,Arc,Region,Polygon} and the line and text drawing primitives. > >I would be extremely suprised, and extremely impressed, if the >original calls to the monochrome Mac toolkit were integrated into >the color version of the same. If you look at the complexity of >coloring single pixels, and applying boolean masking operations to the >screen, you can see that handling 1-bit deep and 2, 4, 8 or 24 bit >deep pixels are very different at the hardware level. I'll consider you impressed and surprised :-) > >Yet the software interface should be the same, with only a few >differences. I am guessing about the Mac toolkit. But Sun's PixRect >package has only two special calls for color systems - setting and >getting the current colormap. All of the other calls are used for >both monochrome and color screens. Sounds familiar. > >This leads me to a third example. SunView allows applications to >specify the number of colors needed for each application. If possible, >the colormap will contain as many maps as possible in the 256 possible >values, allowing several tasks to run using just one colormap. This one area I would consider lacking on the mac. There is only one CLUT per screen, where one per window would be kind of nice. >But I wouldn't be suprised if the ROM on the Mac II needs a major >re-write when Apple finally get's the REAL A/UX window system working. >An upgrade that will be _required_ - before the new A/UX window system >can be used. I think you'll be very and pleasantly surprised. >-- > Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> > uunet!steinmetz!barnett David W. Berry dwb@well.uucp dwb@Delphi dwb@apple.com 973-5168@408.MaBell Disclaimer: Apple doesn't even know I have an opinion and certainly wouldn't want if they did.
des@jplpro.JPL.NASA.GOV (David Smyth) (03/09/88)
stuart@ihlpf.ATT.COM (S. D. Ericson) writes: >bob@tut.cis.ohio-state.edu (Bob Sutterfield) writes: >> lad@eplrx7.UUCP (Lawrence A. Dziegielewski) writes: >> >Apple sued DRI for blatantly ripping off the Mac user interface, ... >> Nobody has yet been able to explain to me why Xerox didn't sue Aple >> for "blatantly ripping off" the UI features developed, or at least >> solidified, during PARC's glory days. You know the ones: pull-down >> menus, icons, and such-like stuff. ... > >This is an argument I've seen over and over. But I think a lot of people >don't realize that *Apple* invented Pull-down menus. I dunno about this. Xerox certainly does have menus which pop when you hit a mouse button over an item with several choices. Does anybody really know who licensed what, who is a thief, and who is creative? I certainly have seen nothing "new" about the Mac interface over the Xerox stuff. Note that Xerox is now touting "rooms" which sound alot like the Mac. Anybody actually using XDE, Viewpoint, or the other Xerox environments care to comment?
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (03/09/88)
In article <7598@apple.Apple.Com> dwb@apple.UUCP (David W. Berry) writes: | The mac "simplfies" things for the user by denoting one |application, the "current" application. It is the only application |which can receive input from the user. This is an extension of |the idea that only the current window receives user input. This raises an interesting point. One of the events SunView can trap is the mouse entering and exiting the window. One use is to change the mouse cursor while in one window. (One program we have called fig, tracks the mouse and provides horizontal and vertical arrows on the top and left grid.) Now what happens when several applications are open, and the mouse is moved through each of the windows? Is the application with the mouse over it active, or the application on top? If it is the application on top, then lower applications wouldn't receive the events of the mouse passing through the window. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
wagner@gypsy.siemens-rtl (Mike Wagner) (03/10/88)
In article <1512@devvax.JPL.NASA.GOV> des@jplpro.JPL.NASA.GOV (David Smyth) writes: >stuart@ihlpf.ATT.COM (S. D. Ericson) writes: >>bob@tut.cis.ohio-state.edu (Bob Sutterfield) writes: >>This is an argument I've seen over and over. But I think a lot of people >>don't realize that *Apple* invented Pull-down menus. > >I dunno about this. Xerox certainly does have menus which pop when >you hit a mouse button over an item with several choices. > >Does anybody really know who licensed what, who is a thief, and >who is creative? I certainly have seen nothing "new" about the >Mac interface over the Xerox stuff. > If you define "pull-down menus" to mean "click a mouse button while the mouse is over some labelling image to bring up a menu" then the Xerox Star (now Viewpoint) environment definitely had it before the Mac was on the market. I worked for about 2 1/2 years at Xerox, so can speak with a bit of authority. Every editor window in Star had (has) two little iconic pictures in the title stripe. If you click on one of these, a menu pops up and you can select an item from it. Also, the screen had a small, narrow window across the top of the screen, with a little picture in the far right. Click on this to bring up a menu that did "system" kinds of things (invert the screen, logoff, ...). An interesting anecdote. When I was working at Xerox, some people from DRI came up from Monterey to talk to my manager about their troubles with Apple. Seems they wanted to see a Star environment and possibly use it as ammunition. They were *extremely* pleased to see those pictures with menus under them. Don't know what they did with this information. Maybe they're "copyright infringements" were much more than just pull-down menus (MacPaint, ...). Or maybe they couldn't afford the fight. At Xerox we were all pulling for DRI. Wish they'd stuck it out. Mike Wagner Siemens Research & Technology Labs UUCP: ...!princeton!siemens!gypsy!wagner Princeton, NJ 08638 ARPA: wagner@gypsy.siemens.com
phil@Apple.COM (Phil Ronzone) (03/10/88)
In article <4015@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: >But I wouldn't be suprised if the ROM on the Mac II needs a major >re-write when Apple finally get's the REAL A/UX window system working. >An upgrade that will be _required_ - before the new A/UX window system >can be used. I am not sure what the REAL A/UX window system is supposed to be. And I hope I would be the first to know. ( :-) ) However, the cleanliness and "work- ability" of the Mac OS ROMs in a 32-bit address space has been very very good. I think our most notable bug was in some color code in Quickdraw, where arithmetic shifts instead of logical shifts were being done. We will be using the exact same ROMs as the MAC OS. To be sure, the ROMs have been "A/UX sensitized" for some time now, but things like 32-bit universe expectations are good for the ROMs in any case, A/UX or not. In other words, it will be over dead bodies that Apple will have more than one set of Quickdraw/Toolbox ROMs (A/UX & MAC OS). And none of wish t die ... :-) Just wanting to set the record straight. ------------------------------------------------------------------------------- Philip K. Ronzone, A/UX Technical Manager APPLELINK: RONZONE1 Apple Computer, Mail Stop 27AJ, 10500 N. DeAnza Blvd. Cupertino, CA 95014 UUCP: ...!{sun,voder,nsc,mtxinu,dual,unisoft}!apple!phil -- ------------------------------------------------------------------------------- Philip K. Ronzone, A/UX Technical Manager APPLELINK: RONZONE1 Apple Computer, Mail Stop 27AJ, 10500 N. DeAnza Blvd. Cupertino, CA 95014 UUCP: ...!{sun,voder,nsc,mtxinu,dual,unisoft}!apple!phil
wetter@tybalt.caltech.edu (Pierce T. Wetter) (03/11/88)
>An interesting anecdote. When I was working at Xerox, some people from DRI >came up from Monterey to talk to my manager about their troubles with Apple. >Seems they wanted to see a Star environment and possibly use it as ammunition. >They were *extremely* pleased to see those pictures with menus under them. >Don't know what they did with this information. Maybe they're "copyright >infringements" were much more than just pull-down menus (MacPaint, ...). >Or maybe they couldn't afford the fight. At Xerox we were all pulling for DRI. >Wish they'd stuck it out. In other words, they'd never seen anything _but_ the mac environment so they must of copied the mac interface exactly. If they'd never seen a star they couldn't have copied it. QED. PIerce Wetter Bolub's Fourth Law of Computerdom: Project teams detest weekly progress reporting because it so vividly manifests their lack of progress. -------------------------------------------- wetter@tybalt.caltech.edu --------------------------------------------
lsr@Apple.COM (Larry Rosenstein) (03/12/88)
In article <484@siemens.UUCP> wagner@gypsy.UUCP (Mike Wagner) writes: > >If you define "pull-down menus" to mean "click a mouse button while the mouse >is over some labelling image to bring up a menu" then the Xerox Star (now What you described is what people generally call popup menus. I think the idea of displaying a list of menu titles in a fixed place is also part of the pull-down menu concept. The user can also move the mouse over each title in turn to see all the command available. Experienced users can take advantage of the fact that the menus appear in the same place each time, and can anticipate where on the screen an item will fall. >They were *extremely* pleased to see those pictures with menus under them. >Don't know what they did with this information. Maybe they're "copyright >infringements" were much more than just pull-down menus (MacPaint, ...). I think this was the case. They copied many aspects of the Macintosh user interface (down to the set of system patterns). Also, the issue as I understood it was the overall appearance of the user interface. The Xerox menus and the Apple menu looked totally difference, although one could easily see the heritage. The same was not true of GEM. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
lsr@Apple.COM (Larry Rosenstein) (03/12/88)
In article <4035@vdsvax.steinmetz.ge.com> barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) writes: > >Now what happens when several applications are open, and the mouse is >moved through each of the windows? > >Is the application with the mouse over it active, or the application on top? > >If it is the application on top, then lower applications wouldn't >receive the events of the mouse passing through the window. If you are dealing with a single application, then it is possible to track the mouse over windows that are inactive. If you are dealing with multiple applications, then the answer is no. The cursor shape should be considered part of the input focus (since it signifies what happens when you click the mouse), and the frontmost application owns the input focus. This whole discussion about user interfaces was missed some of the subtle features of the Mac, which enhance its usability. For example, it is possible to program your application so that clicking in an inactive window works exactly like clicking in an active window. Normally, clicking in an inactive window simply brings that window to the front. In many applications, you want the user to be able to click on anything that is visible even if it is not in an active window. (The Finder does this with icons, and it works very well.) I think it is pointless to discuss user interfaces feature by feature. The Mac was designed with very different goals than the Sun. These goals end up influencing the user interface and system design. There are going to be many user interface features on the Sun that aren't used (or can't be done) on the Mac, and vice versa. This does not make one system better than the other. If you analyze the particular feature and what it is trying to accomplish, then you can probably find a suitable way to implement it on the Mac. If you simply try to port an interface from another machine, then it may not work as well. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
jeff@polyslo.UUCP (Jeff Weinstein) (03/12/88)
In article <5723@cit-vax.Caltech.Edu> wetter@tybalt.caltech.edu.UUCP (Pierce T. Wetter) writes: > In other words, they'd never seen anything _but_ the mac environment so they >must of copied the mac interface exactly. If they'd never seen a star they >couldn't have copied it. QED. >PIerce Wetter Are you saying that no one at DRI was capable of an original thought or even a bit of creativity? That they must have copied everything from Apple if they did not copy it from Xerox? If so you might post some evidence of this. Jeff Weinstein Computer Systems Lab Cal Poly State Univ jeff@polyslo.uucp ucbvax!voder!polyslo!jeff
peter@sugar.UUCP (Peter da Silva) (03/14/88)
There are two innovations in the Mac environment that rightly belong to Apple. They're not a knock-off of anything Xerox did, and they're both part and parcel of the one-button mouse. They are pull-down menus and doubleclicking. There are three things that are commonly done with a mouse in a well-designed user interface. They are (1) selecting an object or objects (including dragging them), (2) activating an object, and (3) bringing up a menu relating to the selected object or objects if you want to do more than the default action command. The ideal situation would be to have three buttons for this. A SELECT button, a DOIT button, and a MENU button. On the Mac all three of these are overlaid on one button, so everything's jammed into the selection button. On the Amiga, there's a SELECT button and a MENU button. DOIT could have been mapped into holding down both buttons, but that was used for extended menu selections and they copied doubleclicking for the DOIT action. Some systems have all three buttons... and even use them this way. Now then. It seems (based on this discussion) that the Sun uses the three buttons as extra keys, with common commands mapped into them. This isn't bad, if you can program them to behave in the fashion described above. It'd be preferable if this was the default behaviour, and even that it was the only behaviour. After all, you don't reprogram the shift and control keys. I hope. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
goldman@Apple.COM (Phil Goldman) (03/14/88)
In article <3690@bloom-beacon.MIT.EDU> you write: >In article <7656@apple.Apple.Com> lsr@apple.UUCP (Larry Rosenstein) writes: >> MultiFinder is not >>large (50K) and it works very well. > >Well, size is all relative, you know. 50K is more RAM than my >friend's Apple II ever had. And almost as much as the roms in the >orignal Macs. 50K includes both (C) code and data, as opposed to the ROM, which is code only. This number would have been about 9-10K if it had been built in from the start. However, as new ROMs get created the MF code can be put into ROM, just as system patches are. > But whatever your standards, you can't say 50K is >insignificant. > True, but hopefully what you get for 50K isn't either. Besides, it definitely pales in comparison to the size of kernels of other OS's, and only a fraction of MultiFinder is its kernel. >>>What's that? Mac software? Who cares about Mac software? >> >>Millions of people care. > >Sigh. I forgot to put in the :-). I know perfectly well that my >argument is an attempt to compare multitasking and MultiFinder in a >vacuum. The logic is so clean when you ignore other variables. > >Reality is messy. I know that millions of people own Mac software, >and that this is MultiFinder's greatest (only?) advantage. Of course, >_I_ don't own any Mac software, so why should I care, right? :-) :-) > >If all you want to do is compare multitasking and Multifinder _as_ >_tools_for_switching_between_programs_, I stand by my argument. If I agree. MultiFinder has made life more difficult (only a little, though) for application developers in order to make life a great deal easier for end-users. I think much of the argument depends on what point of view you take. Adam argues from the programmer's point of view, Larry (and other Apple people) from the user's. >>If you simply judge systems on the basis of multitasking, then MultiFinder >>would not offer any advantages. Most users, however, don't buy computers >>based on operating system features. > >Hear hear! Couldn't have said it better myself! > Again, it depends on what point of view you take. MF offers many advantages for the user. It offers most of the same advantages as preemptive multitasking for well-behaved programs. I think one point you are both missing out on is that preemptive multitasking requires hardware support not available on a 68000. It is not compatibility that stops us from implementing preemption, although it does pose some hairy problems, but the requirement that we can run on a MacPlus and SE. It may be that preemptive multitasking is preferable to cooperative multitasking -- this is the real argument here, at least the really interesting one -- but it isn't possible on a MacPlus. We are investigating preemption on the MacII. As far as which type of multitasking is preferable, I think the answer is, a combination of both. Even if preemption is available it is still *highly* desirable to allow the application to notify the OS that it has nothing useful to do for a given time period. -Phil Goldman Apple Computer
mwm@eris (Mike (My watch has windows) Meyer) (03/15/88)
[Followups have been pointed to comp.sys.68k.]
In article <7670@apple.Apple.Com> goldman@apple.UUCP (Phil Goldman) writes:
<I think one point you are both missing out on is that preemptive multitasking
<requires hardware support not available on a 68000.
Right. So how did Sun, Apollo, Amiga, Sage, Stride and a multitude of
others manage to market 68000 systems that did preemptive
multitasking?
All you need to manage preemptive multitasking is a way to take
interrupts that allows you to save the old context, and the mechanisms
needed for a non-preemptive scheduler.
Being able to save the old context can be a bear - you have to either
not interrupt instructions, or be able to rewind/restart an
instruction. On the 68K, about the only thing that causes serious
problems is bus & address errors. Address errors are sufficient to
abort the processes causing it (or panic the OS). Bus errors do the
same in non-VM systems. In vm systems, they could indicate a page
fault, which has to be dealt with.
Here is where the 68000 has problems: there's not enough information
around to restart a process that page faults in the middle of some
instructions. The 68010 & later processors fixed this. But people
found ways around that problem with thoe 68000.
<-Phil Goldman
<Apple Computer
<mike
--
Il brilgue: les toves lubricilleux Mike Meyer
Se gyrent en vrillant dans le guave, mwm@berkeley.edu
Enmimes sont les gougebosqueux, ucbvax!mwm
Et le momerade horsgrave. mwm@ucbjade.BITNETpeter@nuchat.UUCP (Peter da Silva) (03/15/88)
In article <7655@apple.Apple.Com>, lsr@Apple.COM (Larry Rosenstein) writes: > In article <484@siemens.UUCP> wagner@gypsy.UUCP (Mike Wagner) writes: > >If you define "pull-down menus" to mean "click a mouse button while the mouse > >is over some labelling image to bring up a menu" then the Xerox Star (now > What you described is what people generally call popup menus. No, it's what *Mac* people call pop-up menus. Everyone else calls pop-up menus the menu you get *under the mouse* when you click the menu button on the mouse. > I think the idea of displaying a list of menu titles in a fixed place is > also part of the pull-down menu concept. The user can also move the mouse > over each title in turn to see all the command available. Experienced users > can take advantage of the fact that the menus appear in the same place each > time, and can anticipate where on the screen an item will fall. The user can move the mouse up and down the pop-up menu and in turn see all the commands available. Experienced users can take advantage of the fact that the menus always appear in the same place with resepect to the mouse and can anticipate what quick little move they'll make to reach an item. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
peter@nuchat.UUCP (Peter da Silva) (03/19/88)
In article <7670@apple.Apple.Com>, goldman@Apple.COM (Phil Goldman) writes: > I think one point you are both missing out on is that preemptive multitasking > requires hardware support not available on a 68000. Do you really mean to say this? 1) I can't conceive of a processor that does not permit preemptive multitasking that would still qualify as a computer. A buddy of mine implemented a preemptive multitasker on the Apple-II, as a matter of fact. 2) I'm *using* a computer that does preemptive multitasking on a 68000 with no associated hardware support. I've been using it for a year now and am quite pleased with it. It's a *lot* more responsive than a Mac. Yes, you know the one. 3) At work we have 3 68000-based machines that run multiprocessing (yes, multiple CPUs) UNIX on 68000s. Not 68020s or 68010s. 68000. > As far as which type of multitasking is preferable, I think the answer is, a > combination of both. Even if preemption is available it is still *highly* > desirable to allow the application to notify the OS that it has nothing useful > to do for a given time period. You probably need to spend some time studying the history, theory, and practice of operating system design... or else let someone else speak for Apple. I know that there are some highly competant people there, look what they've managed to do with the Mac design. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
scc@cl.cam.ac.uk (Stephen Crawley) (03/21/88)
In article <1512@devvax.JPL.NASA.GOV> des@jplpro.JPL.NASA.GOV (David Smyth) writes: >stuart@ihlpf.ATT.COM (S. D. Ericson) writes: >>This is an argument I've seen over and over. But I think a lot of people >>don't realize that *Apple* invented Pull-down menus. > >I dunno about this. Xerox certainly does have menus which pop when >you hit a mouse button over an item with several choices. >[...] Anybody actually using XDE, Viewpoint, or the other Xerox >environments care to comment? The Star/Viewpoint product line has pull-down menus that you get by left-click-and-hold'ing over a little doodat in a window's menu bar. There's another doodat on the "herald" bar along the top of the screen. XDE has both pop-up and pull-down menus. You get a pop-up menu stack by choording the 2-button mouse anywhere on the screen. The contents of the stack depends on the window you choord over. Pull-down "hint" menus are used to fill in fields of a form subwindow. You left-click-and-hold over the fieldname, pull down in the menu that appears to select a value. When you release the button, the value stuffed into the form field. There are some neat "hacks" (unsupported programs) in XDE that allow you to provide your own hint menus for a tool that does not provide them. If only Xerox had released XDE (or Mesa as it was originally) as a product 5 or 6 years ago ... -- Steve
sbb@esquire.UUCP (Stephen B. Baumgarten) (03/22/88)
In article <823@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >> As far as which type of multitasking is preferable, I think the answer is, a >> combination of both. Even if preemption is available it is still *highly* >> desirable to allow the application to notify the OS that it has nothing useful >> to do for a given time period. > >You probably need to spend some time studying the history, theory, and practice >of operating system design... or else let someone else speak for Apple. >I know that there are some highly competant people there, look what they've >managed to do with the Mac design. Again, net-readers, the folks using Apple's computers to post are *NOT* posting as official reps of Apple -- that's why they all have such lengthy disclaimers. If they happen to get some of their facts wrong, it's because they don't always know what they're talking about, just like the rest of us... :-) :-) -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." ...!cmcl2!esquire!sbb | - David Letterman
ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre) (03/22/88)
In article <7670@apple.Apple.Com> goldman@apple.UUCP (Phil Goldman) writes: ... >I think one point you are both missing out on is that preemptive multitasking >requires hardware support not available on a 68000. I'm operating under the assumption that preemptive multitasking only requires a regular source of interrupts, which will trigger a 'context switch' (save all registers & other task-specific data someplace 'safe', restore the next tasks registers & globals, then go to the next task). A stock IBM PC can do this, and even an Apple //e or Commodore 64 can. One problem on the Mac is that the globals are 'everywhere'. All Macs that I know of have provisions for a Vertical Blanking interrupt. If you can do your context switch in 1/60th of a second (before the next interrupt comes along), then you're on your way, but I'm glad it's not my job to try to implement it. The ability to do preemptive multitasking is separate from the issue of protection, which helps keep multiple tasks from stepping on each other's address space. This is where you a memory management unit (such as the unit that can be plugged into a Mac ][) to help keep things separate. -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
hugo@eleazar.Dartmouth.EDU (Peter Su) (03/23/88)
In article <7670@apple.Apple.Com> goldman@apple.UUCP (Phil Goldman) writes: >I agree. MultiFinder has made life more difficult (only a little, though) >for application developers in order to make life a great deal easier for >end-users. I think much of the argument depends on what point of view >you take. Adam argues from the programmer's point of view, Larry (and >other Apple people) from the user's. > I think one of the problems I have with Multifinder, nay, the whole Mac pseudo-OS is that it doesn't have to make life so difficult for programmers. A great example of this is in memory management. The kinds of gyrations developers have to go through to make sure they have enough memory around is just disgusting. What's worse, methods for handling memory management at the OS level (e.g. virtual memory) have been around for about 25 years. So, to Apple I say, the user interface is there, but there is no OS under neath it. And someone else said: >>>If you simply judge systems on the basis of multitasking, then MultiFinder >>>would not offer any advantages. Most users, however, don't buy computers >>>based on operating system features. >> See, but they should be aware that if the system they are buying has better OS support for things like networking, tasking, and MM, then applications that they run will almost always be more robust and more numerous. >I think one point you are both missing out on is that preemptive multitasking >requires hardware support not available on a 68000. It is not compatibility Seems to me a few years ago Sun had a little 68000 box with VM and Unix on it... The problem isn't that the 68K can't do it, the problem is that originally Apple made a decision not to put enough support hardware into the Mac to let this happen. They had it in the Lisa, but the took it out mostly for financial reasons, I would guess. >-Phil Goldman >Apple Computer Pete -- CSNET: hugo@darmouth.edu UUCP: hugo@eleazar.UUCP (Sorry) ARPA: hugo%dartmouth.edu@relay.cs.net QUOTE:"Our president's crazy! Did you hear what he said?" - Talking Heads
james@cantuar.UUCP (J. Collier) (03/31/88)
Sender: Followup-To: Mike (My watch has windows) Meyer (mwm@eris.UUCP) writes: >In article <7670@apple.Apple.Com> goldman@apple.UUCP (Phil Goldman) writes: ><I think one point you are both missing out on is that preemptive multitasking ><requires hardware support not available on a 68000. > >Right. So how did Sun, Apollo, Amiga, Sage, Stride and a multitude of >others manage to market 68000 systems that did preemptive >multitasking? [Mike goes on to explain that 68000 instructions can be restarted after most exceptions other than bus & address errors. This hampers the use of paged virtual memory, but *not* pre-emptive multitasking] As Mike says, the problems with pre-emptive multitasking on the Mac can't be blamed on the 68000 architecture. The difficulty is in determining whether process exchange would leave shared OS and Toolbox structures in an inconsistent state. Normally [slightly bold] this is done by ensuring that such inconsistencies can arise only during the execution of a single system call, and by switching the processor from user (unprivileged) to supervisor mode during system calls. The process dispatcher is inhibited when the S-bit is set. Memory protection usually plays a part in this as well, but that's another story. Unfortunately, the Mac Toolbox/OS falls down twice: 1) the processor is *always* in supervisor mode 2) A certain amount of state information which would apply only to particular process is stored globally within the system during the execution of user code. For all this, pre-emptive multitasking on the Mac can be [and has been] done. Part of my MSc thesis involved the implementation of a multi-threaded window server on the Mac, and for reasons of stubbornness I persevered with pre-emptive multitasking. To get around (1), you have to simulate the S-bit in software. You replace the trap dispatcher (very, very carefully) with one which records whether the system is executing in the context of a trap. The standard trap dispatcher jumps directly to the required routine; this version must fiddle the exception address so that the simulated S-bit is cleared before the return to user code. Various tricks are required to ensure that this process is invisible to certain hideous ROM patches which look down the stack to see where they were called from. (Thanks to Scott Knaster for pointing this out). (2) is trickier. The process dispatcher has to test for the appropriate conditions before proceeding, and/or save and restore the various pieces of state information with each context switch. To some extent this is also necessary with non-preemptive multitasking (Multifinder, Switcher), so the solutions are not new. Another difficulty comes from running the process dispatcher off the 60Hz VIA interrupt. The scheduler can be installed as a VBLtask, but in order to protect against possible unbounded stack growth it is necessary to install the dispatcher as the last interrupt task so that it can RTE directly into the new context. Again, this involves replacing the interrupt handler. Admittedly this system was designed to run code files which were linked specifically for the window server, rather than full-blown applications. The server looks after DA support, window management, event preprocessing etc., so its 'sub-applications' don't have so many conflicting requirements. I couldn't believe the reports on Multifinder until I saw it in action; all praise to those responsible. But given that applications can be integrated in this way, I can't see why pre-emptive application multitasking should be considered impossible. Unless Multifinder relies on the application's not calling GetNextEvent() at inopportune moments... Is there something I have missed? Is interactive performance the issue? Or is it just not worth the effort? ><-Phil Goldman ><Apple Computer > > Mike Meyer mwm@berkeley.edu ucbvax!mwm mwm@ucbjade.BITNET ------------------------- James Collier Internet(ish): james@cantuar.uucp Computer Science Dept., UUCP: {watmath,munnari,mcvax}!cantuar!james University of Canterbury, Spearnet/Janet: j.collier@nz.ac.canty (unreliable) Christchurch, New Zealand. Office: +64 3 482 009 x8356 Home: +64 3 554 025
chow@batcomputer.tn.cornell.edu (Christopher Chow) (04/01/88)
In article <270@cantuar.UUCP> james@cantuar.UUCP (J. Collier) writes: > > [...] > Unfortunately, the Mac Toolbox/OS falls down twice: >1) the processor is *always* in supervisor mode One thing I always wanted to know -- why did and why do all Macintoshes running under the Macintosh OS always run in supervisor mode, (especially when Apple guidelines prohibits using certain priveleged instructions such as RTE)? Perhaps the original decision to run in supervisor mode may have to do with the limited amount of RAM avalible on the classic 128k Mac (since the supervisor state has its own stack, ...). But if lack of memory was the only problem then this could have been changed with either the 512k 'fat' Mac or especially the Mac Plus since it had a new set of ROMs anyway. Comments solicited... Christopher Chow /---------------------------------------------------------------------------\ | Internet: chow@tcgould.tn.cornell.edu (128.84.248.35 or 128.84.253.35) | | Usenet: ...{uw-beaver|ihnp4|decvax|vax135}!cornell!batcomputer!chow | | Bitnet: chow@crnlthry.bitnet | | Phone: 1-607-253-6699 Address: 7122 N. Campus 7, Ithaca, NY 14853 | | Delphi: chow2 PAN: chow | \---------------------------------------------------------------------------/