Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!van-bc! From: lphillips@lpami.wimsey.bc.ca (Larry Phillips) Newsgroups: comp.sys.amiga.tech Subject: Re: Mutual Exclude Gadgets Keywords: Gadgets Message-ID: <947@lpami.wimsey.bc.ca> Date: 27 Dec 89 13:14:49 GMT Lines: 99 Return-Path: To: van-bc!rnews 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 | +-----------------------------------------------------------------------+