<chapter id="win32">
<title>Running GHC on Win32 systems</title>
-<sect1>
+<sect1 id="ghc-windows">
<title>
-Starting GHC on Win32 platforms</title>
+Starting GHC on Windows platforms</title>
<para>
The installer that installs GHC on Win32 also sets up the file-suffix associations
<!-- 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
</sect1>
-<sect1>
+<sect1 id="ghci-windows">
+<title>Running GHCi on Windows</title>
+
+ <para>We recommend running GHCi in a standard Windows console:
+ select the <literal>GHCi</literal> option from the start menu item
+ added by the GHC installer, or use
+ <literal>Start->Run->cmd</literal> to get a Windows console and
+ invoke <literal>ghci</literal> from there (as long as it's in your
+ <literal>PATH</literal>).</para>
+
+ <para>If you run GHCi in a Cygwin or MSYS shell, then the Control-C
+ behaviour is adversely affected. In one of these environments you
+ should use the <literal>ghcii.sh</literal> script to start GHCi,
+ otherwise when you hit Control-C you'll be returned to the shell
+ prompt but the GHCi process will still be running. However, even
+ using the <literal>ghcii.sh</literal> script, if you hit Control-C
+ then the GHCi process will be killed immediately, rather than
+ letting you interrupt a running program inside GHCi as it should.
+ This problem is caused by the fact that the Cygwin and MSYS shell
+ environments don't pass Control-C events to non-Cygwin child
+ processes, because in order to do that there needs to be a Windows
+ console.</para>
+
+ <para>There's an exception: you can use a Cygwin shell if the
+ <literal>CYGWIN</literal> environment variable does
+ <emphasis>not</emphasis> contain <literal>tty</literal>. In this
+ mode, the Cygwin shell behaves like a Windows console shell and
+ console events are propagated to child processes. Note that the
+ <literal>CYGWIN</literal> environment variable must be set
+ <emphasis>before</emphasis> starting the Cygwin shell; changing it
+ afterwards has no effect on the shell.</para>
+
+ <para>This problem doesn't just affect GHCi, it affects any
+ GHC-compiled program that wants to catch console events. See the
+ <ulink
+ url="&libraryBaseLocation;/GHC-ConsoleHandler.html">GHC.ConsoleHandler</ulink>
+ module.</para>
+</sect1>
+
+<sect1 id="terminal-interaction">
<title>
Interacting with the terminal</title>
</sect1>
-<sect1>
+<sect1 id="library-differences">
<title>
Differences in library behaviour </title>
</para>
</sect1>
-<sect1>
+<sect1 id="ghci-cygwin">
<title>
Using GHC (and other GHC-compiled executables) with cygwin</title>
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.
<sect2><title>Things to do</title>
<itemizedlist>
<listitem>
-<para> Don't use absolute paths in make, configure & co if there is any chance
+<para> Don't use absolute paths in make, configure & 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.
<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
</title>
<para>
-<emphasis>Making Haskell libraries into DLLs doesn't work on Windows at the
-moment; however, all the machinery is
-still there. If you're interested, contact the GHC team. 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
</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
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>
-rwxr-xr-x 1 544 everyone 4608 May 3 17:11 main.exe*
sh$ ./main
hello, world!
-sh$
+sh$
</screen>
</para>
<para>
<indexterm><primary>Creating a Win32 DLL</primary></indexterm>
-<indexterm><primary>––mk-dll</primary></indexterm>
+<indexterm><primary>–shared</primary></indexterm>
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:
<para>
<screen>
-ghc ––mk-dll -o foo.dll bar.o baz.o wibble.a -lfooble
+ghc –shared -o foo.dll bar.o baz.o wibble.a -lfooble
</screen>
</para>
<para>
-By feeding the ghc compiler driver the option <option>––mk-dll</option>, it
+By feeding the ghc compiler driver the option <option>–shared</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.
<listitem>
<para>
By default, the entry points of all the object files will be exported from
-the DLL when using <option>––mk-dll</option>. Should you want to constrain
+the DLL when using <option>–shared</option>. Should you want to constrain
this, you can specify the <emphasis>module definition file</emphasis> to use
on the command line as follows:
<screen>
-ghc ––mk-dll -o .... -optdll––def -optdllMyDef.def
+ghc –shared -o .... MyDef.def
</screen>
See Microsoft documentation for details, but a module definition file
<listitem>
<para>
-In addition to creating a DLL, the <option>––mk-dll</option> option also
+In addition to creating a DLL, the <option>–shared</option> option also
creates an import library. The import library name is derived from the
name of the DLL, as follows:
<programlisting>
-DLL: HScool.dll ==> import lib: libHScool_imp.a
+DLL: HScool.dll ==> import lib: libHScool.dll.a
</programlisting>
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.,
<filename>libHSfoo.a</filename> and
-<filename>libHSfoo_imp.a</filename>.
+<filename>libHSfoo.dll.a</filename>.
Additionally, when the compiler driver is linking in non-static mode, it
will rewrite occurrence of <option>-lHSfoo</option> on the command line to
-<option>-lHSfoo_imp</option>. By doing this for you, switching from
+<option>-lHSfoo.dll</option>. By doing this for you, switching from
non-static to static linking is simply a question of adding
<option>-static</option> to your command line.
<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. The dirty details are in the <emphasis>Foreign Function
-Interface</emphasis> definition, but it can be tricky to work out how to
-combine this with DLL building, so 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 –– 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-––a possible implementation is:
-
<programlisting>
-#include <windows.h>
+// StartEnd.c
#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
- )
+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).
+ int argc = 1;
+ char* argv[] = {"ghcDll", NULL}; // argv must end with NULL
-Compile this up:
+ // Initialize Haskell runtime
+ char** args = argv;
+ hs_init(&argc, &args);
+}
+void HsEnd()
+{
+ hs_exit();
+}
+</programlisting>
+<para>
+ 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 -c dllMain.c
+ghc -c Adder.hs
+ghc -c StartEnd.c
+ghc -shared -o Adder.dll Adder.o Adder_stub.o StartEnd.o
</screen>
+<para>
+ 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>
-</listitem>
-
-<listitem>
<para>
-Construct the DLL:
-
-<screen>
-ghc ––mk-dll -o adder.dll adder.o adder_stub.o dllMain.o
-</screen>
-
+ <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>
-<listitem>
-<para>
-Start using <function>adder</function> from VBA-––here's how I would
-<constant>Declare</constant> it:
+<sect3 id="win32-dlls-vba">
+<title>Using from VBA</title>
+<para>
+ An example of using <filename>Adder.dll</filename> from VBA is:
+</para>
<programlisting>
-Private Declare Function adder Lib "adder.dll" Alias "adder@8"
+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.
+Private Declare Sub HsStart Lib "Adder.dll" ()
+Private Declare Sub HsEnd Lib "Adder.dll" ()
+
+Private Sub Document_Close()
+HsEnd
+End Sub
+
+Private Sub Document_Open()
+HsStart
+End Sub
+
+Public Sub Test()
+MsgBox "12 + 5 = " & 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>
+
+<sect3 id="win32-dlls-c++">
+<title>Using from C++</title>
<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.
+ An example of using <filename>Adder.dll</filename> from C++ is:
</para>
-</listitem>
+<programlisting>
+// Tester.cpp
+#include "HsFFI.h"
+#include "Adder_stub.h"
+#include <stdio.h>
+
+extern "C" {
+ void HsStart();
+ void HsEnd();
+}
-</itemizedlist>
+int main()
+{
+ HsStart();
+ // can now safely call functions from the DLL
+ printf("12 + 5 = %i\n", adder(12,5)) ;
+ HsEnd();
+ return 0;
+}
+</programlisting>
+<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>
<!-- Emacs stuff:
;;; Local Variables: ***
- ;;; mode: xml ***
;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***
;;; End: ***
-->
projects / ghc-hetmet.git / blobdiff