2 <title>Running GHC on Win32 systems</title>
6 Starting GHC on Win32 platforms</title>
9 The installer that installs GHC on Win32 also sets up the file-suffix associations
10 for ".hs" and ".lhs" files so that double-clicking them starts <command>ghci</command>.
13 Be aware of that <command>ghc</command> and <command>ghci</command> do
14 require filenames containing spaces to be escaped using quotes:
16 c:\ghc\bin\ghci "c:\\Program Files\\Haskell\\Project.hs"
18 If the quotes are left off in the above command, <command>ghci</command> will
19 interpret the filename as two, "c:\\Program" and "Files\\Haskell\\Project.hs".
22 <!-- not clear whether there are current editions of Win32 OSes that
23 doesn't do this by default.
25 <para> Solution: don't use "Open With...", avoid spaces in file names,
26 or fiddle with the appropriate registry setting:
28 HKEY_CLASSES_ROOT\Unknown\shell\openas\command
30 Notice how the "%1" argument is quoted (or not).
32 <para> This problem doesn't occur when double-clicking.
40 Avoiding the console window</title>
42 <para>By default GHC builds applications that open a console window when they start.
43 If you want to build a GUI-only application, with no console window, use the flag
44 <literal>-optl-mwindows</literal> in the link step.
50 Differences in library behaviour </title>
53 Some of the standard Haskell libraries behave slightly differently on Windows.
57 On Windows, the '<literal>^Z</literal>' character is interpreted as end-of-file, so
58 if you read a file containing this character the file will appear to end just before it.
59 To subvert this behaviour, you can put the file into Binary
60 mode using <literal>GHC.Handle.hSetBinaryMode</literal>. (unfortunately this
61 function isn't available form anywhere more stable, yet).
70 Using GHC (and other GHC-compiled executables) with cygwin</title>
73 <title>Background</title> <para>The cygwin tools aim to provide a
74 unix-style API on top of the windows libraries, to facilitate ports of
75 unix software to windows. To this end, they introduce a unix-style
76 directory hierarchy under some root directory (typically
77 <filename>/</filename> is <filename>C:\cygwin\</filename>). Moreover,
78 everything built against the cygwin API (including the cygwin tools
79 and programs compiled with cygwin's ghc) will see / as the root of
80 their file system, happily pretending to work in a typical unix
81 environment, and finding things like <filename>/bin</filename> and <filename>/usr/include</filename> without
82 ever explicitly bothering with their actual location on the windows
83 system (probably <filename>C:\cygwin\bin</filename> and <filename>C:\cygwin\usr\include</filename>).
87 <sect2><title>The problem</title>
88 <para>GHC, by default, no longer depends on cygwin, but is a native
89 windows program. It is built using mingw, and it uses mingw's ghc
90 while compiling your Haskell sources (even if you call it from
91 cygwin's bash), but what matters here is that - just like any other
92 normal windows program - neither GHC nor the executables it produces
93 are aware of cygwin's pretended unix hierarchy. GHC will happily
94 accept either '/' or '\' as path separators, but it won't know where
95 to find <filename>/home/joe/Main.hs</filename> or <filename>/bin/bash</filename>
96 or the like. This causes all
97 kinds of fun when GHC is used from within cygwin's bash, or in
98 make-sessions running under cygwin.
102 <sect2><title>Things to do</title>
105 <para> Don't use absolute paths in make, configure & co if there is any chance
106 that those might be passed to GHC (or to GHC-compiled programs). Relative
107 paths are fine because cygwin tools are happy with them and GHC accepts
108 '/' as path-separator. And relative paths don't depend on where cygwin's
109 root directory is located, or on which partition or network drive your source
110 tree happens to reside, as long as you 'cd' there first.
114 <para> If you have to use absolute paths (beware of the innocent-looking
115 <literal>ROOT=`pwd`</literal> in makefile hierarchies or configure scripts), cygwin provides
116 a tool called <command>cygpath</command> that can convert cygwin's unix-style paths to their
117 actual windows-style counterparts. Many cygwin tools actually accept
118 absolute windows-style paths (remember, though, that you either need
119 to escape '\' or convert '\' to '/'), so you should be fine just using those
120 everywhere. If you need to use tools that do some kind of path-mangling
121 that depends on unix-style paths (one fun example is trying to interpret ':'
122 as a separator in path lists..), you can still try to convert paths using
123 <command>cygpath</command> just before they are passed to GHC and friends.
127 <para> If you don't have <command>cygpath</command>, you probably don't have cygwin and hence
128 no problems with it... unless you want to write one build process for several
129 platforms. Again, relative paths are your friend, but if you have to use
130 absolute paths, and don't want to use different tools on different platforms,
131 you can simply write a short Haskell program to print the current directory
132 (thanks to George Russell for this idea): compiled with GHC, this will give
133 you the view of the file system that GHC depends on (which will differ
134 depending on whether GHC is compiled with cygwin's gcc or mingw's
135 gcc or on a real unix system..) - that little program can also deal with
136 escaping '\' in paths. Apart from the banner and the startup time,
137 something like this would also do:
139 $ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci
147 <sect1 id="win32-dlls">
148 <Title>Building and using Win32 DLLs
152 <IndexTerm><Primary>Dynamic link libraries, Win32</Primary></IndexTerm>
153 <IndexTerm><Primary>DLLs, Win32</Primary></IndexTerm>
154 On Win32 platforms, the compiler is capable of both producing and using
155 dynamic link libraries (DLLs) containing ghc-compiled code. This
156 section shows you how to make use of this facility.
160 Until recently, <Command>strip</Command> didn't work reliably on DLLs, so you
161 should test your version with care, or make sure you have the latest
162 binutils. Unfortunately, we don't know exactly which version of binutils
163 cured the problem (it was supposedly fixed some years ago).
167 <Sect2 id="win32-dlls-link">
168 <Title>Linking with DLLs
172 The default on Win32 platforms is to link applications in such a way
173 that the executables will use the Prelude and system libraries DLLs,
174 rather than contain (large chunks of) them. This is transparent at the
182 main = putStrLn "hello, world!"
183 sh$ ghc -o main main.hs
184 ghc: module version changed to 1; reason: no old .hi file
187 -rwxr-xr-x 1 544 everyone 4608 May 3 17:11 main.exe*
195 will give you a binary as before, but the <Filename>main.exe</Filename>
196 generated will use the Prelude and RTS DLLs instead of linking them in
201 4K for a <Literal>"hello, world"</Literal> application—not bad, huh? :-)
206 <Sect2 id="win32-dlls-linking-static">
207 <Title>Not linking with DLLs
208 <IndexTerm><Primary>-static option (Win32)</Primary></IndexTerm></Title>
211 If you want to build an executable that doesn't depend on any
212 ghc-compiled DLLs, use the <Option>-static</Option> option to link in
217 Notice that you cannot mix code that has been compiled with
218 <Option>-static</Option> and not, so you have to use the <Option>-static</Option>
219 option on all the Haskell modules that make up your application.
224 <Sect2 id="win32-dlls-create">
225 <Title>Creating a DLL
229 <emphasis>Making libraries into DLLs doesn't work on Windows at the
230 moment (and is no longer supported); however, all the machinery is
231 still there. If you're interested, contact the GHC team. Note that
232 building an entire Haskell application as a DLL is still supported
233 (it's just inter-DLL Haskell calls that don't work).</emphasis>
234 <IndexTerm><Primary>Creating a Win32 DLL</Primary></IndexTerm>
235 <IndexTerm><Primary>––mk-dll</Primary></IndexTerm>
236 Sealing up your Haskell library inside a DLL is straightforward;
237 compile up the object files that make up the library, and then build
238 the DLL by issuing a command of the form:
243 ghc ––mk-dll -o foo.dll bar.o baz.o wibble.a -lfooble
248 By feeding the ghc compiler driver the option <Option>––mk-dll</Option>, it
249 will build a DLL rather than produce an executable. The DLL will
250 consist of all the object files and archives given on the command
255 To create a `static' DLL, i.e. one that does not depend on the GHC DLLs,
256 use the <Option>-static</Option> when compiling up your Haskell code and
261 A couple of things to notice:
269 Since DLLs correspond to packages (see <XRef LinkEnd="packages">) you need
270 to use <Option>-package-name dll-name</Option> when compiling modules that
271 belong to a DLL if you're going to call them from Haskell. Otherwise, Haskell
272 code that calls entry points in that DLL will do so incorrectly, and crash.
273 For similar reasons, you can only compile a single module tree into a DLL,
274 as <Function>startupHaskell</Function> needs to be able to call its
275 initialisation function, and only takes one such argument (see <XRef
276 LinkEnd="win32-dlls-foreign">). Hence the modules
277 you compile into a DLL must have a common root.
283 By default, the entry points of all the object files will be exported from
284 the DLL when using <Option>––mk-dll</Option>. Should you want to constrain
285 this, you can specify the <Emphasis>module definition file</Emphasis> to use
286 on the command line as follows:
289 ghc ––mk-dll -o .... -optdll--def -optdllMyDef.def
292 See Microsoft documentation for details, but a module definition file
293 simply lists what entry points you want to export. Here's one that's
294 suitable when building a Haskell COM server DLL:
298 DllCanUnloadNow = DllCanUnloadNow@0
299 DllGetClassObject = DllGetClassObject@12
300 DllRegisterServer = DllRegisterServer@0
301 DllUnregisterServer = DllUnregisterServer@0
308 In addition to creating a DLL, the <Option>––mk-dll</Option> option also
309 creates an import library. The import library name is derived from the
310 name of the DLL, as follows:
313 DLL: HScool.dll ==> import lib: libHScool_imp.a
316 The naming scheme may look a bit weird, but it has the purpose of allowing
317 the co-existence of import libraries with ordinary static libraries (e.g.,
318 <Filename>libHSfoo.a</Filename> and
319 <Filename>libHSfoo_imp.a</Filename>.
321 Additionally, when the compiler driver is linking in non-static mode, it
322 will rewrite occurrence of <Option>-lHSfoo</Option> on the command line to
323 <Option>-lHSfoo_imp</Option>. By doing this for you, switching from
324 non-static to static linking is simply a question of adding
325 <Option>-static</Option> to your command line.
335 <Sect2 id="win32-dlls-foreign">
336 <Title>Making DLLs to be called from other languages</Title>
340 If you want to package up Haskell code to be called from other languages,
341 such as Visual Basic or C++, there are some extra things it is useful to
342 know. The dirty details are in the <Emphasis>Foreign Function
343 Interface</Emphasis> definition, but it can be tricky to work out how to
344 combine this with DLL building, so here's an example:
352 Use <Literal>foreign export</Literal> declarations to export the Haskell
353 functions you want to call from the outside. For example,
358 adder :: Int -> Int -> IO Int -- gratuitous use of IO
359 adder x y = return (x+y)
361 foreign export stdcall adder :: Int -> Int -> IO Int
371 ghc -c adder.hs -fglasgow-exts
374 This will produce two files, adder.o and adder_stub.o
380 compile up a <Function>DllMain()</Function> that starts up the Haskell
381 RTS-––a possible implementation is:
384 #include <windows.h>
385 #include <Rts.h>
387 EXTFUN(__stginit_Adder);
389 static char* args[] = { "ghcDll", NULL };
390 /* N.B. argv arrays must end with NULL */
399 if (reason == DLL_PROCESS_ATTACH) {
400 /* By now, the RTS DLL should have been hoisted in, but we need to start it up. */
401 startupHaskell(1, args, __stginit_Adder);
408 Here, <Literal>Adder</Literal> is the name of the root module in the module
409 tree (as mentioned above, there must be a single root module, and hence a
410 single module tree in the DLL).
425 ghc ––mk-dll -o adder.dll adder.o adder_stub.o dllMain.o
433 Start using <Function>adder</Function> from VBA-––here's how I would
434 <Constant>Declare</Constant> it:
437 Private Declare Function adder Lib "adder.dll" Alias "adder@8"
438 (ByVal x As Long, ByVal y As Long) As Long
441 Since this Haskell DLL depends on a couple of the DLLs that come with GHC,
442 make sure that they are in scope/visible.
446 Building statically linked DLLs is the same as in the previous section: it
447 suffices to add <Option>-static</Option> to the commands used to compile up
448 the Haskell source and build the DLL.
461 ;;; Local Variables: ***
463 ;;; sgml-parent-document: ("users_guide.sgml" "book" "chapter") ***