X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fwin32-dlls.xml;h=ad1c788adac17ca762893da29092c20ffb5639fc;hb=1bf40a4b38180b8b1c1bdaf4919bc327d5b27abe;hp=8cd73ec5a986cd26dbec8108e6d6c90e5c9e555e;hpb=035890658d56bc5233f73b311a1bd08c41752d33;p=ghc-hetmet.git

diff --git a/docs/users_guide/win32-dlls.xml b/docs/users_guide/win32-dlls.xml
index 8cd73ec..ad1c788 100644
--- a/docs/users_guide/win32-dlls.xml
+++ b/docs/users_guide/win32-dlls.xml
@@ -23,7 +23,7 @@ interpret the filename as two, "c:\\Program" and "Files\\Haskell\\Project.hs".
 <!-- not clear whether there are current editions of Win32 OSes that
      doesn't do this by default.
 
-<para> Solution: don't use "Open With...", avoid spaces in file names, 
+<para> Solution: don't use "Open With...", avoid spaces in file names,
 or fiddle with the appropriate registry setting:
 <programlisting>
   HKEY_CLASSES_ROOT\Unknown\shell\openas\command
@@ -71,7 +71,7 @@ Notice how the "%1" argument is quoted (or not).
   <para>This problem doesn't just affect GHCi, it affects any
   GHC-compiled program that wants to catch console events.  See the
   <ulink
-  url="../libraries/base/GHC-ConsoleHandler.html">GHC.ConsoleHandler</ulink>
+  url="&libraryBaseLocation;/GHC-ConsoleHandler.html">GHC.ConsoleHandler</ulink>
   module.</para>
 </sect1>
 
@@ -152,7 +152,7 @@ cygwin's bash), but what matters here is that - just like any other
 normal windows program - neither GHC nor the executables it produces
 are aware of cygwin's pretended unix hierarchy. GHC will happily
 accept either '/' or '\' as path separators, but it won't know where
-to find <filename>/home/joe/Main.hs</filename> or <filename>/bin/bash</filename> 
+to find <filename>/home/joe/Main.hs</filename> or <filename>/bin/bash</filename>
 or the like. This causes all
 kinds of fun when GHC is used from within cygwin's bash, or in
 make-sessions running under cygwin.
@@ -162,9 +162,9 @@ make-sessions running under cygwin.
 <sect2><title>Things to do</title>
 <itemizedlist>
 <listitem>
-<para> Don't use absolute paths in make, configure &amp; co if there is any chance 
+<para> Don't use absolute paths in make, configure &amp; co if there is any chance
   that those might be passed to GHC (or to GHC-compiled programs). Relative
-  paths are fine because cygwin tools are happy with them and GHC accepts 
+  paths are fine because cygwin tools are happy with them and GHC accepts
   '/' as path-separator. And relative paths don't depend on where cygwin's
   root directory is located, or on which partition or network drive your source
   tree happens to reside, as long as you 'cd' there first.
@@ -175,25 +175,25 @@ make-sessions running under cygwin.
   <literal>ROOT=`pwd`</literal> in makefile hierarchies or configure scripts), cygwin provides
   a tool called <command>cygpath</command> that can convert cygwin's unix-style paths to their
   actual windows-style counterparts. Many cygwin tools actually accept
-  absolute windows-style paths (remember, though, that you either need 
-  to escape '\' or convert '\' to '/'), so you should be fine just using those 
-  everywhere. If you need to use tools that do some kind of path-mangling 
-  that depends on unix-style paths (one fun example is trying to interpret ':' 
-  as a separator in path lists..), you can still try to convert paths using 
+  absolute windows-style paths (remember, though, that you either need
+  to escape '\' or convert '\' to '/'), so you should be fine just using those
+  everywhere. If you need to use tools that do some kind of path-mangling
+  that depends on unix-style paths (one fun example is trying to interpret ':'
+  as a separator in path lists..), you can still try to convert paths using
   <command>cygpath</command> just before they are passed to GHC and friends.
 </para></listitem>
-  
+
 <listitem>
 <para> If you don't have <command>cygpath</command>, you probably don't have cygwin and hence
   no problems with it... unless you want to write one build process for several
   platforms. Again, relative paths are your friend, but if you have to use
   absolute paths, and don't want to use different tools on different platforms,
   you can simply write a short Haskell program to print the current directory
-   (thanks to George Russell for this idea): compiled with GHC, this will give 
-  you the view of the file system that GHC depends on (which will differ 
+   (thanks to George Russell for this idea): compiled with GHC, this will give
+  you the view of the file system that GHC depends on (which will differ
   depending on whether GHC is compiled with cygwin's gcc or mingw's
-  gcc or on a real unix system..) - that little program can also deal with 
-  escaping '\' in paths. Apart from the banner and the startup time, 
+  gcc or on a real unix system..) - that little program can also deal with
+  escaping '\' in paths. Apart from the banner and the startup time,
   something like this would also do:
 <programlisting>
   $ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci
@@ -209,15 +209,6 @@ make-sessions running under cygwin.
 </title>
 
 <para>
-<emphasis>Making Haskell libraries into DLLs doesn't work on Windows at the
-moment; we hope to re-instate this facility in the future
-(see <xref linkend="using-shared-libs"/>).  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.</emphasis></para>
-
-<!--
-<para>
 <indexterm><primary>Dynamic link libraries, Win32</primary></indexterm>
 <indexterm><primary>DLLs, Win32</primary></indexterm>
 On Win32 platforms, the compiler is capable of both producing and using
@@ -226,6 +217,33 @@ section shows you how to make use of this facility.
 </para>
 
 <para>
+There are two distinct ways in which DLLs can be used:
+<itemizedlist>
+  <listitem>
+    <para>
+      You can turn each Haskell package into a DLL, so that multiple
+      Haskell executables using the same packages can share the DLL files.
+      (As opposed to linking the libraries statically, which in effect
+      creates a new copy of the RTS and all libraries for each executable
+      produced.)
+    </para>
+    <para>
+      That is the same as the dynamic linking on other platforms, and it
+      is described in <xref linkend="using-shared-libs"/>.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+      You can package up a complete Haskell program as a DLL, to be called
+      by some external (usually non-Haskell) program. This is usually used
+      to implement plugins and the like, and is described below.
+    </para>
+  </listitem>
+</itemizedlist>
+</para>
+
+<!--
+<para>
 Until recently, <command>strip</command> didn't work reliably on DLLs, so you
 should test your version with care, or make sure you have the latest
 binutils. Unfortunately, we don't know exactly which version of binutils
@@ -240,7 +258,7 @@ cured the problem (it was supposedly fixed some years ago).
 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 
+command-line, so
 </para>
 
 <para>
@@ -255,7 +273,7 @@ sh$ ls -l main.exe
 -rwxr-xr-x   1 544      everyone     4608 May  3 17:11 main.exe*
 sh$ ./main
 hello, world!
-sh$ 
+sh$
 </screen>
 </para>
 
@@ -403,227 +421,147 @@ non-static to static linking is simply a question of adding
 <title>Making DLLs to be called from other languages</title>
 
 <para>
-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 <xref linkend="ffi-library" />; we'll deal with
-          the DLL-specific issues that arise below.  Here's an example:
+  This section describes how to create DLLs to be called from other languages,
+  such as Visual Basic or C++. This is a special case of
+  <xref linkend="ffi-library" />; we'll deal with the DLL-specific issues that
+  arise below. Here's an example:
 </para>
-
-<itemizedlist>
-
-<listitem>
 <para>
-Use <literal>foreign export</literal> declarations to export the Haskell
-functions you want to call from the outside. For example,
-
+  Use foreign export declarations to export the Haskell functions you want to
+  call from the outside. For example:
+</para>
 <programlisting>
+-- Adder.hs
+{-# LANGUAGE ForeignFunctionInterface #-}
 module Adder where
 
-adder :: Int -> Int -> IO Int  &ndash;&ndash; gratuitous use of IO
+adder :: Int -> Int -> IO Int  -- gratuitous use of IO
 adder x y = return (x+y)
 
 foreign export stdcall adder :: Int -> Int -> IO Int
 </programlisting>
-</para>
-</listitem>
-
-<listitem>
 <para>
-Compile it up:
-
-<screen>
-ghc -c adder.hs -fglasgow-exts
-</screen>
-  
-This will produce two files, adder.o and adder_stub.o
+  Add some helper code that starts up and shuts down the Haskell RTS:
 </para>
-</listitem>
-
-<listitem>
-<para>
-compile up a <function>DllMain()</function> that starts up the Haskell
-RTS-&ndash;&ndash;a possible implementation is:
-
 <programlisting>
-#include &lt;windows.h&gt;
+// StartEnd.c
 #include &lt;Rts.h&gt;
 
-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
-   )
+void HsStart()
 {
-  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;
-}
-</programlisting>
-
-Here, <literal>Adder</literal> 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:
+   int argc = 1;
+   char* argv[] = {"ghcDll", NULL}; // argv must end with NULL
 
-<screen>
-ghc -c dllMain.c
-</screen>
-</para>
-</listitem>
+   // Initialize Haskell runtime
+   char** args = argv;
+   hs_init(&amp;argc, &amp;args);
+}
 
-<listitem>
+void HsEnd()
+{
+   hs_exit();
+}
+</programlisting>
 <para>
-Construct the DLL:
-
+  Here, <literal>Adder</literal> 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 everything up:
+</para>
 <screen>
-ghc &ndash;shared -o adder.dll adder.o adder_stub.o dllMain.o
+ghc -c Adder.hs
+ghc -c StartEnd.c
+ghc -shared -o Adder.dll Adder.o Adder_stub.o StartEnd.o
 </screen>
-
-</para>
-</listitem>
-
-<listitem>
 <para>
-Start using <function>adder</function> from VBA-&ndash;&ndash;here's how I would
-<constant>Declare</constant> it:
-
-<programlisting>
-Private Declare Function adder Lib "adder.dll" Alias "adder@8"
-      (ByVal x As Long, ByVal y As Long) As Long
-</programlisting>
-
-Since this Haskell DLL depends on a couple of the DLLs that come with GHC,
-make sure that they are in scope/visible.
+  Now the file <filename>Adder.dll</filename> can be used from other
+  programming languages. Before calling any functions in Adder it is necessary
+  to call <literal>HsStart</literal>, and at the very end call
+  <literal>HsEnd</literal>.
 </para>
-
 <para>
-Building statically linked DLLs is the same as in the previous section: it
-suffices to add <option>-static</option> to the commands used to compile up
-the Haskell source and build the DLL.
+  <emphasis>Warning:</emphasis> It may appear tempting to use
+  <literal>DllMain</literal> to call
+  <literal>hs_init</literal>/<literal>hs_exit</literal>, but this won't work
+  (particularly if you compile with <literal>-threaded</literal>). There are
+  severe restrictions on which actions can be performed during
+  <literal>DllMain</literal>, and <literal>hs_init</literal> violates these
+  restrictions, which can lead to your dll freezing during startup (see
+  <ulink url="http://hackage.haskell.org/trac/ghc/ticket/3605">bug
+  #3605</ulink>).
 </para>
 
-</listitem>
-
-</itemizedlist>
-
-</sect2>
-
-<sect2>
-<title>Beware of DllMain()!</title>
-
-<para>The body of a <literal>DllMain()</literal> 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 <literal>DllMain()</literal> 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
-<literal>DllMain()</literal>, unless your shutdown code only requires use of certain
-functions which are guaranteed to be available (see the Platform SDK
-docs for more info).</para>
-
-<para>In particular, if you are writing a DLL that's statically
-linked with Haskell, it is not safe to call
-<literal>hs_exit()</literal> from <literal>DllMain()</literal>, since
-<literal>hs_exit()</literal> may make use of other DLLs (see also <xref
-          linkend="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
-<literal>DllMain()</literal>, which can cause even more
-problems.</para>
-
-<para>A solution is to always export <literal>Begin()</literal> and <literal>End()</literal> 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.</para>
-
-<para>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 <literal>Bar</literal> and <literal>Zap</literal>,
-where <literal>Bar</literal> imports <literal>Zap</literal> and is
-therefore the root module in the sense of <xref
-linkend="using-own-main" />. Then the main C++ unit for the DLL would
-look something like:</para>
+<sect3 id="win32-dlls-vba">
+<title>Using from VBA</title>
 
+<para>
+  An example of using <filename>Adder.dll</filename> from VBA is:
+</para>
 <programlisting>
- // Lewis.cpp -- compiled using GCC
- #include &lt;Windows.h&gt;
- #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(&amp;argc, &amp;argv);
-
-   // Tell Haskell about all root modules
-   hs_add_root(__stginit_Bar);
+Private Declare Function Adder Lib "Adder.dll" Alias "adder@8" _
+      (ByVal x As Long, ByVal y As Long) As Long
 
-   // do any other initialization here and
-   // return false if there was a problem
-   return HS_BOOL_TRUE;
- }
+Private Declare Sub HsStart Lib "Adder.dll" ()
+Private Declare Sub HsEnd Lib "Adder.dll" ()
 
- LEWIS_API void lewis_End(){
-   hs_exit();
- }
+Private Sub Document_Close()
+HsEnd
+End Sub
 
- LEWIS_API HsInt lewis_Test(HsInt x){
-   // use Haskell functions exported by
-   // modules Bar and/or Zap
+Private Sub Document_Open()
+HsStart
+End Sub
 
-   return ...
- }
-
- } // extern "C"
+Public Sub Test()
+MsgBox "12 + 5 = " &amp; Adder(12, 5)
+End Sub
+</programlisting>
+<para>
+  This example uses the
+  <literal>Document_Open</literal>/<literal>Close</literal> functions of
+  Microsoft Word, but provided <literal>HsStart</literal> is called before the
+  first function, and <literal>HsEnd</literal> after the last, then it will
+  work fine.
+</para>
+</sect3>
 
-and some application which used the functions in the DLL would have a main() function like:
+<sect3 id="win32-dlls-c++">
+<title>Using from C++</title>
 
- // MyApp.cpp
- #include "stdafx.h"
- #include "Lewis.h"
+<para>
+  An example of using <filename>Adder.dll</filename> from C++ is:
+</para>
 
- int main(int argc, char *argv[]){
-   if (lewis_Begin()){
-      // can now safely call other functions
-      // exported by Lewis DLL
+<programlisting>
+// Tester.cpp
+#include "HsFFI.h"
+#include "Adder_stub.h"
+#include &lt;stdio.h&gt;
+
+extern "C" {
+    void HsStart();
+    void HsEnd();
+}
 
-   }
-   lewis_End();
-   return 0;
- }
+int main()
+{
+    HsStart();
+    // can now safely call functions from the DLL
+    printf("12 + 5 = %i\n", adder(12,5))    ;
+    HsEnd();
+    return 0;
+}
 </programlisting>
-
-<para><literal>Lewis.h</literal> would have to have some appropriate <literal>#ifndef</literal> 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 <literal>HsFFI.h</literal> etc). 
+<para>
+  This can be compiled and run with:
 </para>
+<screen>
+$ ghc -o tester Tester.cpp Adder.dll.a
+$ tester
+12 + 5 = 17
+</screen>
+
+</sect3>
+
 </sect2>
 
 </sect1>
@@ -631,7 +569,6 @@ the include files like <literal>HsFFI.h</literal> etc).
 
 <!-- Emacs stuff:
      ;;; Local Variables: ***
-     ;;; mode: xml ***
      ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***
      ;;; End: ***
  -->