Subject: Re: IIgs run-time libraries
Newsgroups: comp.sys.apple2.programmer
From: dempson@actrix.gen.nz (David Empson)
Date: Sun, 6 Aug 2000 22:34:11 +1200
Message-ID: <1eeyr0c.12x7wbi1qixk6wN%dempson@actrix.gen.nz>
References: <3989EAA3.17D0459A@spam.com>
Organization: Empsoft
User-Agent: MacSOUP/2.4.2
NNTP-Posting-Host: 202.49.157.176
X-Original-NNTP-Posting-Host: 202.49.157.176
X-Trace: 6 Aug 2000 22:33:02 NZST, 202.49.157.176
Lines: 82
Path: lobby!newstf02.news.aol.com!portc01.blue.aol.com!portc03.blue.aol.com!newsfeed.cwix.com!news-hog.berkeley.edu!newsfeed.berkeley.edu!ucberkeley!news-stock.gip.net!news.gsl.net!gip.net!news.iprolink.co.nz!news.actrix.gen.nz!dempson



Matt Jensen <no@spam.com> wrote:

> Does anyone out there know of a fairly simple way to use
> dynamically-linked library files on the IIgs with GS/OS 6.01?  I am
> looking for something with functionality similar to .dll files on
> Windows and .so files on Unix.

There isn't anything which is an exact equivalent, but there is
something in the same ballpark: file type $B4 (RTL) is a run-time
library.

There is no file type note for it, and I've never actually seen one.  I
suspect it isn't supported by the ORCA linker (Mike Westerfield should
be able to elaborate) but I have a vague recollection that it was
supported by Apple's LinkGS (either the original MPW version or the port
to APW).

The ProDOS 16 Reference warns that initial releases of ProDOS 16 may not
support these files, but describes the theory behind them, with the
intention being that support would eventually be available.

Basically, an RTL works exactly like a normal library, except that the
code is not copied into the application.  Instead, the application file
contains inter-segment references which are partially resolved when the
application is launched, and resolved when the segment is loaded
explicitly by the application or as a side effect of the first JSL to
the RTL.

The RTL must be present when the application is launched.  I'm not sure
what the situation is with pathnames - it may be possible to refer to
*/System/whatever, or the linker might only be able to cope with the RTL
being in the same directory as the application.  There is no "search
path" support.

An RTL generally consists of dynamic segments, and the first call to a
segment will load it into memory (the same mechanism applies to dynamic
segments within an application).  For safety, the application can
pre-fetch dynamic segments to ensure they are available before calling
them (to avoid a fatal error if there is a problem loading them).  When
the segment is loaded, all JSL references to it are effectively patched
to point to the loaded copy (via the jump table, which is part of every
multi-segment application with dynamic segments).

In addition to this built-in run time library support, an application
can also use the system loader directly to load and execute arbitrary
executable files.  The complication is that it will have to deal with
all of the entry points itself - it won't be handled automatically, and
there is no "symbol table" to assist with this task.

> Please note that I *do not* want to write a tool.

A user tool is the standard method of doing this sort of thing on the
IIgs.  Jawaid Bazyar did a serial port driver wrapper as a user toolset,
which worked quite well (I used it in a bulletin board many years ago).

> I would really like to be able to find all libraries in a given folder
> (such as an
> "Extensions" folder) and search each one for a particular exported
> function symbol, then jump to that function if it is found.
> 
> Is there any way to do this using Orca/C or (gulp) Orca/M?

Not as a standard.  You could invent your own format for a symbol table
and use assembly macros to build an entry table with named entry points,
then tack the whole thing on the front of the file.  It would need a new
file type, and preferably a user or system tool set to provide
standardised support (or you could just write the support code as a
library and link it into all applications which needed it).

I doubt you could do this just with Orca/C.  Assembly code would be
needed, so you have full control over the structure of the output symbol
table header.

Another possibility might be to use embedded symbols for GSBug, but this
would require searching the executable to locate them.  I haven't done
any IIgs programming for quite a while now, so my recollection of this
mechanism is very hazy.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P O Box 27-103, Wellington, New Zealand