1 <?xml version="1.0" encoding="iso-8859-1"?>
3 <title>Running GHC on Win32 systems</title>
5 <sect1 id="ghc-windows">
7 Starting GHC on Windows platforms</title>
10 The installer that installs GHC on Win32 also sets up the file-suffix associations
11 for ".hs" and ".lhs" files so that double-clicking them starts <command>ghci</command>.
14 Be aware of that <command>ghc</command> and <command>ghci</command> do
15 require filenames containing spaces to be escaped using quotes:
17 c:\ghc\bin\ghci "c:\\Program Files\\Haskell\\Project.hs"
19 If the quotes are left off in the above command, <command>ghci</command> will
20 interpret the filename as two, "c:\\Program" and "Files\\Haskell\\Project.hs".
23 <!-- not clear whether there are current editions of Win32 OSes that
24 doesn't do this by default.
26 <para> Solution: don't use "Open With...", avoid spaces in file names,
27 or fiddle with the appropriate registry setting:
29 HKEY_CLASSES_ROOT\Unknown\shell\openas\command
31 Notice how the "%1" argument is quoted (or not).
33 <para> This problem doesn't occur when double-clicking.
39 <sect1 id="ghci-windows">
40 <title>Running GHCi on Windows</title>
42 <para>We recommend running GHCi in a standard Windows console:
43 select the <literal>GHCi</literal> option from the start menu item
44 added by the GHC installer, or use
45 <literal>Start->Run->cmd</literal> to get a Windows console and
46 invoke <literal>ghci</literal> from there (as long as it's in your
47 <literal>PATH</literal>).</para>
49 <para>If you run GHCi in a Cygwin or MSYS shell, then the Control-C
50 behaviour is adversely affected. In one of these environments you
51 should use the <literal>ghcii.sh</literal> script to start GHCi,
52 otherwise when you hit Control-C you'll be returned to the shell
53 prompt but the GHCi process will still be running. However, even
54 using the <literal>ghcii.sh</literal> script, if you hit Control-C
55 then the GHCi process will be killed immediately, rather than
56 letting you interrupt a running program inside GHCi as it should.
57 This problem is caused by the fact that the Cygwin and MSYS shell
58 environments don't pass Control-C events to non-Cygwin child
59 processes, because in order to do that there needs to be a Windows
62 <para>There's an exception: you can use a Cygwin shell if the
63 <literal>CYGWIN</literal> environment variable does
64 <emphasis>not</emphasis> contain <literal>tty</literal>. In this
65 mode, the Cygwin shell behaves like a Windows console shell and
66 console events are propagated to child processes. Note that the
67 <literal>CYGWIN</literal> environment variable must be set
68 <emphasis>before</emphasis> starting the Cygwin shell; changing it
69 afterwards has no effect on the shell.</para>
71 <para>This problem doesn't just affect GHCi, it affects any
72 GHC-compiled program that wants to catch console events. See the
74 url="&libraryBaseLocation;/GHC-ConsoleHandler.html">GHC.ConsoleHandler</ulink>
78 <sect1 id="terminal-interaction">
80 Interacting with the terminal</title>
82 <para>By default GHC builds applications that open a console window when they start.
83 If you want to build a GUI-only application, with no console window, use the flag
84 <literal>-optl-mwindows</literal> in the link step.
87 <para> <emphasis>Warning:</emphasis> Windows GUI-only programs have no
88 stdin, stdout or stderr so using the ordinary Haskell
89 input/output functions will cause your program to fail with an
90 IO exception, such as:
92 Fail: <stdout>: hPutChar: failed (Bad file descriptor)
94 However using Debug.Trace.trace is alright because it uses
95 Windows debugging output support rather than stderr.</para>
97 <para>For some reason, Mingw ships with the <literal>readline</literal> library,
98 but not with the <literal>readline</literal> headers. As a result, GHC (like Hugs) does not
99 use <literal>readline</literal> for interactive input on Windows.
100 You can get a close simulation by using an emacs shell buffer!
105 <sect1 id="library-differences">
107 Differences in library behaviour </title>
110 Some of the standard Haskell libraries behave slightly differently on Windows.
114 On Windows, the '<literal>^Z</literal>' character is interpreted as an
115 end-of-file character, so if you read a file containing this character
116 the file will appear to end just before it. To avoid this,
117 use <literal>IOExts.openFileEx</literal> to open a file in binary
118 (untranslated) mode or change an already opened file handle into
119 binary mode using <literal>IOExts.hSetBinaryMode</literal>. The
120 <literal>IOExts</literal> module is part of the
121 <literal>lang</literal> package.
128 <sect1 id="ghci-cygwin">
130 Using GHC (and other GHC-compiled executables) with cygwin</title>
133 <title>Background</title> <para>The cygwin tools aim to provide a
134 unix-style API on top of the windows libraries, to facilitate ports of
135 unix software to windows. To this end, they introduce a unix-style
136 directory hierarchy under some root directory (typically
137 <filename>/</filename> is <filename>C:\cygwin\</filename>). Moreover,
138 everything built against the cygwin API (including the cygwin tools
139 and programs compiled with cygwin's ghc) will see / as the root of
140 their file system, happily pretending to work in a typical unix
141 environment, and finding things like <filename>/bin</filename> and <filename>/usr/include</filename> without
142 ever explicitly bothering with their actual location on the windows
143 system (probably <filename>C:\cygwin\bin</filename> and <filename>C:\cygwin\usr\include</filename>).
147 <sect2><title>The problem</title>
148 <para>GHC, by default, no longer depends on cygwin, but is a native
149 windows program. It is built using mingw, and it uses mingw's ghc
150 while compiling your Haskell sources (even if you call it from
151 cygwin's bash), but what matters here is that - just like any other
152 normal windows program - neither GHC nor the executables it produces
153 are aware of cygwin's pretended unix hierarchy. GHC will happily
154 accept either '/' or '\' as path separators, but it won't know where
155 to find <filename>/home/joe/Main.hs</filename> or <filename>/bin/bash</filename>
156 or the like. This causes all
157 kinds of fun when GHC is used from within cygwin's bash, or in
158 make-sessions running under cygwin.
162 <sect2><title>Things to do</title>
165 <para> Don't use absolute paths in make, configure & co if there is any chance
166 that those might be passed to GHC (or to GHC-compiled programs). Relative
167 paths are fine because cygwin tools are happy with them and GHC accepts
168 '/' as path-separator. And relative paths don't depend on where cygwin's
169 root directory is located, or on which partition or network drive your source
170 tree happens to reside, as long as you 'cd' there first.
174 <para> If you have to use absolute paths (beware of the innocent-looking
175 <literal>ROOT=`pwd`</literal> in makefile hierarchies or configure scripts), cygwin provides
176 a tool called <command>cygpath</command> that can convert cygwin's unix-style paths to their
177 actual windows-style counterparts. Many cygwin tools actually accept
178 absolute windows-style paths (remember, though, that you either need
179 to escape '\' or convert '\' to '/'), so you should be fine just using those
180 everywhere. If you need to use tools that do some kind of path-mangling
181 that depends on unix-style paths (one fun example is trying to interpret ':'
182 as a separator in path lists..), you can still try to convert paths using
183 <command>cygpath</command> just before they are passed to GHC and friends.
187 <para> If you don't have <command>cygpath</command>, you probably don't have cygwin and hence
188 no problems with it... unless you want to write one build process for several
189 platforms. Again, relative paths are your friend, but if you have to use
190 absolute paths, and don't want to use different tools on different platforms,
191 you can simply write a short Haskell program to print the current directory
192 (thanks to George Russell for this idea): compiled with GHC, this will give
193 you the view of the file system that GHC depends on (which will differ
194 depending on whether GHC is compiled with cygwin's gcc or mingw's
195 gcc or on a real unix system..) - that little program can also deal with
196 escaping '\' in paths. Apart from the banner and the startup time,
197 something like this would also do:
199 $ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci
207 <sect1 id="win32-dlls">
208 <title>Building and using Win32 DLLs
212 <indexterm><primary>Dynamic link libraries, Win32</primary></indexterm>
213 <indexterm><primary>DLLs, Win32</primary></indexterm>
214 On Win32 platforms, the compiler is capable of both producing and using
215 dynamic link libraries (DLLs) containing ghc-compiled code. This
216 section shows you how to make use of this facility.
220 There are two distinct ways in which DLLs can be used:
224 You can turn each Haskell package into a DLL, so that multiple
225 Haskell executables using the same packages can share the DLL files.
226 (As opposed to linking the libraries statically, which in effect
227 creates a new copy of the RTS and all libraries for each executable
231 That is the same as the dynamic linking on other platforms, and it
232 is described in <xref linkend="using-shared-libs"/>.
237 You can package up a complete Haskell program as a DLL, to be called
238 by some external (usually non-Haskell) program. This is usually used
239 to implement plugins and the like, and is described below.
247 Until recently, <command>strip</command> didn't work reliably on DLLs, so you
248 should test your version with care, or make sure you have the latest
249 binutils. Unfortunately, we don't know exactly which version of binutils
250 cured the problem (it was supposedly fixed some years ago).
254 <sect2 id="win32-dlls-link">
255 <title>Linking with DLLs</title>
258 The default on Win32 platforms is to link applications in such a way
259 that the executables will use the Prelude and system libraries DLLs,
260 rather than contain (large chunks of) them. This is transparent at the
268 main = putStrLn "hello, world!"
269 sh$ ghc -o main main.hs
270 ghc: module version changed to 1; reason: no old .hi file
273 -rwxr-xr-x 1 544 everyone 4608 May 3 17:11 main.exe*
281 will give you a binary as before, but the <filename>main.exe</filename>
282 generated will use the Prelude and RTS DLLs instead of linking them in
287 4K for a <literal>"hello, world"</literal> application—not bad, huh? :-)
292 <sect2 id="win32-dlls-linking-static">
293 <title>Not linking with DLLs
294 <indexterm><primary>-static option (Win32)</primary></indexterm></title>
297 If you want to build an executable that doesn't depend on any
298 ghc-compiled DLLs, use the <option>-static</option> option to link in
303 Notice that you cannot mix code that has been compiled with
304 <option>-static</option> and not, so you have to use the <option>-static</option>
305 option on all the Haskell modules that make up your application.
311 <sect2 id="win32-dlls-create">
312 <title>Creating a DLL</title>
315 <indexterm><primary>Creating a Win32 DLL</primary></indexterm>
316 <indexterm><primary>–shared</primary></indexterm>
317 Sealing up your Haskell library inside a DLL is straightforward;
318 compile up the object files that make up the library, and then build
319 the DLL by issuing a command of the form:
324 ghc –shared -o foo.dll bar.o baz.o wibble.a -lfooble
329 By feeding the ghc compiler driver the option <option>–shared</option>, it
330 will build a DLL rather than produce an executable. The DLL will
331 consist of all the object files and archives given on the command
337 To create a `static' DLL, i.e. one that does not depend on the GHC DLLs,
338 use the <option>-static</option> when compiling up your Haskell code and
344 A couple of things to notice:
353 Since DLLs correspond to packages (see <xref linkend="packages"/>) you need
354 to use <option>-package-name dll-name</option> when compiling modules that
355 belong to a DLL if you're going to call them from Haskell. Otherwise, Haskell
356 code that calls entry points in that DLL will do so incorrectly, and crash.
357 For similar reasons, you can only compile a single module tree into a DLL,
358 as <function>startupHaskell</function> needs to be able to call its
359 initialisation function, and only takes one such argument (see <xref
360 linkend="win32-dlls-foreign"/>). Hence the modules
361 you compile into a DLL must have a common root.
368 By default, the entry points of all the object files will be exported from
369 the DLL when using <option>–shared</option>. Should you want to constrain
370 this, you can specify the <emphasis>module definition file</emphasis> to use
371 on the command line as follows:
374 ghc –shared -o .... MyDef.def
377 See Microsoft documentation for details, but a module definition file
378 simply lists what entry points you want to export. Here's one that's
379 suitable when building a Haskell COM server DLL:
383 DllCanUnloadNow = DllCanUnloadNow@0
384 DllGetClassObject = DllGetClassObject@12
385 DllRegisterServer = DllRegisterServer@0
386 DllUnregisterServer = DllUnregisterServer@0
393 In addition to creating a DLL, the <option>–shared</option> option also
394 creates an import library. The import library name is derived from the
395 name of the DLL, as follows:
398 DLL: HScool.dll ==> import lib: libHScool.dll.a
401 The naming scheme may look a bit weird, but it has the purpose of allowing
402 the co-existence of import libraries with ordinary static libraries (e.g.,
403 <filename>libHSfoo.a</filename> and
404 <filename>libHSfoo.dll.a</filename>.
406 Additionally, when the compiler driver is linking in non-static mode, it
407 will rewrite occurrence of <option>-lHSfoo</option> on the command line to
408 <option>-lHSfoo.dll</option>. By doing this for you, switching from
409 non-static to static linking is simply a question of adding
410 <option>-static</option> to your command line.
420 <sect2 id="win32-dlls-foreign">
421 <title>Making DLLs to be called from other languages</title>
424 This section describes how to create DLLs to be called from other languages,
425 such as Visual Basic or C++. This is a special case of
426 <xref linkend="ffi-library" />; we'll deal with the DLL-specific issues that
427 arise below. Here's an example:
430 Use foreign export declarations to export the Haskell functions you want to
431 call from the outside. For example:
435 {-# LANGUAGE ForeignFunctionInterface #-}
438 adder :: Int -> Int -> IO Int -- gratuitous use of IO
439 adder x y = return (x+y)
441 foreign export stdcall adder :: Int -> Int -> IO Int
444 Add some helper code that starts up and shuts down the Haskell RTS:
448 #include <Rts.h>
453 char* argv[] = {"ghcDll", NULL}; // argv must end with NULL
455 // Initialize Haskell runtime
457 hs_init(&argc, &args);
466 Here, <literal>Adder</literal> is the name of the root module in the module
467 tree (as mentioned above, there must be a single root module, and hence a
468 single module tree in the DLL). Compile everything up:
473 ghc -shared -o Adder.dll Adder.o Adder_stub.o StartEnd.o
476 Now the file <filename>Adder.dll</filename> can be used from other
477 programming languages. Before calling any functions in Adder it is necessary
478 to call <literal>HsStart</literal>, and at the very end call
479 <literal>HsEnd</literal>.
482 <emphasis>Warning:</emphasis> It may appear tempting to use
483 <literal>DllMain</literal> to call
484 <literal>hs_init</literal>/<literal>hs_exit</literal>, but this won't work
485 (particularly if you compile with <literal>-threaded</literal>). There are
486 severe restrictions on which actions can be performed during
487 <literal>DllMain</literal>, and <literal>hs_init</literal> violates these
488 restrictions, which can lead to your dll freezing during startup (see
489 <ulink url="http://hackage.haskell.org/trac/ghc/ticket/3605">bug
493 <sect3 id="win32-dlls-vba">
494 <title>Using from VBA</title>
497 An example of using <filename>Adder.dll</filename> from VBA is:
500 Private Declare Function Adder Lib "Adder.dll" Alias "adder@8" _
501 (ByVal x As Long, ByVal y As Long) As Long
503 Private Declare Sub HsStart Lib "Adder.dll" ()
504 Private Declare Sub HsEnd Lib "Adder.dll" ()
506 Private Sub Document_Close()
510 Private Sub Document_Open()
515 MsgBox "12 + 5 = " & Adder(12, 5)
519 This example uses the
520 <literal>Document_Open</literal>/<literal>Close</literal> functions of
521 Microsoft Word, but provided <literal>HsStart</literal> is called before the
522 first function, and <literal>HsEnd</literal> after the last, then it will
527 <sect3 id="win32-dlls-c++">
528 <title>Using from C++</title>
531 An example of using <filename>Adder.dll</filename> from C++ is:
537 #include "Adder_stub.h"
538 #include <stdio.h>
548 // can now safely call functions from the DLL
549 printf("12 + 5 = %i\n", adder(12,5)) ;
555 This can be compiled and run with:
558 $ ghc -o tester Tester.cpp Adder.dll.a
571 ;;; Local Variables: ***
572 ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***