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 illustrated here:
slink
$ lo file1
$ lo file2
$ lo tpgraph.dll
$ file
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.