win32-dlls.xml 20.8 KB
Newer Older
1
<?xml version="1.0" encoding="iso-8859-1"?>
2
3
4
<chapter id="win32">
<title>Running GHC on Win32 systems</title>

5
<sect1 id="ghc-windows">
6
<title>
7
Starting GHC on Windows platforms</title>
8
9
10
11
12
13

<para>
The installer that installs GHC on Win32 also sets up the file-suffix associations
for ".hs" and ".lhs" files so that double-clicking them starts <command>ghci</command>.
</para>
<para>
sof's avatar
sof committed
14
15
Be aware of that <command>ghc</command> and <command>ghci</command> do
require filenames containing spaces to be escaped using quotes:
16
<programlisting>
sof's avatar
sof committed
17
  c:\ghc\bin\ghci "c:\\Program Files\\Haskell\\Project.hs"
18
</programlisting>
sof's avatar
sof committed
19
20
If the quotes are left off in the above command, <command>ghci</command> will
interpret the filename as two, "c:\\Program" and "Files\\Haskell\\Project.hs".
21
</para>
sof's avatar
sof committed
22
23
24
25

<!-- not clear whether there are current editions of Win32 OSes that
     doesn't do this by default.

26
27
28
29
30
31
32
33
34
<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
</programlisting>
Notice how the "%1" argument is quoted (or not).
</para>
<para> This problem doesn't occur when double-clicking.
</para>
sof's avatar
sof committed
35
-->
36
37
38

</sect1>

39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
<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="../libraries/base/GHC-ConsoleHandler.html">GHC.ConsoleHandler</ulink>
  module.</para>
</sect1>

78
<sect1 id="terminal-interaction">
79
<title>
80
Interacting with the terminal</title>
81
82
83
84
85

<para>By default GHC builds applications that open a console window when they start.
If you want to build a GUI-only application, with no console window, use the flag
<literal>-optl-mwindows</literal> in the link step.
</para>
86

87
88
89
90
91
92
93
94
95
96
<para>       <emphasis>Warning:</emphasis> Windows GUI-only programs have no
        stdin, stdout or stderr so using the ordinary Haskell
        input/output functions will cause your program to fail with an
        IO exception, such as:
<screen>
      Fail: &lt;stdout&gt;: hPutChar: failed (Bad file descriptor)
</screen>
        However using Debug.Trace.trace is alright because it uses
        Windows debugging output support rather than stderr.</para>

97
98
99
100
101
102
<para>For some reason, Mingw ships with the <literal>readline</literal> library,
but not with the <literal>readline</literal> headers. As a result, GHC (like Hugs) does not
use <literal>readline</literal> for interactive input on Windows.
You can get a close simulation by using an emacs shell buffer!
</para>

103
104
</sect1>

105
<sect1 id="library-differences">
106
107
108
109
110
111
112
113
<title>
Differences in library behaviour </title>

<para>
Some of the standard Haskell libraries behave slightly differently on Windows.

<itemizedlist>
<listitem> <para>
sof's avatar
sof committed
114
115
116
117
118
119
120
121
On Windows, the '<literal>^Z</literal>' character is interpreted as an
end-of-file character, so if you read a file containing this character
the file will appear to end just before it. To avoid this,
use <literal>IOExts.openFileEx</literal> to open a file in binary
(untranslated) mode or change an already opened file handle into
binary mode using <literal>IOExts.hSetBinaryMode</literal>. The
<literal>IOExts</literal> module is part of the
<literal>lang</literal> package.
122
123
124
125
126
127
</para>
</listitem>
</itemizedlist>
</para>
</sect1>

128
<sect1 id="ghci-cygwin">
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
<title>
Using GHC (and other GHC-compiled executables) with cygwin</title>

<sect2>
<title>Background</title> <para>The cygwin tools aim to provide a
unix-style API on top of the windows libraries, to facilitate ports of
unix software to windows. To this end, they introduce a unix-style
directory hierarchy under some root directory (typically
<filename>/</filename> is <filename>C:\cygwin\</filename>). Moreover,
everything built against the cygwin API (including the cygwin tools
and programs compiled with cygwin's ghc) will see / as the root of
their file system, happily pretending to work in a typical unix
environment, and finding things like <filename>/bin</filename> and <filename>/usr/include</filename> without
ever explicitly bothering with their actual location on the windows
system (probably <filename>C:\cygwin\bin</filename> and <filename>C:\cygwin\usr\include</filename>).
</para>
</sect2>

<sect2><title>The problem</title>
<para>GHC, by default, no longer depends on cygwin, but is a native
windows program. It is built using mingw, and it uses mingw's ghc
while compiling your Haskell sources (even if you call it from
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> 
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.
</para>
</sect2>

<sect2><title>Things to do</title>
<itemizedlist>
<listitem>
165
<para> Don't use absolute paths in make, configure &amp; co if there is any chance 
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
  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 
  '/' 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.
</para></listitem>

<listitem>
<para> If you have to use absolute paths (beware of the innocent-looking
  <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 
  <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 
  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, 
  something like this would also do:
<programlisting>
  $ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci
</programlisting>
</para></listitem>
</itemizedlist>
</sect2>
</sect1>


<sect1 id="win32-dlls">
208
209
<title>Building and using Win32 DLLs
</title>
sof's avatar
sof committed
210

211
212
<para>
<emphasis>Making Haskell libraries into DLLs doesn't work on Windows at the
Simon Marlow's avatar
Simon Marlow committed
213
moment; we hope to re-instate this facility in the future.  Note that
214
215
216
217
218
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>

<!--
219
220
221
<para>
<indexterm><primary>Dynamic link libraries, Win32</primary></indexterm>
<indexterm><primary>DLLs, Win32</primary></indexterm>
sof's avatar
sof committed
222
223
224
On Win32 platforms, the compiler is capable of both producing and using
dynamic link libraries (DLLs) containing ghc-compiled code. This
section shows you how to make use of this facility.
225
</para>
sof's avatar
sof committed
226

227
228
<para>
Until recently, <command>strip</command> didn't work reliably on DLLs, so you
rrt's avatar
rrt committed
229
230
231
should test your version with care, or make sure you have the latest
binutils. Unfortunately, we don't know exactly which version of binutils
cured the problem (it was supposedly fixed some years ago).
232
</para>
rrt's avatar
rrt committed
233
234


235
236
<sect2 id="win32-dlls-link">
<title>Linking with DLLs</title>
sof's avatar
sof committed
237

238
<para>
sof's avatar
sof committed
239
240
241
242
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 
243
</para>
sof's avatar
sof committed
244

245
246
<para>
<screen>
sof's avatar
sof committed
247
248
249
250
251
252
253
sh$ cat main.hs
module Main where
main = putStrLn "hello, world!"
sh$ ghc -o main main.hs
ghc: module version changed to 1; reason: no old .hi file
sh$ strip main.exe
sh$ ls -l main.exe
rrt's avatar
rrt committed
254
-rwxr-xr-x   1 544      everyone     4608 May  3 17:11 main.exe*
sof's avatar
sof committed
255
256
257
sh$ ./main
hello, world!
sh$ 
258
259
</screen>
</para>
sof's avatar
sof committed
260

261
262
<para>
will give you a binary as before, but the <filename>main.exe</filename>
rrt's avatar
rrt committed
263
264
generated will use the Prelude and RTS DLLs instead of linking them in
statically.
265
</para>
rrt's avatar
rrt committed
266

267
268
269
<para>
4K for a <literal>"hello, world"</literal> application&mdash;not bad, huh? :-)
</para>
sof's avatar
sof committed
270

271
</sect2>
sof's avatar
sof committed
272

273
274
275
<sect2 id="win32-dlls-linking-static">
<title>Not linking with DLLs
<indexterm><primary>-static option (Win32)</primary></indexterm></title>
sof's avatar
sof committed
276

277
<para>
rrt's avatar
rrt committed
278
If you want to build an executable that doesn't depend on any
279
ghc-compiled DLLs, use the <option>-static</option> option to link in
rrt's avatar
rrt committed
280
the code statically.
281
</para>
sof's avatar
sof committed
282

283
<para>
sof's avatar
sof committed
284
Notice that you cannot mix code that has been compiled with
285
<option>-static</option> and not, so you have to use the <option>-static</option>
sof's avatar
sof committed
286
option on all the Haskell modules that make up your application.
287
</para>
sof's avatar
sof committed
288

289
</sect2>
290
-->
sof's avatar
sof committed
291

292
293
<sect2 id="win32-dlls-create">
<title>Creating a DLL</title>
rrt's avatar
rrt committed
294

295
296
297
<para>
<indexterm><primary>Creating a Win32 DLL</primary></indexterm>
<indexterm><primary>&ndash;&ndash;mk-dll</primary></indexterm>
rrt's avatar
rrt committed
298
Sealing up your Haskell library inside a DLL is straightforward;
sof's avatar
sof committed
299
compile up the object files that make up the library, and then build
rrt's avatar
rrt committed
300
the DLL by issuing a command of the form:
301
</para>
sof's avatar
sof committed
302

303
304
<para>
<screen>
305
ghc &ndash;&ndash;mk-dll -o foo.dll bar.o baz.o wibble.a -lfooble
306
307
</screen>
</para>
sof's avatar
sof committed
308

309
310
<para>
By feeding the ghc compiler driver the option <option>&ndash;&ndash;mk-dll</option>, it
sof's avatar
sof committed
311
312
313
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.
314
</para>
sof's avatar
sof committed
315

316
<!--
317
<para>
rrt's avatar
rrt committed
318
To create a `static' DLL, i.e. one that does not depend on the GHC DLLs,
319
use the <option>-static</option> when compiling up your Haskell code and
rrt's avatar
rrt committed
320
building the DLL.
321
</para>
322
-->
rrt's avatar
rrt committed
323

324
<para>
sof's avatar
sof committed
325
A couple of things to notice:
326
</para>
rrt's avatar
rrt committed
327

328
<para>
rrt's avatar
rrt committed
329

330
<itemizedlist>
331
<!--
332
333
334
335
<listitem>
<para>
Since DLLs correspond to packages (see <xref linkend="packages"/>) you need
to use <option>-package-name dll-name</option> when compiling modules that
rrt's avatar
rrt committed
336
337
338
belong to a DLL if you're going to call them from Haskell. Otherwise, Haskell
code that calls entry points in that DLL will do so incorrectly, and crash.
For similar reasons, you can only compile a single module tree into a DLL,
339
340
341
as <function>startupHaskell</function> needs to be able to call its
initialisation function, and only takes one such argument (see <xref
linkend="win32-dlls-foreign"/>). Hence the modules
rrt's avatar
rrt committed
342
you compile into a DLL must have a common root.
343
344
</para>
</listitem>
345
-->
rrt's avatar
rrt committed
346

347
348
<listitem>
<para>
rrt's avatar
rrt committed
349
By default, the entry points of all the object files will be exported from
350
351
the DLL when using <option>&ndash;&ndash;mk-dll</option>. Should you want to constrain
this, you can specify the <emphasis>module definition file</emphasis> to use
rrt's avatar
rrt committed
352
on the command line as follows:
rrt's avatar
rrt committed
353

354
<screen>
355
ghc &ndash;&ndash;mk-dll -o .... -optdll&ndash;&ndash;def -optdllMyDef.def
356
</screen>
rrt's avatar
rrt committed
357

sof's avatar
sof committed
358
359
360
361
See Microsoft documentation for details, but a module definition file
simply lists what entry points you want to export. Here's one that's
suitable when building a Haskell COM server DLL:

362
<programlisting>
sof's avatar
sof committed
363
364
365
366
367
EXPORTS
 DllCanUnloadNow     = DllCanUnloadNow@0
 DllGetClassObject   = DllGetClassObject@12
 DllRegisterServer   = DllRegisterServer@0
 DllUnregisterServer = DllUnregisterServer@0
368
369
370
</programlisting>
</para>
</listitem>
sof's avatar
sof committed
371

372
373
374
<listitem>
<para>
In addition to creating a DLL, the <option>&ndash;&ndash;mk-dll</option> option also
rrt's avatar
rrt committed
375
creates an import library. The import library name is derived from the
sof's avatar
sof committed
376
377
name of the DLL, as follows:

378
<programlisting>
rrt's avatar
rrt committed
379
DLL: HScool.dll  ==&#62; import lib: libHScool_imp.a
380
</programlisting>
rrt's avatar
rrt committed
381

rrt's avatar
rrt committed
382
383
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.,
384
385
<filename>libHSfoo.a</filename> and
<filename>libHSfoo&lowbar;imp.a</filename>.
sof's avatar
sof committed
386

rrt's avatar
rrt committed
387
Additionally, when the compiler driver is linking in non-static mode, it
388
389
will rewrite occurrence of <option>-lHSfoo</option> on the command line to
<option>-lHSfoo&lowbar;imp</option>. By doing this for you, switching from
rrt's avatar
rrt committed
390
non-static to static linking is simply a question of adding
391
<option>-static</option> to your command line.
sof's avatar
sof committed
392

393
394
395
396
</para>
</listitem>
</itemizedlist>
</para>
rrt's avatar
rrt committed
397

398
</sect2>
rrt's avatar
rrt committed
399
400


401
402
<sect2 id="win32-dlls-foreign">
<title>Making DLLs to be called from other languages</title>
rrt's avatar
rrt committed
403

404
<para>
rrt's avatar
rrt committed
405
406
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
Simon Marlow's avatar
Simon Marlow committed
407
408
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:
409
</para>
rrt's avatar
rrt committed
410

411
<itemizedlist>
rrt's avatar
rrt committed
412

413
414
415
<listitem>
<para>
Use <literal>foreign export</literal> declarations to export the Haskell
rrt's avatar
rrt committed
416
functions you want to call from the outside. For example,
rrt's avatar
rrt committed
417

418
<programlisting>
rrt's avatar
rrt committed
419
420
module Adder where

421
adder :: Int -> Int -> IO Int  &ndash;&ndash; gratuitous use of IO
rrt's avatar
rrt committed
422
423
424
adder x y = return (x+y)

foreign export stdcall adder :: Int -> Int -> IO Int
425
426
427
</programlisting>
</para>
</listitem>
rrt's avatar
rrt committed
428

429
430
<listitem>
<para>
rrt's avatar
rrt committed
431
432
Compile it up:

433
<screen>
rrt's avatar
rrt committed
434
ghc -c adder.hs -fglasgow-exts
435
</screen>
rrt's avatar
rrt committed
436
437
  
This will produce two files, adder.o and adder_stub.o
438
439
</para>
</listitem>
rrt's avatar
rrt committed
440

441
442
443
<listitem>
<para>
compile up a <function>DllMain()</function> that starts up the Haskell
444
RTS-&ndash;&ndash;a possible implementation is:
rrt's avatar
rrt committed
445

446
<programlisting>
rrt's avatar
rrt committed
447
#include &lt;windows.h&gt;
rrt's avatar
rrt committed
448
#include &lt;Rts.h&gt;
rrt's avatar
rrt committed
449

Simon Marlow's avatar
Simon Marlow committed
450
extern void __stginit_Adder(void);
rrt's avatar
rrt committed
451

rrt's avatar
rrt committed
452
453
static char* args[] = { "ghcDll", NULL };
                       /* N.B. argv arrays must end with NULL */
rrt's avatar
rrt committed
454
455
456
457
458
459
460
461
462
463
BOOL
STDCALL
DllMain
   ( HANDLE hModule
   , DWORD reason
   , void* reserved
   )
{
  if (reason == DLL_PROCESS_ATTACH) {
      /* By now, the RTS DLL should have been hoisted in, but we need to start it up. */
ken's avatar
ken committed
464
      startupHaskell(1, args, __stginit_Adder);
rrt's avatar
rrt committed
465
466
467
468
      return TRUE;
  }
  return TRUE;
}
469
</programlisting>
rrt's avatar
rrt committed
470

471
Here, <literal>Adder</literal> is the name of the root module in the module
rrt's avatar
rrt committed
472
473
474
tree (as mentioned above, there must be a single root module, and hence a
single module tree in the DLL).

rrt's avatar
rrt committed
475
476
Compile this up:

477
<screen>
sof's avatar
sof committed
478
ghc -c dllMain.c
479
480
481
</screen>
</para>
</listitem>
rrt's avatar
rrt committed
482

483
484
<listitem>
<para>
rrt's avatar
rrt committed
485
486
Construct the DLL:

487
<screen>
488
ghc &ndash;&ndash;mk-dll -o adder.dll adder.o adder_stub.o dllMain.o
489
</screen>
rrt's avatar
rrt committed
490

491
492
</para>
</listitem>
rrt's avatar
rrt committed
493

494
495
496
497
<listitem>
<para>
Start using <function>adder</function> from VBA-&ndash;&ndash;here's how I would
<constant>Declare</constant> it:
rrt's avatar
rrt committed
498

499
<programlisting>
rrt's avatar
rrt committed
500
Private Declare Function adder Lib "adder.dll" Alias "adder@8"
rrt's avatar
rrt committed
501
      (ByVal x As Long, ByVal y As Long) As Long
502
</programlisting>
rrt's avatar
rrt committed
503
504
505

Since this Haskell DLL depends on a couple of the DLLs that come with GHC,
make sure that they are in scope/visible.
506
</para>
rrt's avatar
rrt committed
507

508
<para>
rrt's avatar
rrt committed
509
Building statically linked DLLs is the same as in the previous section: it
510
suffices to add <option>-static</option> to the commands used to compile up
rrt's avatar
rrt committed
511
the Haskell source and build the DLL.
512
</para>
rrt's avatar
rrt committed
513

514
</listitem>
rrt's avatar
rrt committed
515

516
</itemizedlist>
rrt's avatar
rrt committed
517

518
</sect2>
rrt's avatar
rrt committed
519

Simon Marlow's avatar
Simon Marlow committed
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
<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>

<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);

   // do any other initialization here and
   // return false if there was a problem
   return HS_BOOL_TRUE;
 }

 LEWIS_API void lewis_End(){
   hs_exit();
 }

 LEWIS_API HsInt lewis_Test(HsInt x){
   // use Haskell functions exported by
   // modules Bar and/or Zap

   return ...
 }

 } // extern "C"

and some application which used the functions in the DLL would have a main() function like:

 // MyApp.cpp
 #include "stdafx.h"
 #include "Lewis.h"

 int main(int argc, char *argv[]){
   if (lewis_Begin()){
      // can now safely call other functions
      // exported by Lewis DLL

   }
   lewis_End();
   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>
</sect2>

628
</sect1>
629
</chapter>
630
631
632

<!-- Emacs stuff:
     ;;; Local Variables: ***
633
634
     ;;; mode: xml ***
     ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***
635
636
     ;;; End: ***
 -->