Path: utzoo!utgpu!water!watmath!clyde!burl!codas!mtune!rutgers!rochester!ur-tut!dpvc
From: dpvc@ur-tut.UUCP (Davide P. Cervone)
Newsgroups: comp.sys.amiga
Subject: Re: Where's CAOS (was: Re: Are you playing with (enough) power?)
Message-ID: <798@ur-tut.UUCP>
Date: 11 Jan 88 18:03:45 GMT
References: <4124@watdragon.waterloo.edu> <4459@pyr.gatech.EDU> <1150@sugar.UUCP> <15998@watmath.waterloo.edu> <19975@amdahl.amdahl.com> <16076@watmath.waterloo.edu>
Reply-To: dpvc@tut.cc.rochester.edu.UUCP (Davide P. Cervone)
Organization: Univ. of Rochester Computing Center
Lines: 62

In article <16076@watmath.waterloo.edu> ccplumb@watmath.waterloo.edu (Colin Plumb) writes:
>I've heard various people say that Intuition isn't "really" a device.
>Can someone describe how it's not?

Intuition is not a device at all.  It is a library, as Jimm pointed out.  (A 
device and a Library have a lot in common, but they are not the same).

A device has code that runs as a separate process; you use messages to send
it information about what you want the device to do (e.g., you send the
serial.device a Standard IO Packet when you want to read a character from
the serial port).  

A library, on the other hand, contains routines that are called by the programs
that use the library.  These routines are run from the context of the CALLING
program (as opposed to a device, where they are called from the device process)
which means they must be reentrant.  A library also can have a set of global
variables that are common to ALL the programs that are calling it.  For 
example, the Intuition library has it's own global variables:  they are in fact
the ones pointed to by IntuitionBase, and described in 
intuition/intuitionbase.h.  When you open a library (or device), you get a
pointer to its global data variables. 

The routines in a library are called by the library vector table, which is a
jump table that sits in memory just below the library's global data.  That's
why the LVO variables are all negative, they point to memory IN FRONT OF the
library pointer.  In order to call an Intuition routine, you need the library
base pointer, that's why AmigaDOS must open Intuition:  to get access to
OpenWindow(), etc.

One thing that is unusual about Intuition is that it also runs part of its
code as an input handler.  That is, it runs in the context of the Input.Device.
That's why things like ClickUpFront work, they are called by the input.device
before it calls intuition.  If you look in the Intuition manual, you will
see a routine called Intuition() that takes an input event chain and returns
a (modified) input chain.  That's the routine that the input.device calls,
just like it calls myHandler in ClickUpFront.  Intuition() just does a LOT 
more than myHandler.  If you've ever looked at the contents of an 
IntuiMessage, you'll see that the reply port is NULL.  That is, there is
NO INTUITION TASK TO SIGNAL.  It's really "running" as part of the input
device.  Anyway, that's a whole different story.

I don't have my manuals or notes with me, so I may have mis-remembered some
of that, and some of it is only speculation anyway, but I think it is
largely correct.  I'd be interested in knowing if anyone has a different
view of how Intuition works.

Davide P. Cervone
dpvc@tut.cc.rochester.edu
dpvc@ur-tut.UUCP
DPVC@UORDBV.BITNET

P.S., if anyone want to verify this, you can probably do it the following way:
set up a dummy input handler, and send a message to the input device to
add your handler into the chain.  See ClickUpFront or HeliosMouse for a 
sample of how to do this.  You will need an Interrupt structure, as I recall.
This is linked into the input device's list of handler that it calls.  If I'm 
not mistaken, this is a standard exec LIST structure, so your interrupt
structure will contain a NODE structure.  You can use this to "peek" at what
other routines will be called by the input device.  You should be able to
match these against the pointer to the Intuition() routine in intuition.
You may have to get the actual address from the library jump tables, otherwise
you may just get the pointer to the glue routine in the amiga.lib library.
If anyone does this, let me know what you come up with.