DLL Programmer's Guide for TNS/E Systems

DLLs on a TNS/E System
DLL Programmer’s Guide for TNS/E Systems—527252-006
1-12
Other Loader Operations

Semi-globalized — A semi-globalized loadfile uses its own definition for any of its
symbol references when it offers such a definition, but imports other definitions
from the program it is loaded with and any loadfile in the program’s loadList.
In any case, if the symbol to be imported is defined only once in the collection of
loadfile candidates to supply imported symbols, that symbol is used to resolve your
loadfile’s need. Good practice normally avoids multiple definitions of the same symbol
in the loadfiles in a loadList, because of the danger that an imported symbol could be
resolved in an unexpected way. However, the library facility allows multiple definitions,
and symbol resolution in such cases is discussed in Import Controls and SearchLists
on page 4-5.
Localized symbol resolution is consistent with long standing conventions on NonStop
systems including TNS programs and user libraries, as well as native non-PIC
programs and SRLs in TNS/R. The linker’s default is to localize loadfiles. On the other
hand, globalized symbol resolution is an industry (UNIX) standard. One useful
consequence of globalized symbol resolution is that DLLs can import symbols from
their clients, including the program. Globalized symbol resolution can be especially
useful when multiple loadfiles define and use the same symbol and you want to ensure
that they all use the same one. If you declare all these loadfiles to be globalized, then
the loader will resolve all these imports to the same exported symbol. However, object
files using globalized or semi-globalized import are likely to take somewhat longer to
load, because the linker is unable to preset bindings for files not seen at link time.
Other Loader Operations
The loader and operating system assign the program being loaded and the libraries in
its loadList to their positions in virtual memory and bind their symbols to their
appropriate definitions in these loadfiles.
Adjusting Symbol Values and Relocating in Virtual Memory
You do not have to relink a loadfile when a DLL it uses is changed. To accommodate
this, each instance of a DLL must be relocatable in virtual memory when the DLL is
loaded for execution. This requirement is the reason that programs and DLLs are
written in PIC (although all code on a TNS/E system is PIC). Virtual instances of a DLL
do not depend on being loaded in any particular location in virtual memory, and they do
not depend on any symbols they reference being loaded in any particular location. For
example, you can replace a DLL with a new one of the same name that provides the
same symbols without relinking the DLL’s clients, even if the locations of these
symbols are different in the two DLLs.
Dynamically Loaded DLLs
A running program or DLL can load and open a previously not-loaded DLL and gain
access to the symbols it offers. DLLs invoked this way are called dynamically loaded
DLLs; they are further described in Section 3, Dynamic Use of DLLs
.