tim@hoptoad.uucp (Tim Maroney) (11/28/89)
I don't really want to continue this, but after several days of sitting on my hands, I think there are a few points in Whiplash's message that shouldn't go without comment. In article <5352@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: >I'd be more than happy to continue the >discussion, although I believe it will be much easier when System 7 final >ships, since at that point the details of the Alias Manager, et al. will >be much clearler. In other words, we don't care what comments you might have on the merits of this new feature. It's going in the new system anyway and it will be just the way it always was going to be; just keep your suggestions to yourself and let us tell you how things are. It's obvious that at no time do the Apple representatives consider the dialogue with the developer community to be two-way. Any criticism or complaint that may be raised is there to be waved aside, not to be taken into account as a possible influence on future software directions. Tim: >and people are coming >to ignore your conclusions even in the very rare cases where you >sincerely try to prove them correct. Paul: >For whom exactly are you speaking? So far, you're the only one making >these claims. False. I've received an e-mail message from a person who mentioned making exactly the same complaints about you here, with the same level of non-response. And as I already pointed out, a number of people have commented here on the failure of your messages to adequately address issues like exactly why tail patches are wrong, the non-run-time nature of library code, and the binding nature of instructions in Inside Macintosh, as well as my points on problems with file ids. I guess you've blocked these people's messages from your mind; inconvenient, aren't they? That people are coming to ignore your positions is obvious; it is, in fact, explicitly what you've been bitching about. Well, Paul, there's a reason for it -- you almost never bother to back up what you say. If you don't have a technical argument to add, then you should avoid contributing pointless flames. Paul: >Perhaps I'm like an army drill sargeant or something: I'm harsh, I'm >stern, I'm a pain in the ass, but it's all to benefit the person being >disciplined. Tim: >Gee, Daddy, thanks a lot. Paul: >Gee, Tim, what a substantive rebuttal. Thanks for noticing. Adults do not act in loco parentis to other adults, except as a way of expressing contempt. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "It is better to be a human being dissatisfied than a pig satisfied; better to be Socrates dissatisfied than a fool satisfied." -- John Stuart Mill, UTILITARIANISM (1863)
chewy@apple.com (Paul Snively) (11/28/89)
In article <9090@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > In article <5352@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: > >I'd be more than happy to continue the > >discussion, although I believe it will be much easier when System 7 final > >ships, since at that point the details of the Alias Manager, et al. will > >be much clearler. > > In other words, we don't care what comments you might have on the > merits of this new feature. It's going in the new system anyway and it > will be just the way it always was going to be; just keep your > suggestions to yourself and let us tell you how things are. Well, that might be your interpretation of the statement. All it really means is that, as was pointed out by people other than myself here long ago, the concerns that you raised regarding non-Macintosh file servers with respect to file IDs actually are being addressed. The problem is that documentation specifying exactly what non-Macintosh AFP servers should do to support file IDs isn't currently available. In article <9090@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > It's obvious that at no time do the Apple representatives consider the > dialogue with the developer community to be two-way. Any criticism or > complaint that may be raised is there to be waved aside, not to be > taken into account as a possible influence on future software > directions. This may be obvious to you, but it's certainly not obvious to the various developers to whom Apple has talked and whose comments and criticisms actually HAVE made a noticeable (to them, as well as to others) impact on our software. A particularly good example of an evolved piece of software from one revision to another based on third-party feedback is MacApp. In article <9090@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > Tim: > >and people are coming > >to ignore your conclusions even in the very rare cases where you > >sincerely try to prove them correct. > > Paul: > >For whom exactly are you speaking? So far, you're the only one making > >these claims. > > False. I've received an e-mail message from a person who mentioned > making exactly the same complaints about you here, with the same level > of non-response. And as I already pointed out, a number of people have > commented here on the failure of your messages to adequately address > issues like exactly why tail patches are wrong, the non-run-time nature > of library code, and the binding nature of instructions in Inside > Macintosh, as well as my points on problems with file ids. I guess > you've blocked these people's messages from your mind; inconvenient, > aren't they? Well, Tim, all I can say is that I've received several EMails saying precisely the same thing about you; where does THAT get us? I have explained why tail patching is incorrect programming on the Macintosh, as has Larry. I can reiterate if anyone is still unclear. The "non-run-time nature of library code" is a non-sequitur; others here have also pointed out why software updates when using any library code are sometimes necessary. "The binding nature of instructions in Inside Macintosh" is still another non-sequitur; if it weren't there would be no Tech Notes supplementing or revising Inside Macintosh. As if that weren't enough, Inside Macintosh will be on CD-ROM soon, in stack form, which will hopefully be updated at least as regularly as the Tech Note stack is. There isn't anything that hasn't been addressed multiple times, including technically. The fact that the answers aren't what you want to hear is what's preventing you from recognizing that the issues have actually been dealt with. In article <9090@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > Adults do not act in loco parentis to other > adults, except as a way of expressing contempt. That's a perfectly valid expression of opinion, couched in the form of a statement of fact. As such, it is also completely illusory. __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________
francis@mirror.UUCP (Joe Francis) (11/30/89)
Paul, a while ago I was reading this thread to learn about the risks of Tail Patching. I do not know that I read it from the very beginning and we purge old News here, so I may have missed something. I am interested in the technical liabilities of tail patching. I am NOT interested in being told not to tail patch (it's not that I will ignore such a warning; it's that the information I want is not whether or not to, but why not to). I have read and understand the explanation of the dangers tail patching poses with respect to Apple fixes to routines which check to see who calls them. However, many articles ago you said that there were numerous subtle reasons not to tail patch. None of the notes I have read refer to these other reasons, and I would very much like to hear about ANY of them. Thanks, Joe Francis ------------------------------------------------------------------------ SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM EMAIL to: "Nobody Expects the francis@mirror.TMC.COM Spamish Repitition!" ------------------------------------------------------------------------
chewy@apple.com (Paul Snively) (11/30/89)
In article <33413@mirror.UUCP> francis@mirror.UUCP (Joe Francis) writes: > I have read and understand the explanation of the dangers tail patching > poses with respect to Apple fixes to routines which check to see who > calls them. > > However, many articles ago you said that there were numerous subtle > reasons not to tail patch. None of the notes I have read refer to these > other reasons, and I would very much like to hear about ANY of them. Ok, I'll try to be thorough: 1) Many of the subtleties arise precisely because tail patches may break patches to old bugs, thereby either a) reintroducing the old bug, or b) worse, introducing some mutant version of the bug that differs in some unpredictable way from the original. Basically, many of the subtleties arise from the non-deterministic way in which a tail patch may break the system. It's not that your system will crash when it calls the patched trap, or the trap that the patch fixes, or anything so simple. Your system may not crash at all; it may just behave strangely. Or it may crash seconds or minutes or hours after calling the patched trap. Or... 2) I think the article that you're referring to was in specific response to a post with a suggested mechanism for allowing tail patches (namely to shadow the trap dispatch table), and the point that I was making was that shadowing the trap dispatch table isn't a viable alternative because: a) Some ROM routines don't call traps; they indirect through the trap dispatch table. b) Some third-party vendors' add-ons play twisted games with trap patches, in some instances even patching _GetTrapAddress so that it lies to you. Shadowing the trap dispatch table would only confuse matters in such a case even more. c) Some software tools, such as debuggers, HAVE TO, in some cases, ignore the standard trap dispatching mechanism, and it's unclear how they would behave in the presence of a shadowed trap dispatch table. I hope this clarifies somewhat what some of the potential ramifications are. __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________
lsr@Apple.COM (Larry Rosenstein) (11/30/89)
In article <33413@mirror.UUCP> francis@mirror.UUCP (Joe Francis) writes: > However, many articles ago you said that there were numerous subtle > reasons not to tail patch. None of the notes I have read refer to these > other reasons, and I would very much like to hear about ANY of them. Here's one. (CAVEAT: I don't write system software patches, so the following is based on poking around with Macsbug.) On a Mac II there's a come-from patch for GetHandleSize. If you look at the patch, you see that it first tests whether GetHandleSize was called from address $4081885E. If it was, then it calls MaxSizeRsrc instead of GetHandleSize, and returns. (It also handles the case where the handle isn't a resource and returns $26 as the size.) That address happens to be in the Print Manager code. Presumably, there the Print Manager is calling GetHandleSize and it should be calling MaxSizeRsrc. (More likely, there is some subtle bug in the code.) Now, if you patch GetHandleSize, then when GetHandleSize is called your patch executes. If you do a JSR <old-GetHandleSize>, then the return address as seen by the first patch is never going to be the magic address I mentioned. Therefore when the Print Manager calls GetHandleSize, it will bypass the bug fix and call the GetHandleSize implemented in the ROM. I don't know what the effect of this would be; presumably something unsual would happen during printing. Another example on the Mac II is HUnlock. This one seems to be fixing a bug in the QuickDraw picture code, having to do with color tables. I hope this helps. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
yahnke@vms.macc.wisc.edu (Ross Yahnke, MACC) (12/01/89)
Apple documents all traps that may move memory, as an aid to promote safe programming practices. Would it make any sense or be any help if Apple were to do a similar list? How about a tech note that documents which traps are patched, and maybe for what reason, so as to guide those who will inevitably go and patch things in spite of Apple's admonitions? That would seem to me to be an 'official' way for Apple to say, "Don't tail patch, but if you do - here's what to watch out for..." >>> Internet: yahnke@macc.wisc.edu <<< >>> Mille voix chuchottent <<c'est vrai>> <<<
chewy@apple.com (Paul Snively) (12/01/89)
In article <2744@dogie.macc.wisc.edu> yahnke@vms.macc.wisc.edu (Ross Yahnke, MACC) writes: > Apple documents all traps that may move memory, as an aid to promote > safe programming practices. Would it make any sense or be any help > if Apple were to do a similar list? How about a tech note that > documents which traps are patched, and maybe for what reason, so > as to guide those who will inevitably go and patch things in spite > of Apple's admonitions? > > That would seem to me to be an 'official' way for Apple to say, > "Don't tail patch, but if you do - here's what to watch out for..." It's a really great idea, but it's really not feasible because different Systems patch different ROMs on different CPUs differently. That list would have to be revved at every System release for every CPU and every version of the System file. There are also questions like: what else is patched if you have 32-bit QuickDraw installed? What about having MultiFinder version X as opposed to not having it? There are just too many variables, but thanks for the suggestion! __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________
rang@cs.wisc.edu (Anton Rang) (12/02/89)
In article <2744@dogie.macc.wisc.edu> yahnke@vms.macc.wisc.edu (Ross Yahnke, MACC) writes: >Apple documents all traps that may move memory [ ... ] >Would it make any sense or be any help if Apple were to do a similar >list [of traps which cannot be tail-patched]? Seems to me that this list would change too often to be useful. Apple's patches are basically bug-fixes; if somebody finds a new bug, the easiest way to fix it may involve checking a trap which was previously safe to patch. I like the idea of a Tech Note documenting bugs fixed in various system releases, though.... Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+
lsr@Apple.COM (Larry Rosenstein) (12/02/89)
In article <RANG.89Dec1112139@derby.cs.wisc.edu> rang@cs.wisc.edu (Anton Rang) writes: > I like the idea of a Tech Note documenting bugs fixed in various > system releases, though.... We have distributed change notices for recent versions of the system. Some of these are available for FTP on Apple.COM. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
francis@mirror.UUCP (Joe Francis) (12/02/89)
In article <5532@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: >In article <2744@dogie.macc.wisc.edu> yahnke@vms.macc.wisc.edu (Ross >Yahnke, MACC) writes: >> Apple documents all traps that may move memory, as an aid to promote >> safe programming practices. Would it make any sense or be any help >> if Apple were to do a similar list? How about a tech note that >> documents which traps are patched, and maybe for what reason, so >> as to guide those who will inevitably go and patch things in spite >> of Apple's admonitions? > >It's a really great idea, but it's really not feasible because different >Systems patch different ROMs on different CPUs differently. That list >would have to be revved at every System release for every CPU and every >version of the System file. Hmmm. There are other pieces of mac documentation that are constantly being revved. How 'bout this: Have a list of traps which have, in at least one System/CPU/Quickdraw/MultiFinder/fillintheblank combination, been patched? Just a list with no details about the patch(es) or what combination(s) have a patch(es), would be neato. I know another thing that would be neato - so neato, in fact that maybe already been done. Does anyone know where I can find a list of what Toolbox routines may place gobs of stuff on the stack? I had a problem with ScrollRect once, and while it was probably some mistake of my own, I kept wondering if it was trying to put this rather large 8-bit pixel depth rectangle I was orking with onto the stack. I never solved the problem (just abandoned ScrollRect instead) and I still don't know if this might be the case. Any pointers about where I could get such a list would be very welcome. ----------------------------------------------------------------------- SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM Joe Francis Nobody expects the Internet: francis@mirror.TMC.COM Spamish Repitition!
jamesm@sco.COM (James M. Moore) (12/02/89)
In airteagal <2744@dogie.macc.wisc.edu>, scriobhann yahnke@vms.macc.wisc.edu (Ross Yahnke, MACC): >That would seem to me to be an 'official' way for Apple to say, >"Don't tail patch, but if you do - here's what to watch out for..." >>>> Internet: yahnke@macc.wisc.edu <<< >>>> Mille voix chuchottent <<c'est vrai>> <<< I've never worked for or with Apple technical suport, so I can't speak for them in particular, but this is the kind of thing that makes support departments in general run in fear. What happens when you do things like this is that you're going to get a fairly substantial group of people who see this list and then assume that it's OK to patch. When it doesn't work they call and do their level best to make your life miserable because you won't help them fix a problem that they shouldn't have created in the first place. And the people who don't call and who are using the list will be producing potentially dangerous software. Add to all of that the effort necessary to create and maintain the list, which is probably going to change for every release of system software, and you end up with something not worth doing. -- James Moore | Nil aon .sig maith agam anois - Santa Cruz Operation UNIX Tech Support | B'fheidir an tseachtaine seo jamesm@sco.com | chugainn.
alain@atr-la.atr.co.jp (Alain de Cheveigne) (12/03/89)
yahnke@vms.macc.wisc.edu writes: >Apple documents all traps that may move memory, as an aid to promote >safe programming practices. Would it make any sense or be any help >if Apple were to do a similar list? How about a tech note that >documents which traps are patched, and maybe for what reason, so >as to guide those who will inevitably go and patch things in spite >of Apple's admonitions? > >That would seem to me to be an 'official' way for Apple to say, >"Don't tail patch, but if you do - here's what to watch out for..." > >>>> Internet: yahnke@macc.wisc.edu <<< >>>> Mille voix chuchottent <<c'est vrai>> <<< How about a similar list for traps that *unlock* handles ? It took me all of a long time to learn that any routine that dereferences handles should start with HGetState (instead of just HLock), and end with HSetState (instead of HUnlock). The reason is this: if the routine calls HUnlock on exit, it leaves handles unlocked for the code that follows the routine call. This is a nice source of tough bugs. If instead routines just call HLock, leaving the caller to do the unlocking, chances are a few handles will be missed and remain locked, cluttering the heap. If you use HGetState and HSetState instead, the routine leaves all handles just the way they were before the routine was called. The caller doesn't have to know how the callee does his stuff, which is the way it should be. But it seems that some ROM routines don't know it, and unlock handles behind one's back. A list of those would be nice. And how about a note about why HGetState and HSetState are useful ? (or have I missed it ?) Alain de Cheveigne, alain@atr-la.atr.co.jp
tim@hoptoad.uucp (Tim Maroney) (12/05/89)
In article <2744@dogie.macc.wisc.edu> yahnke@vms.macc.wisc.edu (Ross Yahnke, MACC) writes: >Apple documents all traps that may move memory, as an aid to promote >safe programming practices. Would it make any sense or be any help >if Apple were to do a similar list? How about a tech note that >documents which traps are patched, and maybe for what reason, so >as to guide those who will inevitably go and patch things in spite >of Apple's admonitions? > >That would seem to me to be an 'official' way for Apple to say, >"Don't tail patch, but if you do - here's what to watch out for..." Then they would be forever limited to only those come-from patches that are now in place. The whole point of this mechanism is the ability to fix bugs that are accidentally introduced into the ROMs. I'm sure Apple would love to commit to having bugs only in certain parts of the system, but it's not possible. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "I wouldn't work for Dukakis if my life depended on it. I've worked for Greeks and I know just how filthy and stinking they can be." -- Caller, KGO-AM, 8 Nov 88
brecher@well.UUCP (Steve Brecher) (12/18/89)
In article <5540@internal.Apple.COM> usenet@Apple.COM (Larry Rosenstein) writes: >> In article <RANG.89Dec1112139@derby.cs.wisc.edu> rang@cs.wisc.edu (Anton >> Rang) writes: >> I like the idea of a Tech Note documenting bugs fixed in various >> system releases, though.... > > We have distributed change notices for recent versions of the system. > Some of these are available for FTP on Apple.COM. Ya, but there is no detailed list of known bugs. On several occasions I have spent considerable time diagnosing bugs in ROM or system software and reported them, only to be told that they were already known. For example, there is now a bug in FMSwapFont (possible LoadResource between dereference to a handle and use of the pointer) which is fixed in the IIci and Portable ROMs (but not on other machines running the current System) -- which I learned in response to the bug report. It would be very helpful if Apple maintained list of known ROM and system software bugs; it could be accessible, e.g., on AppleLink. -- brecher@well.UUCP (Steve Brecher)
wdh@well.UUCP (Bill Hofmann) (12/20/89)
In article <15079@well.UUCP> brecher@well.UUCP (Steve Brecher) writes: >It would be very helpful if Apple maintained list of known ROM and >system software bugs; it could be accessible, e.g., on AppleLink. Seconded. I've also tracked a number of bugs, some of which were (happily?) news to DTS folks, but a few of which weren't. I'm sure that the System Software group maintains a bug list, I guess the real issue is the politics of making such a thing public, even within the developer community. I think, though, the service to the developer community would outweigh the concerns of a perceived unreliability of system software. Face it, while the early systems were pretty robust (because not so much could go wrong), the ever- increasing complexity of the Macintosh system makes bugs a *legitimate* if unhappy fact. -Bill Hofmann