12.6. Building and using Win32 DLLs
Prev | Chapter 12. Running GHC on Win32 systems | Next

## 12.6. Building and using Win32 DLLs

Making Haskell libraries into DLLs doesn't work on Windows at the moment; we hope to re-instate this facility in the future. Note that building an entire Haskell application as a single DLL is still supported: it's just multi-DLL Haskell programs that don't work. The Windows distribution of GHC contains static libraries only.

### 12.6.1. Creating a DLL

Sealing up your Haskell library inside a DLL is straightforward; compile up the object files that make up the library, and then build the DLL by issuing a command of the form:

    ghc ––shared -o foo.dll bar.o baz.o wibble.a -lfooble

By feeding the ghc compiler driver the option `––shared`, it will build a DLL rather than produce an executable. The DLL will consist of all the object files and archives given on the command line.

A couple of things to notice:

- By default, the entry points of all the object files will be exported from the DLL when using `––shared`. Should you want to constrain this, you can specify the module definition file to use on the command line as follows:

      ghc ––shared -o .... MyDef.def

  See Microsoft documentation for details, but a module definition file simply lists what entry points you want to export. Here's one that's suitable when building a Haskell COM server DLL:

      EXPORTS
       DllCanUnloadNow     = DllCanUnloadNow@0
       DllGetClassObject   = DllGetClassObject@12
       DllRegisterServer   = DllRegisterServer@0
       DllUnregisterServer = DllUnregisterServer@0

- In addition to creating a DLL, the `––shared` option also creates an import library. The import library name is derived from the name of the DLL, as follows:

      DLL: HScool.dll  ==> import lib: libHScool.dll.a

  The naming scheme may look a bit weird, but it has the purpose of allowing the co-existence of import libraries with ordinary static libraries (e.g., `libHSfoo.a` and `libHSfoo.dll.a`. Additionally, when the compiler driver is linking in non-static mode, it will rewrite occurrence of `-lHSfoo` on the command line to `-lHSfoo.dll`. By doing this for you, switching from non-static to static linking is simply a question of adding `-static` to your command line.

### 12.6.2. Making DLLs to be called from other languages

If you want to package up Haskell code to be called from other languages, such as Visual Basic or C++, there are some extra things it is useful to know. This is a special case of Section 9.2.1.2, “Making a Haskell library that can be called from foreign code”; we'll deal with the DLL-specific issues that arise below. Here's an example:

- Use `foreign export` declarations to export the Haskell functions you want to call from the outside. For example,

      module Adder where

      adder :: Int -> Int -> IO Int  –– gratuitous use of IO
      adder x y = return (x+y)

      foreign export stdcall adder :: Int -> Int -> IO Int

- Compile it up:

      ghc -c adder.hs -fglasgow-exts

  This will produce two files, adder.o and adder_stub.o

- compile up a `DllMain()` that starts up the Haskell RTS-––a possible implementation is:

      #include <windows.h>
      #include <Rts.h>

      extern void __stginit_Adder(void);

      static char* args[] = { "ghcDll", NULL };
                             /* N.B. argv arrays must end with NULL */
      BOOL
      STDCALL
      DllMain
         ( HANDLE hModule
         , DWORD reason
         , void* reserved
         )
      {
        if (reason == DLL_PROCESS_ATTACH) {
            /* By now, the RTS DLL should have been hoisted in, but we need to start it up. */
            startupHaskell(1, args, __stginit_Adder);
            return TRUE;
        }
        return TRUE;
      }

  Here, `Adder` is the name of the root module in the module tree (as mentioned above, there must be a single root module, and hence a single module tree in the DLL). Compile this up:

      ghc -c dllMain.c

- Construct the DLL:

      ghc ––shared -o adder.dll adder.o adder_stub.o dllMain.o

- Start using `adder` from VBA-––here's how I would `Declare` it:

      Private Declare Function adder Lib "adder.dll" Alias "adder@8"
            (ByVal x As Long, ByVal y As Long) As Long

  Since this Haskell DLL depends on a couple of the DLLs that come with GHC, make sure that they are in scope/visible.

  Building statically linked DLLs is the same as in the previous section: it suffices to add `-static` to the commands used to compile up the Haskell source and build the DLL.

### 12.6.3. Beware of DllMain()!

The body of a `DllMain()` function is an extremely dangerous place! This is because the order in which DLLs are unloaded when a process is terminating is unspecified. This means that the `DllMain()` for your DLL may be called when other DLLs containing functions that you call when de-initializing your DLL have already been unloaded. In other words, you can't put shutdown code inside `DllMain()`, unless your shutdown code only requires use of certain functions which are guaranteed to be available (see the Platform SDK docs for more info).

In particular, if you are writing a DLL that's statically linked with Haskell, it is not safe to call `hs_exit()` from `DllMain()`, since `hs_exit()` may make use of other DLLs (see also Section 9.2.1.3, “On the use of `hs_exit()`”). What's more, if you wait until program shutdown to execute your deinitialisation code, Windows will have terminated all the threads in your program except the one calling `DllMain()`, which can cause even more problems.

A solution is to always export `Begin()` and `End()` functions from your DLL, and call these from the application that uses the DLL, so that you can be sure that all DLLs needed by any shutdown code in your End() function are available when it is called.

The following example is untested but illustrates the idea (please let us know if you find problems with this example or have a better one). Suppose we have a DLL called Lewis which makes use of 2 Haskell modules `Bar` and `Zap`, where `Bar` imports `Zap` and is therefore the root module in the sense of Section 9.2.1.1, “Using your own `main()`”. Then the main C++ unit for the DLL would look something like:

     // Lewis.cpp -- compiled using GCC
     #include <Windows.h>
     #include "HsFFI.h"

     #define __LEWIS_DLL_EXPORT
     #include "Lewis.h"

     #include "Bar_stub.h"  // generated by GHC
     #include "Zap_stub.h"

     BOOL APIENTRY DllMain( HANDLE hModule,
                            DWORD  ul_reason_for_call,
                            LPVOID lpReserved
                           ){
       return TRUE;
     }

     extern "C"{

     LEWIS_API HsBool lewis_Begin(){
       int argc = ...
       char *argv[] = ...

       // Initialize Haskell runtime
       hs_init(&argc, &argv);

       // Tell Haskell about all root modules
       hs_add_root(__stginit_Bar);

       // do any other initialization here and
       // return false if there was a problem
       return HS_BOOL_TRUE;
     }

     LEWIS_API void lewis_End(){
       hs_exit();
     }

     LEWIS_API HsInt lewis_Test(HsInt x){
       // use Haskell functions exported by
       // modules Bar and/or Zap

       return ...
     }

     } // extern "C"

    and some application which used the functions in the DLL would have a main() function like:

     // MyApp.cpp
     #include "stdafx.h"
     #include "Lewis.h"

     int main(int argc, char *argv[]){
       if (lewis_Begin()){
          // can now safely call other functions
          // exported by Lewis DLL

       }
       lewis_End();
       return 0;
     }

`Lewis.h` would have to have some appropriate `#ifndef` to ensure that the Haskell FFI types were defined for external users of the DLL (who wouldn't necessarily have GHC installed and therefore wouldn't have the include files like `HsFFI.h` etc).

Prev | Up | Next
12.5. Using GHC (and other GHC-compiled executables) with cygwin | Home | Chapter 13. Known bugs and infelicities