Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!usc!apple!rewing From: rewing@Apple.COM (Richard Ewing) Newsgroups: comp.sys.mac Subject: Re: What do I want to see in the Apple of the 90's? Message-ID: <37167@apple.Apple.COM> Date: 10 Dec 89 02:59:32 GMT References: <9986@zodiac.ADS.COM> Organization: Apple Computer Inc, Cupertino, CA Lines: 180 I'll answer your concerns about where Apple is taking the operating system in the 90's, but judging from some of your comments, it's apparent you having been listening to many of the things that Apple has been talking about for the last year. #1: >What does THIS user want to see in a new Macintosh operating system? > > o Rewrite in Pascal and make software calling sequence ANSII C > complient. CtoPstr and PtoCstr is a boatload of nonesense. > Of course this will break all kinds of code out there, but then > Apple plans to continue support of OS 6 right? Gee, I always thought that the Mac OS *was* based on Pascal calls. And you haven't given me any good reason as to why we should make Toolbox calls ANSI C complient. Just for the sake of porting existing applications? Any Mac programmer worth his salt will tell you that porting a stock program doth not a Mac application make. You complaint here is very confusing. #2: > o Simplify calls to the toolbox. I hate having to call functions > with a bazillion arguments. I also dislike sending in "mystery" > parameters like "0L", -1 and so forth. So what if the ROMS and > system get a little larger. System 7.0 will run only on 68030 > boxes anyway. You have plenty of room to spread out. Simplify calls to the toolbox. Okay, programming the toolbox box has never been a cake walk, and this is a legitimate concern. However, I don't think any parameters are "mystery"; all have a purpose. And I *still* don't know where this hogwash got started about System 7.0 only supporting the 68030. System 7.0 will run on all Macs we make today, as well as the future. That includes the Mac Plus, SE, and original Mac II. What these machines can't do under System 7.0 is run virtual memory. The Mac II can be upgraded with a PMMU chip to do virtual memory. But otherwise these Macs can do IPC, outline fonts, new printing, layout manager, new Finder, and all the other goodies that we rolled out to the developers. *All* Macs can do this. 'Nuff said. #3 > o Speed up the interface. I can't stand having to wait for all of > those windows to redraw themselves. If necessary, install hardware > blitter hardware to do a lot of the work for you. When the Mac > was a small inexpensive box, then it was correct to do lots of > stuff in software. Now that Mac CPUs cost upwards of $3,000-$4,000, > Apple can afford a little specialized hardware. One of the problems with hardware blitters is that most graphics coprocessors can't handle the complex regions that Macs have to draw. Now that's not to saw that graphic blitters are impossible; a few are available right now, but most are not cheap enough to put in all Macs. The engineers in Cupertino have explored numerous technologies to make the Mac what is is today, and we do not ignore technolgies. But the engineers believe that the way they've implemented drawing is right. Also, as shown in the past, Quickdraw is always subject to change, and therefore may obsolete a hardware based solution. #4 > o Update the interface. Let's face it... the Mac interface was > inovative 5 years ago, but compared to Motif on X windows or the > NeXT computer interface, its a dog. This is actually a very complex > issue: > > The look and feel of Macintosh windows is very sparten. I would like > to see an interfacethat looks more elegant even if it is no more > functional. Consider the Motif interface in X Windows... very nice > textured panels with 3-D buttons and shadowing. Beautiful. Now look > at Mac windows and dialog boxes... a couple of lines and the samey old > radio buttons and click buttons. Boring. > > To rid ourselves of this sameyness, there should be a tool on the Mac > very similar to the NeXT computer's interface builder. Such a tool > would let you prototype windows and dialog boxes but froma larger > pallette of "panels" and textures. Various buttons and effects > (shadowing, highlighting, blinking) should be available. Different > types of window panes, controls and menuing paradigms should be > available. This hypothetical tool would allow the user to prototype > windows by draggin each item from a menu and simply placing them on > the window. The tool might then generate a framework of code which > the user can fill in later. It should also be possible for the user > to create his/her own controls and plug them into the library of > things attachable to a window or box. > > All of these items should be sharable by users without clobbering each > other's applications too! Contrary to popular opinion, all the things you see in the Mac inferface are not hardwired down to the ROMs. They are al resources that can be changed by modifying the right WDEF, CDEF, or other resource. In fact, some people have already done so in their programs. Others have written INITs to do the same thing. If you doubt that Apple can make changes in the interface for the better, ask your local Apple rep to show you the video tape and literature about our OASIS concept. Or the Knowledge Navigator video. Our technology people are that stupid to rest on past laurels. Interface prototypers for the Mac already exist, although not as flexible as the NeXT Interface builder. but they do exist. #5 > o Stress a greater tie-in with colour. The Mac OS grew up in the days > when the Mac was available only in B&W monochrome. There should be > greater support in Resedit and the Finders for colour. The hardware > is there... but the Finders just don't use it! Please read the section in Inside Mac 4 and the Human Inferface guidelines book on color and its use in the Mac interface. #6 > o It should be possible to run an X Windows based MultiFinder with true > multitasking. X Windows is there.... why ignore it! Integrate the > thing right into the MultiFinder and polish up the interface (although > it would probably run a little slow). MacX isn't a total solution. I don't even want to begin to comment on how ridiculously complex that would be to implement. But I will say that since the Mac OS isn't a UNIX based system, I really don't think that it would make a really good UNIX client host. And as for Mac X..have you used it? Since its not released yet, I'd say no, and from what I've seen of it, I like what it can do. it provides X-Windows server services to any Mac with 2 megs of memory. And I've tried it with A/UX, DECWindows, and an IBM RT. Don't count your chickens before they hatch. And if memory serves me correct, the NeXt machine doesn't even support X-Windows. Hmmmm..... #7 > o Make the OS more Posix call-complient. Functions like FSGetFile are > a good thing but there should also be ANSI conformant Unix "open" > "read" "write" calls. The Unix OS interface is simplicity in itself. > Don't ignore the tide of support for Unix and OS STANDARDS. The OS > looks like it came out of a 128K machine from the mid 1980's. Wonder > why? The Mac OS may not be POSIX complient, but A/UX sure is. Check it out. And you can even do Mac stuff in the process. And "make sure the OS supports object orientation"??? Where have you been for the past 7 years??? What do you think that the Lisa pioneered in microcomputers??? Object oriented inferface concepts and programming have existed since the old Clascal days. C++ is now available from APDA. OOP is nothing new to Apple; please recognize what we've accomplished. I'll just close this already too long response by responding to your last three complaints. First, Inside Mac is being revamped, and Gary Little of Apple has already has conferences on the major bboards looking for input from the masses. Second, the Apple warrenty. I won't respond to this outside of that Apple always reviews its policies on a variety of issues at various intervals. Third, scalable fonts are coming, and their the best in the business. And the reason that we didn't xchoose Postscript fonts was for speed and flexibility. Our fonts will print to anything, Imagewriters, laserwriters, film recorders, plotters, etc. Even Microsoft liked them enough to liscense them from us. And I think that a fear of "not compatible with Postscript" is completely unjustified. It really doesn't make sense for us to introduce a technology that's functionally incompatible with all our Postscript laserwriters, or any other printer for that matter. Look, I don't mean for any of this to be considered personal or heavy handed, but I always cringe when I read something here that i consider inaccurate or short sided. Some of your complaints were well stated, and should be addressed. But make sure that you have all the facts and understand the technical complexities of the problem before you flame. Thank you. And as always, these comments don't come from my employer. -- __________________________________________________________________________ |Disclaimer: Segmentation Fault: Core Dumped. | | | |Internet: REWING@APPLE.COM-----------------------Rick Ewing | |ApplelinkPE & MacNet Soon!------------------Apple Computer, Inc. | |Applelink: EWING--------------------100 Ashford Center North, Suite 100 | |Compu$erve: [76474,1732]--------------------Atlanta, GA 30338 | |GENIE: R.EWING1--------------------------TalkNet: (404) 393-9358 | |USENET: {amdahl,decwrl,sun,unisoft}!apple!rewing | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^