shebanow@apple.com (Andrew Shebanow) (04/12/89)
In article <3637@brunix.UUCP> omh@brunix (Owen M. Hartnett) writes: > Apple DTS always seems to have the attitude that it knows best what > developers should know about (or rather, not know about). There may be > developers out there with legitimate need to know - to fix bugs, to implement > a novel feature, or for reasons yet unknown. > > If the information is available, and properly documented that there > should be no reasons for using it (that we are currently aware of), then > the programmer will know he has to take the responsibility for using it. > > True, some developers will misuse it, but then it's their problem. Apple > should endeavor to make as much information available as possible, and let > us developers write some "insanely great" applications with it. Unfortunately, it isn't just the developer's problem. If a developer writes and sells a buggy application, and that application breaks when a future version of the system software gets released, it hurts all of the programs users, who are Apple customers, and it hurts Apple as well, since many of those customers will blame Apple and not the developer (I am speaking from past experience here). DTS is in a position to influence this problem, by informing developers of the consequences when they want to do something dangerous, and by withholding information when that information would be abused if it was publicly documented. This policy is not written in stone: this whole discussion was brought about by a survey question from a DTS engineer. If someone can convince us that there are COMPELLING reasons to publish this information, we will do so, either privately or publicly. So far though, I haven't seen any reasons posted that justify the compatibility dangers. If this constitutes "arrogance" on our part, then I apologize for all of us. However, we feel that it is our duty (wow, pretty heavy there dude) to try and keep developers on the straight and narrow path to compatibility. Andrew Shebanow DTS Compatibility Ninja - All Opinions Are Mine, and Mine Alone -
omh@brunix (Owen M. Hartnett) (04/13/89)
In article <1304@internal.Apple.COM> shebanow@apple.com (Andrew Shebanow) writes: >In article <3637@brunix.UUCP> omh@brunix (Owen M. Hartnett) writes: > [My comments that DTS should publish "dangerous information."] >Unfortunately, it isn't just the developer's problem. If a developer >writes and sells a buggy application, and that application breaks when a >future version of the system software gets released, it hurts all of the >programs users, who are Apple customers, and it hurts Apple as well, since >many of those customers will blame Apple and not the developer (I am >speaking from past experience here). > >DTS is in a position to influence this problem, by informing developers of >the consequences when they want to do something dangerous, and by >withholding information when that information would be abused if it was >publicly documented. This policy is not written in stone: this whole >discussion was brought about by a survey question from a DTS engineer. If >someone can convince us that there are COMPELLING reasons to publish this >information, we will do so, either privately or publicly. So far though, I >haven't seen any reasons posted that justify the compatibility dangers. > >If this constitutes "arrogance" on our part, then I apologize for all of >us. However, we feel that it is our duty (wow, pretty heavy there dude) to >try and keep developers on the straight and narrow path to compatibility. I think there's a greater danger in keeping quiet. Look, who's is Apple afraid of most that will mis-use the guidelines? Obviously, the big software vendors who are precisely the people who ignore them the most. (Look at all the kludges that not only Apple, but other vendors too had to put in their code to handle Excel's flakiness.) Maybe I'm wrong, but if you put up a standard, particularly on an issue as clear cut as this: (0=computer running finder, 1=computer running multi-finder, 2=computer running a/ux, 3 = computer running ???), you will nip a lot of compatibility problems in the bud. Basically what I'm saying is that people will do it anyway, so why not legalize it? If you look through Inside Mac, it's rife with areas where the same problems exist. Even the newest technote (which has become a joke quoted at almost every user group meeting I've been to lately) admonishes us against using *documented* information. So what's a developer to do? Owen Hartnett Brown University Computer Science omh@cs.brown.edu.CSNET
keith@Apple.COM (Keith Rollin) (04/13/89)
In article <3918@brunix.UUCP> omh@zaphod.UUCP (Owen M. Hartnett) writes: > >Maybe I'm wrong, but if you put up a standard, particularly on an issue >as clear cut as this: (0=computer running finder, 1=computer running >multi-finder, 2=computer running a/ux, 3 = computer running ???), you >will nip a lot of compatibility problems in the bud. There are problems with scheme. What if item 3 becomes defined some day. Suppose that Apple comes out with Zowie-Finder that offers some or all of the features of MultiFinder, in addition to some new ones. How does a program take advantage of these features? Any program that checks to see if the field holds a 1 will not realize that it can also run under 3. Neither can you assume that every system that returns a number greater than 1 will have all of the features of 1. The answer is to do what we've been saying all along; test for the features you need. Then, if we come out with Zowie-Finder you will automatically take advantage of the common features in it. >Basically what I'm saying is that people will do it anyway, so why not >legalize it? Because we are trying to get people to NOT do it so that their programs will work well in the future. By legalizing it, we will have to support it in the future, which will limit us in the ways that we can expand the system. If you check for the presence of MultiFinder, it may not be possible for us to come out with Zowie-Finder. ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
pepke@loligo.cc.fsu.edu (Eric Pepke) (04/13/89)
So asking whether MultiFinder is active or not is the Wrong Question, and Apple will never let us know. Here is a Real Question. I have an application which needs to launch other applications. I need to be able to find out the answer to these questions about Launch before I call it: 1) When I call Launch, will it return immediately and launch the application at a later time, or will it wait until the user quits the subapplication before returning? 2) If the former, will my calling program still have windows at which the user can look before quitting the subapplication? Will it still be able to do stuff that affects these windows from time to time? I don't care what version of the system I am running. I don't care whether the machine has a 68000, 68020, 68030, 68040, or a MIPS processor running an emulator. I don't care whether it is running Finder, Switcher, MultiFinder, A/UX, or Dr. Tongue's 3-D House of Windows. Honest. You could even be running OS-9 or Magic Pustule or whatever it's called without peeving me in the slightest. The only reason I occasionally screw up and ask about MultuFinder is that at least three Mac Tech Notes and the MultiFinder Development package say that how Launch behaves is related to the presence of MultiFinder. Personally, I don't care a whit, tittle, or jot. Not a sausage. Nada. Nichts. It is cold comfort to me that the Notes say that most applications shouldn't need to worry about this. I am not writing most applications; I am writing this one. And yes--it *is* an integrated development system, so I am entitled to consider using Launch. So, what is the answer to this question which has absolutely nothing to do with MultiFinder in any way whatsoever? Eric Pepke ARPA: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: pepke@scri Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
kent@lloyd.camex.uucp (Kent Borg) (04/13/89)
In article <28878@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >The answer is to do what we've been saying all along; test for the features >you need. Then, if we come out with Zowie-Finder you will automatically take >advantage of the common features in it. Take a *hint* guys! Apple is working on Zowie-Finder and lots of the stuff we are doing will break under Zowie-Finder. DTS knows details about Zowie-Finder and can try to steer us in the right direction--and checking for all those interesting MultiFinder features by checking for MultiFinder isn't the right direction. Put that together with talk about when Apple might give us all the preemptive multitasking, protected memory stuff we complain about not having? What have you got? MultiFinder might change *drastically*, it might do it in System 7.0, it might do it soon. In fact the identical version number might act rather differently at different times--say, when on a 68000 vs. a 68030 machine. So checking for the program version will trick us in all kinds of ways. But do we *have* ways for checking for features rather than for MultiFinder? No, so we gripe. Maybe we should start carefully listing what we want to know? 7.0 might have all its features in place right now, but they could probably still easily add some feature *reporting* before they freeze the code. Let's do our best to help them understand what we need to know about MultiFinder and they might discover something crucial they hadn't though of and just manage to slip it onto the end of SysEnvRec. How about our annoyance at Bill Atkinson's breaking of all the rules? Well, it's just possible that DTS is annoyed *too*, but Bill is a powerful guy. Don't expect DTS to bitch about him publicly. They all have fancy car and house payments to worry about. So, what do we want to know? Whether we are covering up icons on the desktop (whether we can add our own icons--I think Apple should share that resource), whether there are background tasks, whether we might become backgrounded, whether we are in user mode, whether we are/might-be set-aside/shrunk-into-an-icon... Let's make a list. Kent Borg kent@lloyd.uucp or ...!hscfvax!lloyd!kent
jackiw@cs.swarthmore.edu (Nick Jackiw) (04/14/89)
In article <28878@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: > In article <3918@brunix.UUCP> omh@zaphod.UUCP (Owen M. Hartnett) writes: > > > >Maybe I'm wrong, but if you put up a standard, particularly on an issue > >as clear cut as this: (0=computer running finder, 1=computer running > >multi-finder, 2=computer running a/ux, 3 = computer running ???), you > >will nip a lot of compatibility problems in the bud. > > There are problems with scheme. What if item 3 becomes defined some day. > [FLAME ON!] Nonsense. This is the SysEnvirons scheme. I know we're flogging a dead horse here, but the High Priests of Multifinder Secrecy have got to realize that their "function not features" argument is flawed. I don't ask "can you draw a line for me in this color?" (a function), I ask "do you have Color Quickdraw?" (a feature). Asking for functions before using them is an infinitely-expandable syllogism, as some recent post seemed close to alluding to. (The classic meta-situation: Before you ask, "Can you do this?" you've got to ask, "If I ask you if you can do this, can you tell me the answer?" All cretans are liars.) [FLAME DIVERTED TO LIGHT A HASTILY DRAWN CIGARETTE -- No sense in letting this good flame go to waste -- ] Come on apple... If you've got some Secret Imperative ("Immovable Rigour," Caligula called it), at least drop your current argument or revise the Mac to uphold it. Classic example: I write a game. Using four-voice sound, it sounds great, but busts the butt off a 68000 (50% proc time for music pre-sound chip, recall). If I run it under Multifinder, my virtuoso performance croaks like a frog. Ideally, I could implement a second rendition of that vital theme music, performed on the square-wave generator (2% load). I look in the technotes and lo! TECHNOTE #342 ------------- Author: XXXXXXXX [Classified] This tech note describes the IsLikelyToCroakLikeAFrog:BOOLEAN function, implemented in System X.02b1k4 [X=Confidential; If you have NeedToKnow, contact MacDTS; b=beta; k=kludge]. "Just what I needed." ------------------------------------ Really, sorry to be so strident about this, but it really seems like this is an issue over which MacDTS and Certain Usenet Readers (myself included) are never going to agree, regardless of what sort of evidence each provides for their righteous views. [YEOW!!! FLAME BURNED DOWN TO MY FINGER TIPS; SPUTTERING OUT...] > ------------------------------------------------------------------------------ > Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support Admiring anyone who believes what they say and is willing to argue over it, I'm -- _ _|\____ Nick Jackiw | Visual Geometry Project | Math Department / /_/ O> \ ------------+-------------------------+ Swarthmore College | O> | 215-328-8225| jackiw@cs.swarthmore.edu| Swarthmore PA 19081 \_Guernica_/ ------------+-------------------------+ USA
mjohnson@Apple.COM (Mark B. Johnson) (04/14/89)
In article <378@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: >How about our annoyance at Bill Atkinson's breaking of all the rules? >Well, it's just possible that DTS is annoyed *too*, but Bill is a >powerful guy. Don't expect DTS to bitch about him publicly. They all >have fancy car and house payments to worry about. > Whoa. Don't we wish. Try beat up car and rent payments for most of us. You don't get to the fancy car and house payments until you can break the rules and get away with it... :-) Mark B. Johnson AppleLink: mjohnson Developer Technical Support domain: mjohnson@Apple.com Apple Computer, Inc. UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson "You gave your life to become the person you are right now. Was it worth it?" - Richard Bach, _One_
omh@brunix (Owen M. Hartnett) (04/15/89)
If you read MacWeek's Mac The Knife, he claims that System 7.0 will be announced at Apple's (pay us $900 and we'll tell you why you should program the Mac) Developer's conference. Although MTK's column is usually merely corroborative evidence intending to give verisimilitude to an otherwise bald and unconvincing narrative, (you can't believe how much fun it is to type in Poo-Bah's line!) he spouts that System 7.0 will have "a new font outline technology to put Quickdraw on parity with PostScript," also virtual memory, IPC, a new printer driver architecture and dragging of fonts and resources just like Servant did. He claims that a ROM upgrade is in order (you knew this would happen! Can you say "ROM simms?") This makes sense to me, although not all may be true, probably most of it is. Apple announced the MacPlus at the last Dev Conf I went to (1986, only $300, I think. What a bargain!) and is probably planning to do this. Owen Hartnett Brown University Computer Science omh@cs.brown.edu.CSNET
kazim@Apple.COM (Alex Kazim) (04/16/89)
In article <28942@apple.Apple.COM> mjohnson@Apple.COM (Mark B. Johnson) writes: > >Whoa. Don't we wish. Try beat up car and rent payments for most of us. ^^^^^^^^^^^> >Mark B. Johnson AppleLink: mjohnson >Developer Technical Support domain: mjohnson@Apple.com >Apple Computer, Inc. UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson > Well, Mark, I wouldn't exactly call your car beat up.:-) Actually, I have to agree with a lot of the netters: There are a lot of Apple programs out there that don't strictly follow the guidelines. (one of the worse is selection vs list manager). Bill A. takes a lot of liberties with the interface because he can. A lot of the work he does is ground-breaking, where no-man has gone before, etc. If he comes up with a "new" way to do things, and it's his project, then it really is his call. If you've got a new way of doing something, then use it. But if ONE person is confused, becuase it doesn't work the way it should, then you've failed. A lot of people have wondered why Apple is slow to accept stuff like pop-up or tear-off menus, or other items that extend the interface, and the answer is we're not. All extensions go thru a LOT of user-testing. Things that might seem trivial to you, may confuse the heck out of someone else. I think we learned that lesson with the "Pandora's Box" user testing of putting together a Mac II. Also, think about international users. A picture of push-button phone may seem perfectly reasonable, but the user in Inssbruk, Austria, would probably wonder why there isn't a dial on it. So, by all means come up with new ideas, but spend time on it. Think about how my mother would use it, whether it would confuse her. ==================================================================== Alex Kazim, Apple Computer This soapbox is mine, not Apple's. So are the opinions. "Chaos is Great" -- Michael Keaton ====================================================================
lsr@Apple.COM (Larry Rosenstein) (04/20/89)
In article <3918@brunix.UUCP> omh@brunix (Owen M. Hartnett) writes: > Maybe I'm wrong, but if you put up a standard, particularly on an issue > as clear cut as this: (0=computer running finder, 1=computer running > multi-finder, 2=computer running a/ux, 3 = computer running ???), you > will nip a lot of compatibility problems in the bud. I'm not so sure. We have a similar mechanism in SysEnvirons to determine what CPU you are running on (68000, 68020, 68030, ...) and what model (Mac II, Mac IIx, etc.). So what happens? Some applications check for color capability by seeing if they are running on a 68020 or on a Mac II, even though SysEnvirons tell you if Color Quickdraw is available. Said applications don't run on a Mac IIx. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
ra_robert@gsbacd.uchicago.edu (04/21/89)
In article <381@lloyd.camex.uucp>, kent@lloyd.camex.uucp (Kent Borg) writes... >*My* mother just started using a new Mac Plus. She had a terrible >time getting the thing to print. She found mention of clicking on the >ImageWriter icon, so she did that. It wouldn't print. She looked in >the MindWrite manual. It wouldn't print. She looked in the >ImageWriter manual (couple years old). It wouldn't print. Finally >she looked in the Mac manual and discovered the Chooser. It worked >perfectly. Sure, compared with the trials of hooking a printer up to [...] Apple should make the user interface more intuitive by using icons for printing and other tasks. For instance, I think a much better method of printing would be to drag a document to a printer icon, much as one throws something out by dragging it to the trash. ( I think that New Wave (remember that? :->) does this.) Robert Anthony ------ ra_robert@gsbacd.uchicago.edu ------ generic disclaimer: all my opinions are mine
day@grand.UUCP (Dave Yost) (04/22/89)
In article <381@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: >*My* mother just started using a new Mac Plus. She had a terrible >time getting the thing to print. ... >She looked in the MindWrite manual. >She looked in the ImageWriter manual (couple years old). >Finally she looked in the Mac manual and discovered the Chooser. > >Conclusion: Things are plenty complicated already. Be very careful >about incremental changes which help a local problem but might break >the larger interface. User interfaces are complicated things. > >Kent Borg Which leads into one of my favorite soapbox derbies: True, but another way to look at this case history is that she couldn't find the answer to her question quickly enough in the manuals. The solution is for manuals to provide a fanatically complete and annotated index. That is, an index whose mission is to field *any* question you might have that is answered in the book. Most indeces are about 1/4 what they should be, I believe. The model we should all emulate is the index in Bartlett's Familiar Quotations. Every quotation is indexed by every key word or thought in it, and you are never given just a raw page number; you always get some context with it so you can tell if the page number has what you are looking for. --dave yost
ech@pegasus.ATT.COM (Edward C Horvath) (04/22/89)
From article <2821@tank.uchicago.edu>, by ra_robert@gsbacd.uchicago.edu: > ...For instance, I think a much better method of printing would > be to drag a document to a printer icon, much as one throws something out by > dragging it to the trash... And indeed, double-clicking the self-same icon could bring up (the printer- subset of) the Chooser. This is so intuitive that I "remember" that the first 128K Mac I saw did things this way. Of course I was hallucinating, but I SHOULD have been right... =Ned Horvath=
casseres@apple.com (David Casseres) (04/25/89)
In article <489@grand.UUCP> day@grand.UUCP (Dave Yost) writes: > The solution is for > manuals to provide a fanatically complete and annotated > index. That is, an index whose mission is to field *any* > question you might have that is answered in the book. > Most indeces are about 1/4 what they should be, I > believe. How very true. This is an area where computers have been misused by people who run dopey "indexing" programs instead of expending the considerable effort required to produce a real index. I have watched the quality of indexes in computer documentation go to hell in a handbasket over the last few years. David Casseres Exclaimer: Wow!
du4@mace.cc.purdue.edu (Ted Goldstein) (04/25/89)
In article <2821@tank.uchicago.edu> ra_robert@gsbacd.uchicago.edu writes: >In article <381@lloyd.camex.uucp>, kent@lloyd.camex.uucp (Kent Borg) writes... > >>*My* mother just started using a new Mac Plus. She had a terrible >>time getting the thing to print. She found mention of clicking on the >>ImageWriter icon, so she did that. It wouldn't print. She looked in >>the MindWrite manual. It wouldn't print. She looked in the >>ImageWriter manual (couple years old). It wouldn't print. Finally >>she looked in the Mac manual and discovered the Chooser. It worked >>perfectly. Sure, compared with the trials of hooking a printer up to >[...] > I remember helping students complete their first Mac assignment back when we had only 2 public macs. They were following instructions to print and had found the cooser, acs in our school. They laserwriter appeared in the box. There was only one name on the list, they thought they were done and tried to print without success. Well after much confusion, now we all know you need to click on the name to highlight it, even if it is the only choice available. Again, not very intuitive... Ted Goldstein du4@mace.cc.purdue.edu
omh@brunix (Owen M. Hartnett) (05/06/89)
In article <1460@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >In article <3918@brunix.UUCP> omh@brunix (Owen M. Hartnett) writes: >> Maybe I'm wrong, but if you put up a standard, particularly on an issue >> as clear cut as this: (0=computer running finder, 1=computer running >> multi-finder, 2=computer running a/ux, 3 = computer running ???), you >> will nip a lot of compatibility problems in the bud. > >I'm not so sure. We have a similar mechanism in SysEnvirons to >determine what CPU you are running on (68000, 68020, 68030, ...) and what >model (Mac II, Mac IIx, etc.). So what happens? Some applications check >for color capability by seeing if they are running on a 68020 or on a Mac >II, even though SysEnvirons tell you if Color Quickdraw is available. Bad programmers who ignore obvious warnings like those in SysEnvirons are going to write poor code, no matter what information Apple withholds. The Real question is: At what point does useful information become "bad," that is where knowledge by the programmer community is at direct odds with the goals of Apple Development. It is a noble goal that Apple DTS wants every application written to run transparently under Multi and Unifinder, but what about the developer who wants his application to run *only* under Multifinder? He encounters a set of deliberate hurdles. My premise is that this is counter productive - developers should be given a way to write exceptional applications. When you think about it, the Mac is the only machine where the application has no idea of what Operating System is underneath it. -Owen Owen Hartnett Brown University Computer Science omh@cs.brown.edu.CSNET