1 <?xml version="1.0" encoding="iso-8859-1"?>
3 <title>Running GHC on Win32 systems</title>
7 Starting GHC on Win32 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.
41 Interacting with the terminal</title>
43 <para>By default GHC builds applications that open a console window when they start.
44 If you want to build a GUI-only application, with no console window, use the flag
45 <literal>-optl-mwindows</literal> in the link step.
48 <para> <emphasis>Warning:</emphasis> Windows GUI-only programs have no
49 stdin, stdout or stderr so using the ordinary Haskell
50 input/output functions will cause your program to fail with an
51 IO exception, such as:
53 Fail: <stdout>: hPutChar: failed (Bad file descriptor)
55 However using Debug.Trace.trace is alright because it uses
56 Windows debugging output support rather than stderr.</para>
58 <para>For some reason, Mingw ships with the <literal>readline</literal> library,
59 but not with the <literal>readline</literal> headers. As a result, GHC (like Hugs) does not
60 use <literal>readline</literal> for interactive input on Windows.
61 You can get a close simulation by using an emacs shell buffer!
68 Differences in library behaviour </title>
71 Some of the standard Haskell libraries behave slightly differently on Windows.
75 On Windows, the '<literal>^Z</literal>' character is interpreted as an
76 end-of-file character, so if you read a file containing this character
77 the file will appear to end just before it. To avoid this,
78 use <literal>IOExts.openFileEx</literal> to open a file in binary
79 (untranslated) mode or change an already opened file handle into
80 binary mode using <literal>IOExts.hSetBinaryMode</literal>. The
81 <literal>IOExts</literal> module is part of the
82 <literal>lang</literal> package.
91 Using GHC (and other GHC-compiled executables) with cygwin</title>
94 <title>Background</title> <para>The cygwin tools aim to provide a
95 unix-style API on top of the windows libraries, to facilitate ports of
96 unix software to windows. To this end, they introduce a unix-style
97 directory hierarchy under some root directory (typically
98 <filename>/</filename> is <filename>C:\cygwin\</filename>). Moreover,
99 everything built against the cygwin API (including the cygwin tools
100 and programs compiled with cygwin's ghc) will see / as the root of
101 their file system, happily pretending to work in a typical unix
102 environment, and finding things like <filename>/bin</filename> and <filename>/usr/include</filename> without
103 ever explicitly bothering with their actual location on the windows
104 system (probably <filename>C:\cygwin\bin</filename> and <filename>C:\cygwin\usr\include</filename>).
108 <sect2><title>The problem</title>
109 <para>GHC, by default, no longer depends on cygwin, but is a native
110 windows program. It is built using mingw, and it uses mingw's ghc
111 while compiling your Haskell sources (even if you call it from
112 cygwin's bash), but what matters here is that - just like any other
113 normal windows program - neither GHC nor the executables it produces
114 are aware of cygwin's pretended unix hierarchy. GHC will happily
115 accept either '/' or '\' as path separators, but it won't know where
116 to find <filename>/home/joe/Main.hs</filename> or <filename>/bin/bash</filename>
117 or the like. This causes all
118 kinds of fun when GHC is used from within cygwin's bash, or in
119 make-sessions running under cygwin.
123 <sect2><title>Things to do</title>
126 <para> Don't use absolute paths in make, configure & co if there is any chance
127 that those might be passed to GHC (or to GHC-compiled programs). Relative
128 paths are fine because cygwin tools are happy with them and GHC accepts
129 '/' as path-separator. And relative paths don't depend on where cygwin's
130 root directory is located, or on which partition or network drive your source
131 tree happens to reside, as long as you 'cd' there first.
135 <para> If you have to use absolute paths (beware of the innocent-looking
136 <literal>ROOT=`pwd`</literal> in makefile hierarchies or configure scripts), cygwin provides
137 a tool called <command>cygpath</command> that can convert cygwin's unix-style paths to their
138 actual windows-style counterparts. Many cygwin tools actually accept
139 absolute windows-style paths (remember, though, that you either need
140 to escape '\' or convert '\' to '/'), so you should be fine just using those
141 everywhere. If you need to use tools that do some kind of path-mangling
142 that depends on unix-style paths (one fun example is trying to interpret ':'
143 as a separator in path lists..), you can still try to convert paths using
144 <command>cygpath</command> just before they are passed to GHC and friends.
148 <para> If you don't have <command>cygpath</command>, you probably don't have cygwin and hence
149 no problems with it... unless you want to write one build process for several
150 platforms. Again, relative paths are your friend, but if you have to use
151 absolute paths, and don't want to use different tools on different platforms,
152 you can simply write a short Haskell program to print the current directory
153 (thanks to George Russell for this idea): compiled with GHC, this will give
154 you the view of the file system that GHC depends on (which will differ
155 depending on whether GHC is compiled with cygwin's gcc or mingw's
156 gcc or on a real unix system..) - that little program can also deal with
157 escaping '\' in paths. Apart from the banner and the startup time,
158 something like this would also do:
160 $ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci
168 <sect1 id="win32-dlls">
169 <title>Building and using Win32 DLLs
173 <emphasis>Making Haskell libraries into DLLs doesn't work on Windows at the
174 moment; however, all the machinery is
175 still there. If you're interested, contact the GHC team. Note that
176 building an entire Haskell application as a single DLL is still supported: it's
177 just multi-DLL Haskell programs that don't work. The Windows
178 distribution of GHC contains static libraries only.</emphasis></para>
182 <indexterm><primary>Dynamic link libraries, Win32</primary></indexterm>
183 <indexterm><primary>DLLs, Win32</primary></indexterm>
184 On Win32 platforms, the compiler is capable of both producing and using
185 dynamic link libraries (DLLs) containing ghc-compiled code. This
186 section shows you how to make use of this facility.
190 Until recently, <command>strip</command> didn't work reliably on DLLs, so you
191 should test your version with care, or make sure you have the latest
192 binutils. Unfortunately, we don't know exactly which version of binutils
193 cured the problem (it was supposedly fixed some years ago).
197 <sect2 id="win32-dlls-link">
198 <title>Linking with DLLs</title>
201 The default on Win32 platforms is to link applications in such a way
202 that the executables will use the Prelude and system libraries DLLs,
203 rather than contain (large chunks of) them. This is transparent at the
211 main = putStrLn "hello, world!"
212 sh$ ghc -o main main.hs
213 ghc: module version changed to 1; reason: no old .hi file
216 -rwxr-xr-x 1 544 everyone 4608 May 3 17:11 main.exe*
224 will give you a binary as before, but the <filename>main.exe</filename>
225 generated will use the Prelude and RTS DLLs instead of linking them in
230 4K for a <literal>"hello, world"</literal> application—not bad, huh? :-)
235 <sect2 id="win32-dlls-linking-static">
236 <title>Not linking with DLLs
237 <indexterm><primary>-static option (Win32)</primary></indexterm></title>
240 If you want to build an executable that doesn't depend on any
241 ghc-compiled DLLs, use the <option>-static</option> option to link in
246 Notice that you cannot mix code that has been compiled with
247 <option>-static</option> and not, so you have to use the <option>-static</option>
248 option on all the Haskell modules that make up your application.
254 <sect2 id="win32-dlls-create">
255 <title>Creating a DLL</title>
258 <indexterm><primary>Creating a Win32 DLL</primary></indexterm>
259 <indexterm><primary>––mk-dll</primary></indexterm>
260 Sealing up your Haskell library inside a DLL is straightforward;
261 compile up the object files that make up the library, and then build
262 the DLL by issuing a command of the form:
267 ghc ––mk-dll -o foo.dll bar.o baz.o wibble.a -lfooble
272 By feeding the ghc compiler driver the option <option>––mk-dll</option>, it
273 will build a DLL rather than produce an executable. The DLL will
274 consist of all the object files and archives given on the command
280 To create a `static' DLL, i.e. one that does not depend on the GHC DLLs,
281 use the <option>-static</option> when compiling up your Haskell code and
287 A couple of things to notice:
296 Since DLLs correspond to packages (see <xref linkend="packages"/>) you need
297 to use <option>-package-name dll-name</option> when compiling modules that
298 belong to a DLL if you're going to call them from Haskell. Otherwise, Haskell
299 code that calls entry points in that DLL will do so incorrectly, and crash.
300 For similar reasons, you can only compile a single module tree into a DLL,
301 as <function>startupHaskell</function> needs to be able to call its
302 initialisation function, and only takes one such argument (see <xref
303 linkend="win32-dlls-foreign"/>). Hence the modules
304 you compile into a DLL must have a common root.
311 By default, the entry points of all the object files will be exported from
312 the DLL when using <option>––mk-dll</option>. Should you want to constrain
313 this, you can specify the <emphasis>module definition file</emphasis> to use
314 on the command line as follows:
317 ghc ––mk-dll -o .... -optdll––def -optdllMyDef.def
320 See Microsoft documentation for details, but a module definition file
321 simply lists what entry points you want to export. Here's one that's
322 suitable when building a Haskell COM server DLL:
326 DllCanUnloadNow = DllCanUnloadNow@0
327 DllGetClassObject = DllGetClassObject@12
328 DllRegisterServer = DllRegisterServer@0
329 DllUnregisterServer = DllUnregisterServer@0
336 In addition to creating a DLL, the <option>––mk-dll</option> option also
337 creates an import library. The import library name is derived from the
338 name of the DLL, as follows:
341 DLL: HScool.dll ==> import lib: libHScool_imp.a
344 The naming scheme may look a bit weird, but it has the purpose of allowing
345 the co-existence of import libraries with ordinary static libraries (e.g.,
346 <filename>libHSfoo.a</filename> and
347 <filename>libHSfoo_imp.a</filename>.
349 Additionally, when the compiler driver is linking in non-static mode, it
350 will rewrite occurrence of <option>-lHSfoo</option> on the command line to
351 <option>-lHSfoo_imp</option>. By doing this for you, switching from
352 non-static to static linking is simply a question of adding
353 <option>-static</option> to your command line.
363 <sect2 id="win32-dlls-foreign">
364 <title>Making DLLs to be called from other languages</title>
368 If you want to package up Haskell code to be called from other languages,
369 such as Visual Basic or C++, there are some extra things it is useful to
370 know. The dirty details are in the <emphasis>Foreign Function
371 Interface</emphasis> definition, but it can be tricky to work out how to
372 combine this with DLL building, so here's an example:
380 Use <literal>foreign export</literal> declarations to export the Haskell
381 functions you want to call from the outside. For example,
386 adder :: Int -> Int -> IO Int –– gratuitous use of IO
387 adder x y = return (x+y)
389 foreign export stdcall adder :: Int -> Int -> IO Int
399 ghc -c adder.hs -fglasgow-exts
402 This will produce two files, adder.o and adder_stub.o
408 compile up a <function>DllMain()</function> that starts up the Haskell
409 RTS-––a possible implementation is:
412 #include <windows.h>
413 #include <Rts.h>
415 extern void__stginit_Adder(void);
417 static char* args[] = { "ghcDll", NULL };
418 /* N.B. argv arrays must end with NULL */
427 if (reason == DLL_PROCESS_ATTACH) {
428 /* By now, the RTS DLL should have been hoisted in, but we need to start it up. */
429 startupHaskell(1, args, __stginit_Adder);
436 Here, <literal>Adder</literal> is the name of the root module in the module
437 tree (as mentioned above, there must be a single root module, and hence a
438 single module tree in the DLL).
453 ghc ––mk-dll -o adder.dll adder.o adder_stub.o dllMain.o
461 Start using <function>adder</function> from VBA-––here's how I would
462 <constant>Declare</constant> it:
465 Private Declare Function adder Lib "adder.dll" Alias "adder@8"
466 (ByVal x As Long, ByVal y As Long) As Long
469 Since this Haskell DLL depends on a couple of the DLLs that come with GHC,
470 make sure that they are in scope/visible.
474 Building statically linked DLLs is the same as in the previous section: it
475 suffices to add <option>-static</option> to the commands used to compile up
476 the Haskell source and build the DLL.
489 ;;; Local Variables: ***
491 ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***