Click above to get retro games delivered to your door ever month!

 Special considerations for CA-Clipper DLL code
------------------------------------------------------------------------------
 If a function name is duplicated in the main EXE and a DLL, then by default
 the one in the main EXE will always be the one executed, even when called
 directly from the DLL. This behaviour is due to the nature of CA-Clipper's
 symbol table, but it can be overriden for dynamically loaded DLLs using the
 BLILIBOVR() function.

 By calling the function BLILIBOVR () with a value of .T. in the main .EXE of
 a CA-Clipper program, functions in dynamically loaded DLLs will override
 functions of the same name in the .EXE file. This also allows ERRORSYS to
 continue after a call to a non-existent function, in order to dynamically
 load a DLL and then attempt to call the function again.

 When a CA-Clipper .DLL dynamically loaded with BLILIBLOD() is freed with
 BLILIBFRE(), CA-Clipper's runtime symbol table handling prevents the
 resources used by the .DLL, such as memory and symbols, from being freed
 until the application finally exits. This is not normally a problem, but
 programs should avoid repeatedly dynamically loading and freeing a
 CA-Clipper .DLL, they should rather leave it loaded for the life of the
 application. A .DLL can still be freed, replaced and then reloaded if
 required, but this should not be done too frequently.

 In order to limit the default size of the main .EXE when using CA-Clipper
 DLLs, none of the extra libraries DBFCDX, DBFNDX, DBFNTX and LLIBG are
 linked in automatically. The file CLDLLEXT.PRG in the CLP subdirectory can
 be modified, compiled and linked to the main EXE to force the code in these
 libraries to be linked in.

 In order to use the CA-Clipper debugger with CA-Clipper .DLLs, at least one
 function in the main EXE must be compiled with debugging information to
 ensure the appropriate debugger functions are linked in.
 To call third party products from a CA-Clipper DLL will require two .OBJ
 files similar to the BLxCLPnn.OBJ files provided with Blinker in order to
 resolve the unresolved externals in the DLL and to force the required
 functions into the main .EXE file.

 The mechanisms which Clip4Win and FiveWin use for dynamically loading C/ASM
 DLLs will not work for CA-Clipper code DLLs because CA-Clipper functions do
 not receive C/ASM parameters and do not return C/ASM values. You must always
 link with the BLcCLPnn.OBJ files and use the BLILIBLOD() function as
 described in the previous section.

 By default, CA-Clipper INIT functions in a statically linked DLL are called
 just before the first call to the DLL is made, rather than when the INIT
 functions in the main .EXE are called. To force them to be executed before
 the main program, simply call a dummy function in the DLL on the first line
 of the main function, or even from an INIT function in the main EXE. This
 will initialise the DLL and therefore call all the INIT functions in the
 DLL.