* Packages are often delivered as a .tar or .tar.gz file, see [[How to unpack a tar file in windows]]

* Packages are often delivered as a .tar or .tar.gz file, see [[How to unpack a tar file in windows]]

−

* Source files from Unix(-like) systems have lines terminated with Line Feed only; to convert them to MS-DOS format (as needed by Windows), use the <code>unix2dos</code> command (from the [http://sourceforge.net/projects/mingw/files/ mingw-utils] package). For more information, give command: <code>unix2dos --help</code>

+

The following two items are somewhat spurious, this is not strictly necessary, it only causes issue if file IO is done in textmode rather than binary, since the whole business of line endings stems from this.

+

+

* Source files from Unix(-like) systems have lines terminated with Line Feed only; to convert them to MS-DOS format, use the <code>unix2dos</code> command (from the [http://sourceforge.net/projects/mingw/files/ mingw-utils] package). For more information, give command: <code>unix2dos --help</code>

* To convert a set of files to MS-DOS format (note: this might damage binary files):

* To convert a set of files to MS-DOS format (note: this might damage binary files):

Line 51:

Line 53:

* Make sure your Haskell compiler (e.g. GHC) and tools are on your system path: http://www.computerhope.com/issues/ch000549.htm

* Make sure your Haskell compiler (e.g. GHC) and tools are on your system path: http://www.computerhope.com/issues/ch000549.htm

−

* GHCi: Using GHCi from a DOS box sucks. Using it from withing shell mode in Emacs sucks a lot less - do 'M-x shell' in emacs, then type 'ghci'.

+

* GHCi: Using GHCi from a Win32 console is not everyones cup of tea. Using it from within shell mode in Emacs sucks a lot less - do 'M-x shell' in emacs, then type 'ghci'.

* GHCi on Cygwin: When running GHC under a Cygwin shell on Windows, Ctrl-C sometimes doesn't work. A workaround is to use the rlwrap program to invoke ghci : In addition to proper Ctrl-C, you also get emacs (or vi) key bindings and command history across sessions, which saves you a load of typing.

* GHCi on Cygwin: When running GHC under a Cygwin shell on Windows, Ctrl-C sometimes doesn't work. A workaround is to use the rlwrap program to invoke ghci : In addition to proper Ctrl-C, you also get emacs (or vi) key bindings and command history across sessions, which saves you a load of typing.

Line 57:

Line 59:

* If a package depends (either directly or indirectly) on the <code>unix</code> package, you cannot compile it on Windows; see the [http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/unix reversed dependencies list]. However, sometimes, the dependency changes per platform; see for example the [http://hackage.haskell.org/packages/archive/directory/1.0.1.0/directory.cabal cabal file] of the <code>directory</code> package

* If a package depends (either directly or indirectly) on the <code>unix</code> package, you cannot compile it on Windows; see the [http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/unix reversed dependencies list]. However, sometimes, the dependency changes per platform; see for example the [http://hackage.haskell.org/packages/archive/directory/1.0.1.0/directory.cabal cabal file] of the <code>directory</code> package

+

* If you are missing or need to distribute libraries with an application, the correct place to put them is not in \WINDOWS\System32 as once was the practice in the early days of Windows. All sane applications/installers keep their own private dependencies in the application directory. Eg, if the user has chosen to install your application to C:\Program Files\Foo then it is best to install any DLLs in the same location.

2 Compilers/interpreters

3 Tools for compilation

As some of the packages contain Unix/Linux specific scripts/commands, you need MinGW and MSYS to simulate a Unix environment. In some cases you need Cygwin instead. If you use msysgit on Windows already, all you need to do is add MinGW to your path.

If you need to link to C-software, define an environment variable C_INCLUDE_PATH that lists the directories where the header files can be found. For linking the libraries you need to define an environment variable LIBRARY_PATH as well, listing the directories where .a and .lib files can be found. In case C++ software must be compiled, define CPLUS_INCLUDE_PATH to list the directories with C++ header files.

The following two items are somewhat spurious, this is not strictly necessary, it only causes issue if file IO is done in textmode rather than binary, since the whole business of line endings stems from this.

Source files from Unix(-like) systems have lines terminated with Line Feed only; to convert them to MS-DOS format, use the unix2dos command (from the mingw-utils package). For more information, give command: unix2dos --help

To convert a set of files to MS-DOS format (note: this might damage binary files):

C:\MSYS\1.0\bin\find . -type f -exec unix2dos {} ;

Note: the find command included in MSYS is different from the MS-DOS find command, therefore, you need to specify the entire path to this command.

5 Special tips and tricks for Windows

GHCi: Using GHCi from a Win32 console is not everyones cup of tea. Using it from within shell mode in Emacs sucks a lot less - do 'M-x shell' in emacs, then type 'ghci'.

GHCi on Cygwin: When running GHC under a Cygwin shell on Windows, Ctrl-C sometimes doesn't work. A workaround is to use the rlwrap program to invoke ghci : In addition to proper Ctrl-C, you also get emacs (or vi) key bindings and command history across sessions, which saves you a load of typing.

If a package depends (either directly or indirectly) on the unix package, you cannot compile it on Windows; see the reversed dependencies list. However, sometimes, the dependency changes per platform; see for example the cabal file of the directory package

If you are missing or need to distribute libraries with an application, the correct place to put them is not in \WINDOWS\System32 as once was the practice in the early days of Windows. All sane applications/installers keep their own private dependencies in the application directory. Eg, if the user has chosen to install your application to C:\Program Files\Foo then it is best to install any DLLs in the same location.

6 Direct downloads

6.1 Haskell

Below a list of binary packages packages for Windows. To be sure you get the last version of each, it is best to download the source from Hackage and compile.