Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!ptsfa!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac
Subject: Re: Should 64K ROMs be supported?
Message-ID: <1506@hoptoad.uucp>
Date: Wed, 17-Dec-86 19:00:25 EST
Article-I.D.: hoptoad.1506
Posted: Wed Dec 17 19:00:25 1986
Date-Received: Thu, 18-Dec-86 05:11:59 EST
References: <476@runx.OZ> <1490@hoptoad.uucp> <907@ur-tut.UUCP>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Centram Systems, Berkeley
Lines: 121

Sorry for the delay; news system problems.

First, David, your proposed solution for getting to globals at the interrupt
level without using writes into relative code space is incorrect.  CurrentA5
gives the A5 of the *current application*.  This strategy will fail very
badly under Switcher, causing the globals of various other applicvations to
be modified in undefined ways, and bringing the whole system to a lovely,
gnarly, crunchy crash.  I can see you've never written a socket listener or
protocol handler.  Care to make another stab at an answer?

Second, I rather resent your tone.  You keep trying to make it seem like I
am some fiend bent on screwing millions of people out of their Macs.  If
more software manufacturers had an upgrade policy as rational as Apple's,
then there would be no problem with cleaning up the OS.  Yes, some old
versions would break, and people would have to get the new versions.  Big
deal.  This isn't screwing over the users; it's refusal by the maufacturers
to upgrade every few months that screws over the users.  Upgrades are a
reality of software; nothing is perfectly bug free, and nothing is ever as
good as it could be with another few weeks of hacking.  (Apple could help
this process along by instituting a third-party software upgrade system
through registered Apple dealers.)

What causes my resentment is that we at Centram have had to do a huge amount
of compatibility hacking that serves no purpose but to make our software
work with some arcane software or hardware product for the Mac.  (A main
source of our compatibility problems is that the late introduction of record
locking forced a number of DB applications to depend on undocumented FS
behavior; this has also prevented any reasonable network caching.)
Fortunately, this phase ended shortly before release, we have almost no
compatibility problems now.  Do you think you're the only ones who suffer
from the fact that so many Mac programs and peripherals are ill-behaved?  Do
you think a professional developer neccessarily has less comprehension of
compatibility problems?

I think this upgrade/"don't step on Bill Gates' toes" problem is receding
into the past.  Mac software used to be a gamble, on which one could barely
squeeze through with luck.  Manufacturers were unwilling to spend a pittance
on upgrades for software that would have only a small margin of profit
anyway.  Now, in 1986, things are very different.  Mac sales exploded with
the Mac+, as I'm sure you know.  Suddenly everyone and his brother wants to
jump on the bandwagon.  Apple is now in a position 180 degrees opposed to
its earlier begging and pleading with developers to pleeeeeez write Mac
software; now it can dictate terms.  If the terms involved a general upgrade
cycle to last over six months or a year, the devlopers would jump to get
their software compatible first.

Third, do you inform developers when their software has to be specially
accomodated in the ROM?  (We usually do this with TOPS compatibility
problems.)  It seems to me that if Apple did this, then the ill-behaved
software could be wiped out in under a year.  This would then free *Apple*
to do some *serious* OS improvements, like adding multitasking on the 512K
and Mac+, improving the speed of the Resource Manager, adding more
user-selectable user interface operations, and so forth, instead of millions
of patches to keep things running.  Anyone who's stepped through the new
ROMs knows that they're a nightmare of "where was I called from" and "minor
hack to cope with incorrect calls".  I can't imagine how the current
software could possibly survive another revision cycle.

Seriously, compare the rate of improvement of the Mac OS with, say, UNIX or
VMS.  Pretty sorry, isn't it?

Fourth, it appears that I was correct about Apple overestimating the
difficulty of re-implementing the Mac OS, since according to Computer
Currents, the first Mac clone is through development.  To stay ahead in a
market of clones, Apple is going to have to clean up the OS so it will be
able to move faster than the clone makers.

Fifth, it might be interesting to examine why so many Mac applications are
so poorly behaved, as compared to, say, UNIX applications.  Obviously part
of it is that Hertzfeld and Haeberli are no way up to Ritchie's standards
(no insult there!  Very few are!), and part of it is the lack of memory
protection, but I think it strikes deeper than that.  It is weird that in an
OS so obviously influenced by Smalltalk, all the things that help make
Smalltalk (and most OS's) reliable have been ignored.  I am referring, of
course, to data representation hiding.

All through the Mac, the OS is presented not merely as a set of typed
objects on which various operations can be performed, as in Smalltalk or
UNIX, but as a set of data structures in process memory and ways of
manipulating them.  Example: NewMenu, NewDialog, and so forth should return
*typed descriptors* referring to *internal* system data structures not meant
to be touched by the application.  Imagine if UNIX, instead of returning a
descriptor on a file open, returned the system inode data structure for the
file; not just a copy, but the real data structure, and it would be
considered OK for the process to do whatever it wants with it.  Reliability
would plummet, security would be inconceivable, and it would be impossible
to extend the file system (as with the FSS mechanism) because of program
reliance on system data structures.  Sound familiar?

Programmers love to prove to themselves how clever they are.  Given a choice
between a clean, message/syscall-style way of accomplishing something, and a
dirty, sly, tricky way that shows that the person really knows what he is
doing, an awful lot of programmers will choose the latter.  Leaving these
back doors open, and even encouraging them by providing documentation on
internal system data structures to the application programmer, is suicide.

(Putting the data structures in an area of memory used by the application
for its own bookkepping also decreases reliability, of course.  A slightly
incorrect program is much more likely to write incorrect data near where it
is supposed to be writing it than it is to start writing to a random area.
And this storing of system data structures in process memory makes it
impossible to increase OS reliability by later adding memory protection.)

If these problems with lack of data rep hiding in the OS are not clear, I
will be happy to expand on them.  But it should be plain that one
significant reason for misbehavior of so many Mac applications is that the
whole design of the Mac OS encourages applications to screw around with
things that properly belong to the OS exclusively.

I realize my tone here is not overly polite, but I really don't appreciate
being accused of being out to screw everyone over, as you so delicately put
it.  It also doesn't help to have incorrect solutions presented in an
overbearing and self-righteous manner.  I am perfectly willing to have a
calm and polite discussion of the subject, but you are going to have to
drop your defensiveness and innuendos.  To point out that the Mac OS has
flaws is not a personal attack on David Gold, and to respond with
indignation and insult is not likely to convince anyone I am wrong.
-- 
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)