Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think!ames!zodiac!jtn From: jtn@zodiac.ADS.COM (John Nelson) Newsgroups: comp.sys.mac Subject: The Mac of the 90's.... Message-ID: <10088@zodiac.ADS.COM> Date: 14 Dec 89 21:43:27 GMT References: <9986@zodiac.ADS.COM> <37167@apple.Apple.COM> Reply-To: jtn@ads.com (John Nelson) Organization: Advanced Decision Systems, Mt. View, CA (415) 960-7300 Lines: 159 In article <37167@apple.Apple.COM> rewing@Apple.COM (Richard Ewing) writes: >Gee, I always thought that the Mac OS *was* based on Pascal calls. Right. I meant "rewrite in C" and support the ANSI C calling sequence. Pascal calls could also be supported if backward compatability is desired. >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. Let me put it this way... Instead of passing 5 parameters into a toolbox call, define 5 different entry points to the function (5 different toolbox calls) to accomplish the same thing. This might make the code more modular and more than likely easier to read. If you've ever programmed in VAX assembly language you know what I mean. Also I'd like to see some kind of .h file that defined symbols for use with these functions. So instead of saying ToolBoxCall(-1, "\p", 0L, myFunc), I would say ToolBoxCall(ALL_LISTS, NO_TITLE, NO_FILTER, &myFunc). These may sound like trivial suggestions (maybe they are) but it would make dealing with the toolbox somewhat easier and make the code more readable. >*still* don't know where this hogwash got started about System 7.0 only >supporting the 68030. It's because stupid people like me equate system 7.0 and virtual memory as one functional entity. Okay... 7.0 will work across all platforms which is GREAT GREAT GREAT except that to get it to run on a MacPlus you have to upgrade to 2 meg MINIMUM. Booo. >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. This sounds like a reasonable argument, however you will note that the Amiga and Atari machines make good use of blitter hardware. I'm sure that blitters would be useful even when redrawing complex regions. Also I note that changes in Quickdraw haven't obsoleted generations of laserprinters lately, so the situation should be even better for blitters. >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.... But when will things like this be officially shipped with the system or supported by Apple? It would be insanely great (to coin a phrase) if Apple made libraries of DEFs or resources available that we could add to extend the interface and OS even if I had to send away to Apple for such things at a nominal charge! Yeah I know... join APDA. Except APDA's stuff is mighty expensive and geared towards the needs of developers. Don't entice me with visions of the far future and then fail to deliver small enhanceents tomorrow. >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. I haven't been able to obtain a copy of MacX. I wrote to Apple's X evangelist requesting an advanced copy for evaluation by my company. We received neither a letter nor phone call in return. >And if memory serves me correct, the NeXt machine doesn't even support >X-Windows. Hmmmm..... It will early NeXT year. I hear an initial distribution will be available in Janurary. Pretty quick response since the machine was first released! >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. What you're saying is, if the Mac OS doesn't do it than I should switch to another OS. Fine... but if I want Posix compliency I'll switch over to Sun Microsystems or even NeXT, not A/UX! I'm suggesting that BOTH products be complient and compatible with commonly accepted standards. These are reasonable desires for the future if not attainable today. >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. The Lisa programming interface was object oriented? Object oriented programming in the traditional sense includes class definitions, the construction of class libraries and methods to implement responses to messages passed between objects. I may be wrong but I don't think the Lisa implemented ANYTHING resembling this paradigm. Even if it did, it didn't carry over to the Mac. >C++ is now available from APDA. I also wrote to your C++ evangelist about obtaining an advanced copy of C++ for evaluation by my company and I received nothing in return. >OOP is nothing new to Apple; please recognize what we've accomplished. I'm not sure what it is that you are claiming that Apple has accomplished on this front. C++ from Apple is really an implementation of Cfront from AT&T. >First, Inside Mac is being revamped... HALLELUJAH! >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. From what I've seen of Royal, the new Apple font technology, it DOES look promising. I just hope that you guys can achieve more than "just fonts in different sizes." Remember also that Postscript is more than just fonts. Yeah I'm looking forward to fonts that I don't have to buy at $198 a pop. I'm also looking forward to an integrated graphics and font definition like Postscript. >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. But it would make sense to be compatible with OTHER people's laserwriters, computers, displays, printers, ad nauseum. >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. Careful... I clearly stated that these were DESIRES for the future Mac OS. Not complaints. Not Flames. As such they may be off base or even short-sighted, however on the whole I think I've addressed some valid areas of improvment for Apple and the Mac. I want to see the Mac evolved to it's highest state of capability, performance and sophistication. If the current state of affairs represents Apple's idea of the highest pinnacle of achievment then maybe Steve Jobs is correct in stating that the Mac is at the end of it's life expectancy and we should all run out and buy NeXTs. On the other hand, if Apple wishes to remain competative and deliver a quality product they should spare no expense at listening to their customers and improving their existing products and SUPPORT. I think this can be done and I've mentioned only a few possible improvements they could make. -- John T. Nelson UUCP: sun!sundc!potomac!jtn Advanced Decision Systems Internet: jtn@potomac.ads.com 1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611