Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!apple!apple.com!chewy
From: chewy@apple.com (Paul Snively)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Tail Patches
Message-ID: <5405@internal.Apple.COM>
Date: 27 Nov 89 18:03:46 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 69
References:<5249@internal.Apple.COM> <17090@dartvax.Dartmouth.EDU> <5292@internal.Apple.COM> <1989Nov20.182741.2658@eng.umd.edu> <5320@internal.Apple.COM> <6353@drilex.UUCP>

In article <6353@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) 
writes:

[Stuff about Restart removed]

> This raises the issue for third-party applications tool developers.  
Either
> one waits for Think, TML, to decode those libraries, or one does it them-
> selves.

Well, that really means that we need to get new library code to folks like 
Symantec and TML Systems faster, which I'll certainly agree with.

In article <6353@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) 
writes:
> So, you're supposed to ship MPW, with some sort of updates subscription,
> to everyone who wants to automate their dental practice?  Here, I believe
> you're way off base, and Apple appears to have screwed up.  (This stuff
> hasn't really affected me; I've never managed to complete a real Mac
> application.  Just too much investment in doc & time...)

The answer to the first part is clearly "no; it's not necessary in the 
vast majority of the cases."  If the "dental practice" is using THINK or 
TML, they should get updates from them.  On the other hand, if this dental 
practice IS doing Macintosh programming, they do have to concern 
themselves with keeping up to one extent or another.  That's just the way 
the real world is.

In article <6353@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) 
writes:
> For better or worse, Documented is Documented, whether it's an assembly-
> language note or a library description.  Major computer manufacturers
> come to learn (and hate) this.

I'm not disagreeing with this; I'm saying that precisely because it's 
being committed to print, Inside Macintosh could stand to try to be a 
little more careful about saying things like "jump into ROM here."

In article <6353@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) 
writes:
> Apple comes out on the lower end of the "how many applications break on
> each release" scale.  I think Berkeley CSRG is actually lower, but most
> commercial vendors are forced to do much better.  MVS will still run
> binaries from OS/360, compiled 20 years ago.  Unisys/Burroughs finally
> got tired of offering such compatibility: they now only support a binary
> for four releases of the operating system: one forward, the current one,
> and two back.  *If the application is too old, it isn't run*.  This is
> much better than have one function break on odd Tuesdays--it keeps
> everything up front.

I think you mean to say the HIGHER end of the scale.  Actually, if you go 
around trying most commercial Mac applications on most of our machines and 
OS releases, they mostly tend to work across everything from the Mac Plus 
running System 4.1 on up.  The things that break the most are a) 
non-commercial efforts that don't spend so much time paying attention to 
the guidelines, b) INITs and the like, which tend to be hacks by 
definition.

It's not quite fair to compare the microcomputer industry's compatibility 
efforts to the mainframe industry's; the micro industry has to move much 
faster and make larger steps to differentiate its companies from each 
other.

__________________________________________________________________________
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.
__________________________________________________________________________