Direct linking with DLLs
SLINK allows direct linking with one or more DLLs without the need to use import
libraries (see section 5). It will generate its own import library for a DLL
based upon the information contained in the DLL's export table. If you produce
a DLL, you have the choice whether or not to produce an import library.
Sometimes, as is the case with SALFLIBC.LIB (or SALFLIBC.DLL), the library is a
combined import and standard library. In this case, the functions in the
standard library part are not contained within the DLL, so directly linking
with the DLL will not achieve the same result as linking with the .LIB file.
This means that you should not link directly with SALFLIBC.DLL � always use the
.LIB file i.e. SALFLIBC.LIB.
For example, suppose that some of the functions you need are provided inside a
DLL called TPGRAPH.DLL. In this case the linker would not import the runtime
code for the functions from the DLL even though the DLL must be loaded as
$ lo file1
$ lo file2
$ lo tpgraph.dll
TPGRAPH.DLL is merely used to acquire the information that is necessary for the
executable to import functions from TPGRAPH.DLL at run time.
rlo can be used instead of lo with the result that, when the resulting application is
executed, the DLL is not required to be accessible when the application is loaded. The binding is delayed until
the first call to a routine in the DLL. In other words, the executable can be run without the DLL being present
and a runtime failure will not occur unless and until a call is made to a routine in the DLL.
SLINK will not search the system path for the DLL. You should specify the full
path name on the load command.