Calling External DLLs from Delphi

Borland's Delphi allows developers an extremely easy and efficient method to create
object-oriented, event-controlled Windows applications with a minimum of coding.
Therefore many programmers have switched to Delphi as their primary development
platform. Typically Delphi makes Windows programming easier than other visual
development platforms, while still allowing full access to all Windows events and direct
source code. Delphi's component-based concept relieves the developer from much of the
burden of creating a user interface and reacting to Windows events.

This article shows how to write NetWare applications with 16-bit and 32-bit Delphi.

Calling external DLLs gives the developer several benefits:

 It reduces the size of the executable program

 It allows for shared access of multiple applications to the same shared code
 It allows access to functionality of applications provided by 3rd-party vendors
without requiring access to their source code.

To call DLL functions and procedures you will need to know the exact names of the
functions as well as the number and parameters used by the function. If the manufacturers
of the DLLs allow for third-party applications calling into their DLLs's routines, they will
have to provide the applications with information on how to call into the DLLs.

This typically is done by either providing written documentation like in the function
declarations of the online WinHelp or Dynatext documentation for the NetWare SDKs, or
by providing compiler-specific libraries: C programmers might find header files or
libraries (e.g., NetWin16.LIB or NWIPXSPX.LIB), while Pascal programmers might see
include files or units (e.g., NetWin16.DCU or NWQMS.INC).

If the interface to the DLL is provided by libraries or units, the developer does not have
to convert the written documentation into a program interface, but still has to follow the
calling conventions as documented. If, however, the libraries are not or only partially
provided, the interface has to be written by the developer. This might be partially the case
for some Delphi applications; this will also apply to Visual Basic or MS Access
developers who want to access NetWare DLLs.

You do not have to specify or know about the function algorithms, but only the format of
the input and output parameters. The implementation of the used functions can be treated
as black box. You do not even have to care about the programming language that has
been used to write the DLLs: While most of the existing DLLs have been written in C,
they may be accessed form other programming platforms like Delphi, Visual Basic,
Paradox, or MS Access.
You should be aware, however, that while DLLs may contain function/procedure
declarations as well as definitions of records/structures or types, they cannot export
global variables.

The following paragraphs show how to write interface routines to NetWare DLLs in
Delphi.

Basically there are two methods for accessing functions stored in a DLL:

 Dynamic Imports: GetProcAddress and LoadLibrary

 Static Imports: using "external" declarations

Dynamic Imports

The Windows function LoadLibrary allows your program to specify the name of external
DLLs at run time, and the function GetProcAddress will determine the address of the
DLL functions that you need. The combination of these two functions allows for dynamic
access to DLLs and is frequently referred to as "dynamic import" or "explicit loading."

Using GetProcAddress and LoadLibrary (the two must be used in conjunction) to

import a DLL gives your program control over what DLL file is actually loaded. With
dynamic imports your application may continue to run, even if LoadLibrary fails to locate
the DLL. Your application might, for example, check for the existence of NetWare DLLs
and, if the access fails, continue with other program modules. If the application finds the
function in the requested DLL it can directly call into the function address.

Static Imports

In static imports the external directive replaces the complete implementation of the called
functions and procedures.

Example: Function NWCallsInit; external "NWCalls";

Declarations of DLL functions as "External" is most appropriate if you rely on the

existence of the DLL function and your program should only execute if the DLL is
accessible. In the NetWare programming environment it would frequently not make sense
to run NetWare-specific applications if the client station does not have the NetWare client
software with its DLLs installed.

The "external" declaration to perform a static DLL import causes the DLL to be loaded as
your program starts executing. You cannot change the name of the DLL at run time, and
your program will fail if it specifies a DLL that isn't available at run time. During
compilation the compiler does not look for the DLL, so it need not be present.

"External" declarations typically import routines by name and/or by number, e.g.:

By Name: function NWCallsInit; external "CALWIN16";
By number: function NWCallsInit; external "CALWIN16" index 377;

In Delphi 32-bit you additionally specify the parameter passing convention, e.g.:

By number: function NWCallsInit; stdcall; external "CALWIN16" index 377;

When your application accesses a function declared by name, Windows will browse the
internal name table of the specified DLL and locate the address of the requested function
at run time as you call it.

If you specify the ordinal number while importing a DLL routine, Windows will not have
to scan the DLL name table. The access time to the function will be slightly reduced and
general performance increased. Therefore you should specify the ordinal number if
available. You may get the number either from the documentation, or by using tools to
analyze DLLs (e.g., EXEHDR.EXE) that are available from compiler manufacturers or third
parties.