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

 Linking for DOS extended DLLs
------------------------------------------------------------------------------
 The Blinker DOS extender loads and executes standard Windows 3.x DLLs, so
 DLLs which are to be used with a DOS extended program are usually created in
 exactly the same way as DLLs for Windows. This means that DLLs are usually
 linked using the Windows DLL version of the runtime library for the compiler
 being used, rather than the BLXcccnn library and the standard runtime
 library. The only exceptions to this are low level language DOS extended
 only DLLs, which are detailed below.

 As mentioned previously, a limited subset of the Windows API is provided by
 the Blinker extender in order to allow the language runtime libraries to
 initialise themselves and operate in the same manner as under Windows. This
 means that with intelligent design, i.e. not including calls to functions in
 the DOS extender API or the Windows API, the same DLL can be used by both
 Windows and DOS extended programs, even at the same time.

 For example, a DLL could be created which contained all the code required to
 perform the management of a database file, with a few exported functions to
 pass actual data records back and forth. Both the Windows and the DOS
 versions of the main program, and even multiple different programs, can then
 use this database management DLL with no duplication of code between the
 main programs.

 The \DLL subdirectory of the appropriate language subdirectory of the
 Blinker installation directory contains example programs which demonstrate
 the creation of both a statically linked DLL and a dynamically linked DLL.
 The subdirectory \STC contains all the files to create the statically linked
 example, and the subdirectory \DYN contains the files to create the
 dynamically linked example. The C examples also include a Windows program to
 demonstrate the sharing of the same DLL between a Windows and a DOS program.
 When creating Windows DLLs with a lower level language such as C or Pascal,
 certain sections of the run time library such as the printf() functions are
 not available. To incorporate existing code which uses these DOS-specific
 functions into DLLs, it is possible to create DLLs specifically for DOS
 extended programs. These DOS extended DLLs cannot be shared with Windows
 programs, but they can use all of the DOS run time library functions which
 are not present under Windows. The subdirectory \C\DLL\EXT contains a sample
 program demonstrating this feature.

 Unresolved externals may often occur at link time when creating DLLs from
 existing code, since the code may well reference other code which will now
 reside in other modules or the main .EXE. Export and import definitions must
 be set up for all these unresolved externals in order for the program to
 link and execute successfully. Note that, due to the way Windows DLLs,
 exports and imports are designed, there is no easy way to import functions
 from the main .EXE, but the main .EXE can import from a DLL, and DLLs can
 export from, and import to, other DLLs.

 Creating DLLs with CA-Clipper requires special treatment, since the compiler
 does not directly support Windows and DLLs without extra assistance.
 CA-Clipper programmers should therefore skip over the generic example below
 and refer to the CA-Clipper specific example which follows it.
 In all cases, please refer to the Windows online help file BLINKER.HLP for
 the latest information on creating .DLLs, and for details on how to minimise
 the extra overhead being linked into the main .EXE of a CA-Clipper program.