This file contains a set of random observations about my experiences
developing Leach.

It is amazing that Leach got written at all. I originally thought of three
different designs for the program. I can't get the two most interesting of
those ways to work. I started with the crudest approach. Encouraged by
initial moderate success, I tried the more sophisticated approaches. In
both cases, I wasted a lot of time staring at the code until I realized
that there were fundamental insurmountable flaws in both of them.

One thing I learned is that you can't mess with the pointer value in
"UserPort" in an application's Window structure except in the limited ways
described in the Intuition Manual. If you change the contents of this
variable (Who in their right mind would even consider doing this?),
Intuition stops sending messages to the original IDCMP. Actually this might
have its uses in Leach technology. The problem is that the Host is also
likely to switch its attention to the new port. In retrospect, this isn't
surprising.  Intuition knows which window is the active one, and this
window gets all the input events that its IDCMPFlags specify.  How does
Intuition know which IDCMP to send the input event messages to? It looks in
the active window's Window structure, that's how.

The next lesson was that Intuition reuses IntuiMessage structures that are
returned to it by ReplyMsg()'s. This shouldn't be news to anybody. However,
when these messages get recycled into an unprioritized message queue,
Intuition does not re-clear the node's ln_Pri member. I tried to hide some
flags in ln_Pri and soon started receiving new messages with the flags
already set!

My original intent was to replace mp_Task and mp_Signal in the Host's
UserPort with values belonging to Leach. Late in the project, is noticed
that the signal Leach had allocated was the same as the one the Host was
expecting. This seemed like a bug, so I added code to make sure the two
signals had different values. The result was that the Host would respond to
the first signal "ring" from Leach and then ignore all others. Again in
hindsight, the reason seems obvious. Digi-View is almost certainly doing a
"Wait( 1L << UserPort->mp_Signal);". It's not saving the signal bit
independently. When Leach begins to execute, the Host is already Wait()'ing
for the original signal, so it responds to the first ring. From then on,
since I had changed the value of mp_Signal, the Host starts waiting for the
new signal.

It appears that for low resolution screen, you can get MOUSEMOVE messages,
even though the mouse pointer has not really moved. "Twitching" the mouse,
can generate a single input event/message that has the same mouse
coordinates as those in the last message you received, ie. the mouse hasn't
moved! It seems that MOUSEMOVE coordinates always reflect the dimentions of
your screen, but the MOUSEMOVE events are triggered by crossing boundaries
of a fixed 640x400 grid.

Leach Version 1.3 initially exibited serious problems when run against
Hosts that set the MENUVERIFY IDCMP flag; the system locked up when the
menu button was pressed! Apparently, Exec shuts down so completely,
Wait()'ing for the Host to reply to the MENUVERIFY message, that Leach
never got a chance to relay the reply back to Intuition. I don't yet
understand the exact mechanism behind this problem. For the time being, I
have had to settle for the poor solution of disabling all Intuition verify
messages.