🚀 go-pugleaf

In article <953@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
>In <9166@cbmvax.commodore.com>, mks@cbmvax.commodore.com (Michael Sinz - CATS) writes:
>>In article <947@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
>
>>>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.
>>
>>Ahh, but you must understand that the field is for SYSTEM use for that purpose.
>>Lets say you do it via a pointer to a special field that you invent.
>
>But I don't want to use it as a pointer to anything. I want to use it as it was
>intended to be used, as bit significant indicators to gadgets to be unselected.

Ok, even *IF* they could work, what will your program do once the system handles
the task?  Will your program also look at all of the gadgets and unselect and
refresh them?

Since this is a system field and may, at one point, be used by the system, you
could not use it.  For example, I at one point needed a way to send messages
to my own windows that looked like Intuition messages.  This was for timing.
Since the way the system was set up, I never knew how many windows there were
or if they wanted the ticks, I had to make a special list.  However, under your
thinking, I could have defined a new IDCMP bit (unused) and used that as a way
to signal that the program wants that message.  Then the normal ModifyIDCMP()
would work just like for all other messages.

I also have seen programs that say they need all of the IDCMP messages and
set the port to (-1) which is ALL bits.  What a surprize the will get when
a new message class that they can't handle correctly comes down the pipe-line
now that 1.4 (or 1.5) is out.

There is, however, another item.  Back a few years ago (for those of you who
don't know me, I am rather new at C=.  I was (and still am) a commercial
developer for the Amiga since Launch, 1985) there was talk about the Mutual
exclude field.  This was after 1.1 (which was 1.0 with bug fixes) and as
work was starting in 1.2.  When you look at the old definition (which, to
my surprize, still is in the include files!  That is an error...) you notice
almost at once that the method discribed will _NOT_ work.  Why?  Well, as
a bit-field, things would have to stay in the correct locations.  However,
system gadgets (of which you have limited control) are placed before user
gadgets by default.  You can dynamically add and remove gadgets and thus
change the position of the gadgets in the list.  You could have more than
32 gadgets, with the MutualExclude gadgets too far down on the list.  (They
would be right place, but after the system gadgets were put in, your gadgets
got moved).  The whole idea, as outlined briefly in the include files and
in the 1.0 intuition manual (I think 1.1 was the same) was broken.

Even so, that should not change the fact that you are using a system field and
doing your own work with it.  Even if you did it the exact same way as the
version of the OS that does Mutual Exclude, what is going to happen at that
point?  If your program does it in its own way, it will still continue to do
that in future version of the OS.  Then, you can convert the program to use
the new way, using the system field to replace the field you invented and
*poof* you are done.

The reason we keep talking about it this way is that *WE* can not add a field
to the structures anymore.  Unfortunately the structures have been defined as
USER (programmer) allocated and not as BLACK-BOX type of items.  Thus, when we
want to make enhancements, we need to do strange things such as the extended
structures pointed to by this structure from that structure b*llsh*t.  Or
we sneak in a bit that, if set, makes the structure something else.  However,
you, as the programmer of the application, can expand the structure at any
time.  You know that the current "struct Gadget" is not going to change as
otherwise current binary files would not work.  I have a feeling that as
things progress, there will be new classes of Intuition objects that are
100% Black-Box and then you will not be playing with our fields and we will
be able to add new fields at any time.  Until then, we just hope that
programmers do not play with things that belong to the system.

[stuff deleted...  This was getting too long...]

>
>I think you might want to consider putting that warning in the includes, and
>associate it with anything that doesn't currently work. When I write code, I
>try to follow the rules. If and when I go outside the rules, I expect that my
>code will break. When I go outside the rules inadvertently, I tend to be
>surprised that it doesn't work. The more explicit the rules are, the more it is
>explained why, the less problem there will be with broken software. It is in
>CBM's best interests to promote good software in any way they can.

Like I said above, I was *VERY* surprized to see this still in the include
files.  There will be something done about it.  (as I make a note to myself)

>>>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.
>>
>>Again, we have not yet defined HOW, so you can not define it youself unless
>>you really wish to BREAK when we do define it.  If the definition comes out
>>be a "Pointer to the Mutual Exclude function that gets passed, in D0 the
>>gadget ID and A0 the gadget address" and you used it as a pointer to a
>>MX data array or a bit field, POOF, your program goes and executes random
>>data at stange addresses.  YOU blow up, and it would have been YOUR fault.
>
>Well, again, I took those bits as being defined, and the HOW as being defined.
>The only thing I saw as undefined was the WHEN, which could have even been
>'never'.  Changing the meaning of the field is changing the meaning of the
>field, regardless of whether it is being used as MutualExclude or as something
>else entirely, and what the meaning is changed to has no bearing on the matter.
>I figured that in the interim, we could provide our own functionality, in a
>manner that would not break if the MutualExclude was implemented.
>
>I think you will break more than a few programs in 1.4, and some will be broken
>because of this particular field.  Yes, you can blame the programmer, there is
>nothing to prevent you from doing that, but I see CBM as sharing that blame in
>this case.

Maybe something will break if we do a Mutual Exclude.  And if so, I would think
that we (CBM) will say that the field was a system field and should have been
treated as such.  However, I (as myself, not CBM) feel that the fact that the
field was documented so much could have led to some confusion.  I (not CBM)
feel that if a program breaks because the programmer left the bit field
in the Mutual exclude field that it would be the include file's fault.  However,
if the programmer had USED that field to do the work (even if he used the
bit-field method) that was his fault.  I don't see any reasonable way to
defend the use of a system field in a self-implemented function.  I just hope
there are very few programmers that had tried the mutual exclude field, found
that it did not work, and did their own but forgot to remove the values from
the mutual exclude field.

>
>-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        |
>+-----------------------------------------------------------------------+

/----------------------------------------------------------------------\
|      /// Michael Sinz -- CATS/Amiga Software Engineer                |
|     ///  PHONE 215-431-9422  UUCP ( uunet | rutgers ) !cbmvax!mks    |
|    ///                                                               |
|\\\///          When people are free to do as they please,            |
| \XX/                they usually imitate each other.                 |
\----------------------------------------------------------------------/