Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!tecot
From: tecot@Apple.COM (Ed Tecot)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Tail patches
Message-ID: <36881@apple.Apple.COM>
Date: 30 Nov 89 07:00:07 GMT
References: <5249@internal.Apple.COM> <17090@dartvax.Dartmouth.EDU> <17105@dartvax.Dartmouth.EDU>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 65

In article <17105@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes:
>In article <5212@internal.Apple.COM> chewy@apple.com (Paul Snively) writes:
>>And I'd be interested in any examples of "something that we have 
>>decided to break," let alone something that we have decided to break 
>>and then not fix.

I'm not going to claim that we never do this, but I will claim that we never
do it without reason.  We're not spiteful, and we don't make arbitrary
decisions.

>"Assembly-language note:  Changing the value of the block's master
>pointer lock bit with a BSET instruction is faster than HLock.
>However, HLock may eventually perform additional tasks."

Well, it still works in 24-bit systems.  This one we really had no choice in.
In order to increase the amount of memory available (which developers clamor
for), we will eventually have to break this.  I'd say that in this case, it
was a poor documentation choice.

>;The following twelve OS traps have been redundantly defined as
>;Tool traps as well. They should be
>;accessed as OS traps, but their slots in the Tool trap table
>;will be reserved forever.
>;	$1A GetZone
>;	...

Actually, I personally sweated bullets over this one.  We were running out
of traps, and I discovered that no one appeared to be using these redundant
traps anymore.  In fact, DTS went to the trouble to verify this, and found
that it was true.  DTS also found out that a thirteenth, undocumented
redundant trap WAS being used.  The application was fixed about a year and
a half ago.  In this case, we broke no one.

>Network Events.

Actually, we never broke these.  Network events were always implemented by
the libraries linked with the application.  Applications which used them
will continue to work, since the code which creates the events is in the
application.  Of course, there's no longer a guarantee that the events will
be delivered to the application that created them...

>Calling PopupMenuSelect under System 6.0 with Color QuickDraw caused
>the menuWidth and menuHeight both to be set to -1!  I was told that
>this was done deliberately to allow for the possibility of a loaded
>menu being used on different monitors.  Result: CalcMenuSize is broken
>under System 6.0 because its effect is not what IM says it is.

But this was fixed in System 6.0.2.  This was a bona fide bug.  I'd say
that this falls in the class of things that we fixed.

>Mac Plus keyboard shifted arrow keys return identical codes to numeric
>keypad keys.  This hardware was shipped in a broken state, and no fix
>was ever supplied.  Weak-ass excuse supplied by Apple was that this
>was done for compatibility with original separate numeric keypad.

Oh, so now you're complaining because of something we didn't break?
Bad example.  (Excuse my sarcasm, but I can't express it any other way)

>  "We broke it because it was a bad idea in the first place, anyway."
>
>  "Fine, but remember, it was YOUR idea."

What's wrong with admitting your mistakes and correcting them?

						_emt