Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!oliveb!apple!well!shf
From: shf@well.UUCP (Stuart H. Ferguson)
Newsgroups: comp.sys.amiga.tech
Subject: Re: CBM, Why did you make it so hard?
Keywords: Graphics Libraries, reentrancy
Message-ID: <10970@well.UUCP>
Date: 15 Mar 89 00:34:28 GMT
References: <913@dover.uucp>
Reply-To: shf@well.UUCP (Stuart H. Ferguson)
Organization: The Blue Planet
Lines: 57

+-- fullmer@dover.UUCP (Glen Fullmer) writes:
| I have a friend that has ported a generic graphics package to the Amiga.

Great!

| So he thought he would fix that and create a graphics Amiga-shared library 
| that anyone can call at run time.

Wonderful!

| 2.  How does one make a generic package, like his graphics package, both
|     reexecutable and reentrant?  Does it require specific register allocation
|     via assembler programming?  Or is there an easier way? A different 
|     global hook that can be used to hang environments on?

Gee.  It's really not as hard as all this.  The basic "trick" (if you can
call it that) is to organize the library interface so that it has no "global"
variables.  All the context and state information get stored in structures
that the client program (the one who opened the library) owns.  It gets
these strucutres either by calling functions in the library to allocate
(and free) them, or by allocating it itself and calling a library
function to initialize it.  Intuition uses the first strategy, and the
graphics library generally uses the second.

One you have all the state info in a big packet, the client just calls
the library and passes it this structure.  The library itself is just
a collection of code that operate on these "handles" or "objects."  It
isn't really so much a "trick" as it is a basic design feature of an
Amiga shared library.  Since it sounds like the ported graphics library
maintains state in global "session" variables, it may need re-designing
to make it fit the Amiga style of shared library.

Now, it turns out that there is a place to store "global" variables
in a shared library -- the library base structure.  A shared library
can have a normal set of "global" variables if they are initialized
at startup and never change, such as a pointer to SysBase.  But if
values may change during the use of the library, they need to be locked
with semaphores to prevent clashes when multiple tasks are calling the
same functions in the library.  This is why you must call LockIBase()
before looking at the window lists and other structures located in
IntuitionBase.  Locking protocols are no fun.

| 6.  Why isn't it simpler?

Aw, it's not that hard, really.

| Granted, a lot of this is probably very naive for some of you guys, but
| where does one learn it?  References?

Look at Jimm's "elib" on Fish disk 87 for how to make one.  Look at how
the calls to Intuition and other libraries are organized to see how
they maintain context for each client task.

Once you understand the basics its pretty straightforward.  Good luck!
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC