Component Manager

["Tolian Soran" <jamesco@cogs.susx.ac.uk>]

I am presently in the middle of programming a component manager for MiNT.
Those of you who have heard of the Apple component system will know a little
about what I am attempting to achieve. Below is a short description of the
system. I would appreciate it if you could take the time to read this, and
post any comments/questions you may have.

The idea, is that the operating system of the computer can be 'retro' fitted
with new features, such as the capability to load/save different picture files
or sounds, provide functions to aid the playback of animations etc. I am
hoping to create a full graphical environment as a set of components.

It ocured to me the other day, however, that this system could also be used to
implements a shared library system, however, there would be no 'easy' way to
build this into a compiler, although it would be very easy to build a set of
include files to enable C software to use the component system.

The idea is, that a program wishing to use the component system, must fist
obtain a vector which tells that program what the component maager's process
ID is, and a whole bunch of other bits and pieces. I was wondering if and of
the poeple attmepting to create a shared library system knew which trap number
they are likely to use, so that my system won't clash (I am presently using
trap #0). As an aside, I notices the other day, that the Puntaes call (xbios
39 (0x27)) is still not implemented, despite the fact that technically,
MultiTOS is a disc loaded AES...

Anyways, once you have this vector from the component manager, you can make
calls to it my JSRing to either its 'access' or 'direct' functions. To
understand these functions: the 'direct' functions access the functions of the
component providing the 'direct' function, so the component manager's direct
function will enable you to call the components manager's own funcitons. The
access function is only provided by managers, and it allows you to call a
function belonging to any component logged onto that manager.

Lets say, that we have an image loading/saving manager logged onto the
component manager, and your program wants to load a picture that is stored in
JPEG format. In order to call the 'load' function of the JPEG component, we
have to get through the manager. So we call the access function of the
ocmponent manager to call the get_access function of the image loading/saving
manager. Now we have the access funciton of the image loading/saving manager,
we can call any of the functions of any of the components logged onto the
image loading/saving manager.

This may sound rather complicated, and time cosuming, however, it actually
only uses about 10 lines of asembly, 2 lines if you use macros.

Thanks for getting this far! There are lots of other little details about the
system, such as resident vs. non-resident components (managers are always
resident) and logging applications on/off components (to make sure the
component(s) you're using don't get unloaded...)

I am hoping to have a working component system up a running for sometime
shortly after christmas (and of January at the latest, coursework permitting).
I will be releasing documentation on the system around then.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DISCLAIMER:

This article may be harmful or fatal if swallowed. Do not insert this article
into the ear canal. Not responsible for injuries due to reading this article
while showering. Prolonged inhalation of fumes from this article may result in
nausea, dizzyness, convulsions, and death. Do not operate a motor vehicle,
heavy equipment, or power tools while reading this article. Dispose of this
article in a responsible manner when finished reading. No warranties expressed
or implied. May *not* be suitable for children under 12. Discontinue reading
the article if skin rash appears, or vision blurrs, and consult a physician.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~