.NH 1
Introduction
.PP
- blurb about reuse, evolution of libraries, and statement of intent.
.NH 2
static linking
.PP
The process of combining object modules and libraries to form an executable
is refered to as
.I static linking.
The linker (in \*(QX \fBwlink\fP) assigns logical addresses to symbolic names,
and combines the object modules in such a way that all references to a
given symbolic name are assigned the same logical address.
.B Wlink
is typically invoked by the program 
.B cc.
.PP
Software development is greatly simplified by the use of modules
which may be shared by several applications.
This facility both reduces the code bulk in developing a new application
and increases reliability, as fixes or improvements in library modules are
reflected in client applications.
Unfortunately, such modifications are only realized by relinking the
application, and delivering the new binary set to the users.
.PP
In multi-tasking operating systems, such as \*(QX,
many concurrently executing programs may be clients of a given library
set.
Each such program may logically share a number of modules; but because
they have been linked seperately (thus assigned different addresses),
they cannot share the same memory locations.
This inefficient use of system memory also imposes a greater IO requirement
on the system to load these programs from disk or network.
.NH 2
Dynamic Linking
.PP
The term
.I dynamic linking
is attributed to library systems which postpone the resolution of some
symbolic names until a program is loaded into memory.
By postponing this resolution, programs may be made to share common
modules, thus reducing memory and IO requirements; and the common modules
may be updated independant of the program thus immediately programs can
take advantage of fixes or upgrades.
.PP
.I Dynamic linking
is a general term for a spectrum of possible implementations.
This spectrum is characterized by the transparency of the process
to the \fIimplementor\fP of a service within the shared library.
Two general classifications of this transparency are \fIPure Code\fR
and \fIPosition Independant Code\fR.
.NH 2
Pure Code.
.PP
A module is deemed \fIpure\fR if it makes no direct reference to static
data locations.
That is, the module only contains cpu-instructions.
An impure module may be transformed into an impure \fIinterface\fP 
and pure implementation module.
The interface module may then be statically linked to the application;
while the pure implementation module is dynamic linked.
The system shared libraries (\fISlib16, Slib32\fP) in \*(QX 4.2
are 'pure' libraries, which were transformed mostly by hand.
.PP
The example below transforms an impure function into a pure one.
The process is performed by splitting the function into two: a
pure function which is bound to a shared library; and an impure function
which is statically linked to the application.
The impure function invokes the pure function providing pointers to the
static data items.
.PP
Pure code shared libraries are relatively easy to implement because
redirection is trivial \- all functions are named and invoked via
call or jump instructions; thus a \fIstub function\fP can be defined
which hides the mechanism to invoke the shared routine.
Without explicit language or processor support, it isn't feasable to
do the same thing with data references.
.IP "Before modification"
.CS
int
f(int x)
{
        static int    lx = 0;
        int           temp;
        temp = lx;
        lx += x;
        return temp;
}
.CE
.IP "implementation module"
.CS
int
__f(int x, int *lxp)
{
        int         temp;
        temp = *lxp;
        *lxp  += x;
        return temp;
}
.CE
.IP "interface module"
.CS
int
f(int x)
{
        static int         lx;
        return __f(x, &lx);
}
.CE
.NH 2
Position Independant Code.
.PP
A module is deemed \fIpostition independant\fR if in can execute, unmodified,
based upon any start address.
To achieve this requires that addresses of code and data variables be offset
by some value which can be adjusted on a process by process basis, typically
one of the processors registers is reserved for this function.
.PP
At one extreme, the \*(QX micro-kernel could be viewed as
a form of shared library.
Programs using micro-kernel services, such as Send, are invoked by
loading certain values into registers and executing the opcode
"\fBint 0f2h\fP".
At the other extreme; a shared object system such as employed
in the programming language
.B Smalltalk
implements an extensive database of classes and methods; whereby any
class implemented in any installed application is shared by all other
installed applications.
.PP
The \fIshared objects\fP system described in this paper is in the
middle of these extremes.
Some of the features of this object system are:
.IP 1.
\- does not require source code changes or language extensions, thus
code is portable.
.IP 2.
\- modelled after one available in
.UX
System V Release 3,
and is mostly source compatable with it.
.IP 3.
\- minimal overhead in terms of space and computation.
.PP
