jtn@zodiac.ADS.COM (John Nelson) (12/15/89)
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
rewing@Apple.COM (Richard Ewing) (12/15/89)
Okay, I think we both were speaking a little emotionally the last time. You've calmed down, and I've calmed down. Good... I can se your point about having the Mac based on C cals than Pascal calls. Development in C has really exploded in the last few years. We are kindof left with the original Lisa legacy of Pascal, in which that computer was heavily based. Of course, nothing will stop you from programming in C to Pascal style calls, but it can be syntactically unwiedly. So noted. Of course, many people still program in Pascal... Regarding the user interface issues: Sure we could provide a repository of various different wdef and cdef and mdef resources to customize the Mac for the users' tasts, but do you know what that would do to us as a company? This Mac's hallmark has been a clean consistent user experience. To officially sanction that kind of "designer" user interface would invalidate that very concept. Now I grant you, my mac has lots of those "enhancements" too. But I really dondon't think that you and I are typical users. We will go to whereever to get the INITs we want. The majority (*vast*) will be confused, and wouldn't want to get involved. If we change the Apple Desktop Interface, we'll do it across the board and ONE WAY. Doing it three different ways only confuses the users and the public. Regarding System 7.0 and two megs of RAM. Okay, not every user is going to want to upgrade memory, but memory is cheap today, anand considering your options on the DOS/OS2/UNIX enviroments, its a bargain of flexibility. Hell, even my Apple IIgs has 5 megs of memory and didn't cost that much. Regarding the POSIX complient issues: I fail to see why you have to say that the Mac OS must be POSIX, when POSIX was obviosly biased towards Unix, and the two POSIX platforms you mentioned (Sun and NeXT) are both Unix based. I remind you again that A/UX 1.1.1 is POSIX complient, was one of the first OS's to be so, and is a *full* AT&T Unix that can do all that other AT&T unixs can do, and can even run some Mac apps on the side. Don't think that A/UX is a baby Unix devoid of features. Its got it where it counts, including X-Windows. Incidentally, in most cases you just can't call up your local evangelist and ask for preliminary copies of software. No telling *who* you might be...MacWeek, IBM, Sun, NeXT, or a disgruntled soul with an axe to grind. You'd have better luck contacting your local Apple field sales office and ask a systems engineer if you could be previewed software for whatever legitimate purpose. That way, we can know you, and you know us face to face, and can answer your questions and concerns. We can't show or give you everything (like ystem 7.0 for example), but you'll have better luck locally instead of dealing with corporate. That's our jobs, and not what the evangelists should be doing. When I refer to object-oriented programming, I mean I refer to the programming enviroments that have existed for the last 7 years (Clascal, Rascal, Smalltalk and Mac App, etc...) The NeXT machine took object oriented computing to new heights, but I don't think you'll see Apple "rolling over abd playing dead" on this issue. And as for C++, you *can* buy it today from APDA. Yes, most of it did come from AT&T, but what about standards? :-) We could discuss these things forever, but I'm getting tired and must turn in for some shuteye. I encourage you to keep making suggestions for change, because the users are the best feedback, not those of us who build them. Happy Holidays... -- __________________________________________________________________________ |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 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
lsr@Apple.COM (Larry Rosenstein) (12/15/89)
In article <10088@zodiac.ADS.COM> jtn@zodiac.ADS.COM (John Nelson) writes: > 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 Do you mean instead of one function call with 5 parameters, 5 function calls with 1 parameter? (I think an object-oriented architecture would make this easier, where an object can have a default state, which can be modified when needed.) > 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), Good idea. We did this in MacApp to some extent. > 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 It seems to me that once you put part of your graphics system in hardware it is very difficult to upgrade it. From what I read in comp.sys.amiga, the Amiga has gone through a couple of upgrades of its graphics hardware already. > I note that changes in Quickdraw haven't obsoleted generations of laserprinters But Postscript interpreters are updated occasionally, to add support for color, fix bugs, etc. > 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 The internal Lisa libraries were not object-oriented, but the only programmer's interface releasd outside of Apple was object-oriented (the Lisa Toolkit). The Toolkit was a class library exactly as you desribe. > did, it didn't carry over to the Mac. It sure did in the form of MacApp. > I'm not sure what it is that you are claiming that Apple has > accomplished on this front. I think Apple has been in the forefront of using object-oriented technology for real products. When we were working on the Lisa Toolkit and later MacApp we always took the approach that this was the best way to develop applications. It's only been recently that other companies have started to adopt the same approach. You can trace the origins of ET++, TCL, NeXT AppKit, and Aldus' VAMP (see the OOPSLA '89 proceedings) back to the Lisa Toolkit and MacApp. > performance and sophistication. If the current state of affairs > represents Apple's idea of the highest pinnacle of achievment then I think Apple has already shown (with 32-bit QuickDraw, System 7, Comm Toolbox, etc.) that the Macintosh hasn't reached its full potential, and that will continue. > 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. I have collected lots of ideas and comments from people, and I will continue to do so. (I look forward to using some of these suggestions someday. :-) Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
6600pete@hub.UUCP (12/15/89)
From article <10088@zodiac.ADS.COM>, by jtn@zodiac.ADS.COM (John Nelson): > In article <37167@apple.Apple.COM> rewing@Apple.COM (Richard Ewing) writes: >>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. Nope. Can't do that. Most of the toolbox calls need all their parameters. Examples might help. (GetDItem is one I can think of, but that's the only one so far...) If you're really stuck for simplicity, write your own wrappers and put them in a unit (module). 'T'ain't that tough. > This might make the code more > modular and more than likely easier to read. Macintosh code, in my experience, requires fewer comments, because what's going on is so obvious. > If you've ever programmed in VAX assembly language you know what I mean. Aha! Here we have the problem. The Mac isn't a mainframe! > 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). > ...it would make dealing with the toolbox somewhat easier and make the code > more readable. Perhaps you should turn "require prototypes" on, so you don't have to read for bad parameter types. That's the only reading issue I can think of that affects parameter multiplicity. > 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. But do they do regions like the Mac? > I'm sure that blitters would be useful even when redrawing complex regions. He just told you why this isn't a feasible solution. Why are you still "sure"? > Also I note that changes in Quickdraw haven't obsoleted generations of > laserprinters lately, so the situation should be even better for blitters. Ah, but how could you justify the speed sacrifice in translating QuickDraw to BlitterLanguage(tm)? QD -> PostScript is fine when you're getting hardcopy, but it certainly isn't when you're drawing. >>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? Go get the video before you ask this again. After that, think about what I've said about consistency in the UI. > [ ... unrelated text ] > Don't entice me with visions of the far future and then fail to deliver > small enhanceents tomorrow. What? What is this supposed to mean? Applied to a NeXT enthusiast, this is pretty ironic: HOW long was the release version of the OS vaporware? Sounds like a support deficiency to me... >>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! Perhaps release dates have more to do with marketing than "superiority" of a computer firm or its support. I wouldn't think A/UX customers, with the full array of Mac windowing available to them, would clamor as loudly for X as would NeXT customers, who probably see the possibility of disaster with the possibility of an orphan windowing system. (To be fair, note the two uses of "possibility" -- they're deliberate.) > If I want Posix compliency I'll switch over to Sun Microsystems or even > NeXT, not A/UX! Why do that when you already own Mac hardware? > The Lisa programming interface was object oriented? I may be wrong but I > don't think the Lisa implemented ANYTHING resembling this paradigm. You're wrong. > Even if it did, it didn't carry over to the Mac. What do you think Object Pascal is? Chopped liver? > 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. You're right, you're the little guy. You didn't get advance copies of the software because big mean Apple had no idea who you were. In sympathy, I'll break my non-disclosure agreement and send you some beta software I'm testing. Where should I mail it? If you're interested in bitching about support, I'll join you, as I have said elsewhere. But this is not a defense of the position that the Mac does not have enough object orientation in its developement environments. It does. > C++ from Apple is really an implementation of Cfront from AT&T. So? That makes it inferior? It exists. >>First, Inside Mac is being revamped... > HALLELUJAH! Me too. > I just hope that you guys can achieve more than "just fonts in different > sizes." Alas, the Layout Manager isn't going to be in System 7.0. It's there, though. > But it would make sense to be compatible with OTHER people's laserwriters, > computers, displays, printers, ad nauseum. Nope. That's not Apple's market strategy, Candide. > 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... Here's that attempt to say "It's just my opinion" again... > If the current state of affairs represents Apple's idea of the highest > pinnacle of achievment... I think it's pretty clear that in the world today the Mac IS the highest pinnacle of achievement. In no other market is there such a duplicity of software for such a wonderful and consistent user interface. However, I assure you Apple is not sitting around letting the market over-take it. In that sense, you ain't seen nothin' yet. ------------------------------------------------------------------------------- Pete Gontier | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa Editor, Macker | Online Macintosh Programming Journal; mail for subscription Hire this kid | Mac, DOS, C, Pascal, asm, excellent communication skills