Professional Documents
Culture Documents
Calling External DLLs From Delphi
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.
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
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."
Static Imports
In static imports the external directive replaces the complete implementation of the called
functions and procedures.
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.
In Delphi 32-bit you additionally specify the parameter passing convention, e.g.:
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.