DLL Programmer's Guide for TNS/E Systems

DLL Programmer’s Guide for TNS/E Systems—527252-006
1-1
1 DLLs on a TNS/E System
This section explains the TNS/E DLL (dynamic-link library) facility – what DLLs are,
how they work, how they can be used, and the basic workings of the tools that create
them. This facility comprises the linker (eld), the loader (rld), and the portions of the
HP NonStop™ operating system used in loading libraries. The facility runs in either the
OSS or Guardian environments, and on auxiliary Windows systems you can construct,
but not load, TNS/E applications that use DLLs.
DLLs or equivalent features exist on other platforms in the industry (for example, UNIX
and Windows); on UNIX systems they are known as DSO’s (dynamically shared
objects).
Note that this manual discusses the use of the linker eld on TNS/E systems. There is
a companion manual, The DLL Programmer’s Guide for TNS/R Systems that covers
the use of the other PIC linker, ld, which is designed for use on TNS/R systems.
Libraries and Symbols
As used here, a library is a loadable object or code file (or loadfile), that offers
functions and data for use by other loadable code files. In a library, each such function
and data item has its own symbolic name, as defined in its original source. This
symbolic name is known as a symbol, and the function or data offered under this name
is called the symbol definition.
Code that needs a function or data item refers to that function or data by its symbolic
name; such a reference is called a symbolic reference. Thus, a symbolic reference is
the requisition for or the use of the symbol’s definition. A symbolic reference is satisfied
by assigning to it the symbol value, which is the virtual address of the symbol’s
definition. The process of assigning that value is called binding or resolving the
symbolic reference. At load time, for every symbolic reference in every loadfile, the
system finds the program or a library that offers a function or data item having the
same name, and it binds that reference to a corresponding definition.
Figure 1-1 on page 1-2 is an example of how this binding works; while this example is
illustrative, it is not entirely realistic, for instance, in the numbers used for virtual
addresses. The upper portion of this figure shows the situation before the loadfiles are
loaded. A loadfile on the left, called H, which may be a program or a library, contains a
reference to a symbol, Joe. Three libraries are shown on the right; library J is 5000
bytes long; library K is 3000 bytes long; and library L is 4000 bytes long. Lib K contains
a definition of Joe, which has an entry point offset 1300 bytes from the start of that
library.
The lower portion of Figure 1-1 shows the situation after the four code files are loaded
in a process. The loader placed the three libraries contiguously starting at some virtual
address, say, 10000. This means that the definition of Joe is now located at virtual
address 16300; therefore, this is the value of Joe. The loader has resolved, or bound,
the reference in H to Joe by replacing the symbol in H with the value of Joe, namely,
16300.