Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!amdahl!oliveb!amiga!mitsumi!jimm
From: jimm@mitsumi.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga
Subject: Re: A Modest Proposal (was Re: Intuition's "don't mess with these" fields...)
Message-ID: <877@mitsumi.UUCP>
Date: Sun, 8-Nov-87 16:13:49 EST
Article-I.D.: mitsumi.877
Posted: Sun Nov  8 16:13:49 1987
Date-Received: Wed, 11-Nov-87 02:48:26 EST
References: <1961@amiga.amiga.UUCP> <1825@cadovax.UUCP>
Reply-To: jimm@mitsumi.UUCP (James Mackraz)
Organization: Mitsumi Technology Inc
Lines: 79
Keywords: This situation is making enemies of those who should be friends.

In article <3258@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes:
)
)Having seen two groups of well intentioned people, trying to do the
)best job that they can, get furious with each other, and ignoring any
)justice in the other's cause, I'd like to extend my sympathies to both
)Keith Doyle and the CATS crew.  The sad part is, both sides are right.
)
)CATS is completely correct.  

)Keith is ALSO completely correct.  When you work in a marketplace,
)your potential customers won't even LOOK at your product until it is
)at least as good as the competition.
)
)So, rather than having the good guys fight the good guys, I suggest
)ganging up on the villains of the piece, the folks whose use of
)unsupported AmigaDOS hooks has made the whole mess what it is.
)
)I suggest a two pronged approach.  First, CBM should make an effort,
)with malice aforethought, in each release, to break software whose
)disregard of standards causes problems like this. 
)
)Second, for a fee, Commodore should be willing to certify that a
)package meets all known CBM software standards.
)[ ... ] and will strongly
)endeavor _not_ to break it with new operating system releases.
)(I think "guarantee not to break" might be a bit too strong, but
)consider it.)
)
)Love to the lot of you.  You _all_ make my machine the joy it is.
)
)Kent, the (occasionally rather rational) man from xanth.

I agree that there are two sides to these issues, and as a major flame
contributor on this topic, I acknowledge the problems that the facts
give to all concerned.  The issue that gathered so much heat from
former and current C-A employees regards the causes of "buggy programs"
and a "threatening tone."

It isn't realistic to really try to break programs which rely on side
effects.  In spite of the fact that some programs broke under 1.2,
the rules were that existing programs were to be "guaranteed not to break."
For unavoidable reasons, and mistakes by programmers outside and inside
C-A, some broke.  I am sure the situation of any future releases will
be exactly the same: same guarantee, same problems.

An interesting note about programs and v1.2 compatibility: although
there were some disappointing compatibility problems, almost all programs
which we blew up needed to be revised to handle expansion RAM
in the same time frame, anyway.  I hope nothing this major happens again.

The issue I isolate on and which troubles me is that we (when I was at C-A)
had an official position on overscan which time and resources forced us into:
it was that programs should use their own View structure to present overscan
visuals, but should attempt no interaction in this mode.  This is, I believe,
exactly what DPaintII does.  We also provided advice on detecting/preventing
interaction.  We hoped that this was helpful, given that we felt true overscan
screens were an important hole in our capabilities.

Then we made two mistakes, it seems.  One, I elected to publish, for debugging
reasons, system-private fields from IntuitionBase.  Second, on free time for
Truth and Beauty, MoreRows was written and support made for it in Intuition. 
It is hard for me to reckon with the fact that these resulted in people's
problems.  It has changed my vote on providing Intuition source code to
registered developers.  I had honestly thought that no programmer would
release a product which contained the line:

#define DONTYOUDAREMESSWITHTHESE	

much less threaten to release such a program if CATS didn't provide
a suitably competitive alternative.

By the way, has anyone tried changing GfxBase->NormalDisplayRows/Columns?
GfxBase is entirely public, I believe.

	jimm
-- 
	Jim Mackraz
	Mitsumi Technology, Inc.		408/980-5422
	{amiga,pyramid}!mitsumi!jimm