DLL action Blocks and DLLs
The DLL-call elementary blocks are used to call functions inside a DLL ("Dynamic Link Library"). In the Unix world, these are also called "Shared Libraries" or "Shared Objects".
DLLs are files which contain compiled code, typically written in programming languages like C or C++ (but not required to be). To call a function from a DLL, you do not need to know, in which language a DLL's functions were originally written. However, you need to know the name of the function, the number and types of arguments and the return type. On 32bit Windows systems, you also need to know the call-convention (API-call or C-call).
And of course, the location and name of the DLL, in which the desired function is located.
This last item can become a problem, because both the suffixes and the basename of DLL's might be different between operating systems.
For example, the Unix convention is to name them "
XXX.so", whereas under Windows, they are named "
XXX.dll". Sometimes DLLs have different names depending on the wordlength; so a library might be named "
XXX.dll" on a 32bit system and "
XXX_64.dll" on a 64bit system.
Expecco will itself add the appropriate suffix, if the name in the DLL-action definition has none. Therefore, for portability of your test suites between Windows and Linux (if ever desired), you should only specify the basename of the DLL in the action block, and let expecco fill in the appropriate suffix.
DLL Basename Mapping
If the basename (that is the name without path-prefix and filename-suffix) of the Unix DLL is the same as the basename of the Windows DLL, your test suite using DLL action blocks should run unchanged on both systems.
However, if they are different, you need a mapping mechanism, which dynamically specifies a replacement name for a given DLL, and this replacement depends on the architecture (i.e. Linux vs. Windows32 vs. Windows64) or on the installation path in the machine on which you are executing expecco. Therefore, this mapping is kept in your personal preferences, not in the test suite (if required, you can use multiple such settings files and specify the one to use on the command line).
The replacement given in the DLL name mapping can be either another basename, a basename-plus-suffix or a complete relative or absolute path to the target DLL.
A concrete example for this is the autoit DLL, which is named "
autoItX3.dll" under win32, but "
autoItX3_64.dll" under win64. Here, you would specify "
autoItX3" in the DLL action block, and only provide the mapping "
autoItX3" -> "
autoItX3_64" if running on a win64 system.
Another use of the DLL name mapping scheme is to run the same test suite multiple times, using different versions of a DLL (stable, developer, debug vs. production etc.).
Assuming your DLL is named "
myFuncs.dll", and two versions of it are present in two different folders named "
c:\...\folder_v1\myFuncs.dll" and "
c:\...\folder_v\myFuncs.dll", then you should specify "
myFuncs" in the DLL action step, and provide mappings to either directory, depending on which version you want to use.