Building and using Win32 DLLs Dynamic link libraries, Win32 DLLs, Win32 On Win32 platforms, the compiler is capable of both producing and using dynamic link libraries (DLLs) containing ghc-compiled code. This section shows you how to make use of this facility. strip seems not to work reliably on DLLs, so it's probably best not to. Linking with DLLs The default on Win32 platforms is to link applications in such a way that the executables will use the Prelude and system libraries DLLs, rather than contain (large chunks of) them. This is transparent at the command-line, so sh$ cat main.hs module Main where main = putStrLn "hello, world!" sh$ ghc -o main main.hs ghc: module version changed to 1; reason: no old .hi file sh$ strip main.exe sh$ ls -l main.exe -rwxr-xr-x 1 544 everyone 6144 May 3 17:11 main.exe* sh$ ./main hello, world! sh$ will give you a binary as before, but the main.exe generated will use the Prelude and RTS DLLs instead. 6K for a "hello, world" application---not bad, huh? :-) Not linking with DLLs <IndexTerm><Primary>-static option (Win32)</Primary></IndexTerm> If you want to build an executable that doesn't depend on any ghc-compiled DLLs, use the option to link in the code statically. Notice that you cannot mix code that has been compiled with and not, so you have to use the option on all the Haskell modules that make up your application. Creating a DLL Creating a Win32 DLL --mk-dll Sealing up your Haskell library inside a DLL is quite straightforward; compile up the object files that make up the library, and then build the DLL by issuing the following command: ghc --mk-dll -o HSsuper.dll A.o Super.o B.o libmine.a -lgdi32 By feeding the ghc compiler driver the option , 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. To create a `static' DLL, i.e. one that does not depend on the GHC DLLs, compile up your Haskell code using , and write a .def file containing the entry points you want to expose (see for an example). Then link the DLL adding the flag, and , where foo.def is the name of your .def file. A couple of things to notice: Since DLLs correspond to packages (see ) you need to use when compiling modules that belong to a DLL. If you don't, Haskell code that calls entry points in that DLL will do so incorrectly, and a crash will result. By default, the entry points of all the object files will be exported from the DLL when using . Should you want to constrain this, you can specify the module definition file to use on the command line as follows: ghc --mk-dll -o .... -optdll--def -optdllMyDef.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 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_imp.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_imp.a. Additionally, when the compiler driver is linking in non-static mode, it will rewrite occurrence of on the command line to . By doing this for you, switching from non-static to static linking is simply a question of adding to your command line. 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. The dirty details are in the Foreign Function Interface definition, but it can be tricky to work out how to combine this with DLL building, so 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> extern void startupHaskell(int , char** ); static char* args[] = { "ghcDll" }; 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); return TRUE; } return TRUE; } Compile this up: gcc -c dllMain.c Construct the DLL: ghc --mk-dll -o adder.dll adder.o adder_stub.o dllMain.o Start using adder from VBA---here's how I would Declare it: Private Declare 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.