🚀 go-pugleaf

In <9147@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes:
>In article <7052@shlump.nac.dec.com> guineau@wjg.enet.dec.com () writes:
>>To implement Mutual Exclude, you can still use the data structures provided
>                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>by Intuition. When you get an event (IntuiMessage) for a gadget with the
> ^^^^^^^^^^^^
>>MutualExclude bit set, just go through it's exclusion mask and 
>>"generate events" for the gadgets it excludes. By "generate events" I mean do
>>whatever necessary to make the other gadgets think they're "off".
>>
>>John
>
>And MARKV@kuhub.cc.ukans.edu (MARK GOODERUM - UNIV. OF KANSAS ACS - MARKV@UKANVAX)
>writes:
>
>>Although you are free to use the field on your own to track things manually
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>I have no idea if this would break in the future if this field did begin to
>>get used.
>
>>Mark Gooderum			Only...		\   Merry Christmas !!!
>
>WRONG!  Under no circumstances should you help yourself to a field that
>the system reserves for possible future use.  If we were to implement
>mutual exclusion using this field, yet you were using the field for
>your own implementation, how well do you think the two would co-exist?
>
>Not very well at all.

Whoa!  That field is specified, in the latest includes I have, as being the
proper place to specify gadget mutual exclude. It is most definitely NOT
specified as being reserved, nor are there any warnings against using it as a
gadget mutual exclude field. While I fully realize that gadget mutual exclude
does not work in the current release, that is completely beside the point.

>The rule is simple:  Make sure all unused or reserved fields are properly
>initialized (normally to all zeros).

Yes, the rule _is_ simple, but that field is NOT specified as unused or
reserved.  For the rule to work, it must work both ways.  You cannot reasonably
expect to leave fields lying around that are not marked as untouchable and just
sort of hope that nobody will use them.  Worse, you cannot reasonably specify a
field as being for a particular purpose and hope to defend yourself when
someone uses it for that purpose.

>You have plenty of other places to store your own data.  We generally don't.
>
>In summary, we reserve the right to use the MutualExclude field of gadgets
>for anything we please, which may not even be Mutual Exclusion.  Correctly
>written programs leave these fields NULL.  We can't guarantee compatibility
>of incorrectly written programs with future revisions of the Amiga hardware
>and software.

Do you reserve the right to make GRELBOTTOM suddenly mean GRELRIGHT, or to
change the call to OpenLibrary() to DoIO()?  Correctly written operating
systems do what the documentation says they do.  It is an unfortunate fact of
life that bugs can happen.  The proper thing to do in the case of this
particular bug is to either implement this field for its originally intended
purpose, leave it alone and let the authors use it for their own mutual exclude
routines, or to document it as being reserved, and wait a reasonable length of
time (a few releases perhaps), before using it for something else.

If CBM decides to use this field for something other than gadget mutual
exclude, you can expect to have to defend your actions against a flood of
protest, and to my mind, your position will be indefensible.

>There is a fairly long history of such violations (using MOVESR instead
>of GetCC(), not putting image data into chip memory, etc.).  Please learn
>from these kinds of mistakes instead of attempting to create new ones
>or worse, encourage them.

These are entirely different matters, and not even close to being analogous.

All through the includes, one can find reserved and private fields. ROM
Stompers and Structure Twiddlers have been duly warned about the consequences
of messing with them. 'Proper Programmers' do not mess with them, but they
might be using a field DEFINED BY CBM to do what they see as perfectly
legitimate operations, fully within the letter and spirit of the documented
guidelines.

This is not a flame... yet. It is a vehement plea for sanity. There are enough
programs out there already that purposely or inadvertently violate the rules.
The last thing we need is for CBM to pull the rug out from under us by changing
the rules in mid-stream. Please reconsider your position on this matter.

>     Peter Cherna, Software Engineer, Commodore-Amiga, Inc.
>     {uunet|rutgers}!cbmvax!peter    peter@cbmvax.cbm.commodore.com
>My opinions do not necessarily represent the opinions of my employer.

-larry

--
" All I ask of my body is that it carry around my head."
         - Thomas Alva Edison -
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+