Surviving Windows as a Unix user: A glossary
Here's a summary of words you will see while working on GHC on Windows. Some other helpful background can be found on
- the How does msys2 differ from Cygwin article on the msys2 wiki.
- This Stack Overflow question discussing the relationship between msys and msys2
msys2 (the distribution)
msys2 is a software distribution packaging a number of components including,
- the msys2 runtime (see below)
- a basic UNIX-like command-line environment
- a toolchain for compiling code written for a POSIX environment (linking against the msys2 runtime)
- 64- and 32-bit
msys2 (the runtime)
The msys2 distribution is built upon the
msys2 runtime, which is a fork of the Cygwin runtime. The runtime provides basic POSIX APIs, making it possible to run software written to run on a POSIX-like system on Windows.
The msys2 and Cygwin runtimes used to differ strongly, but have been converging (see https://github.com/Alexpux/MSYS2-packages/blob/master/msys2-runtime/PKGBUILD for the current patches). Most of the remaining differences are to make the provided environment a bit closer to Windows than Cygwin's behavior.
msys2 (the toolchain)
The msys2 distribution includes a compiler toolchain which can be used to compile code written for a POSIX environment. It can be found in
Executables compiled with this toolchain will link against the
msys2 runtime. Consequently this is not the toolchain to use to build GHC. Instead use the
mingw-w64 toolchain (see below).
Cygwin (the runtime)
Cygwin is a runtime library providing a POSIX-like environment, allowing software written for POSIX systems to run on Windows unchanged. The
msys2 distribution that we use in GHC doesn't use Cygwin, but instead the
msys2 fork (see above). Cygwin differs from
msys in that it seeks to provide complete Linux emulation in user-mode; in contrast,
msys2 merely seeks to provide enough POSIX support to be able to use toolchains such as
mingw-w64 to make native binaries.
Cygwin (the distribution)
Cygwin is also a distribution built upon the
Cygwin runtime providing a Linux-like environment on Windows. We don't use it; instead we use the msys2 distribution.
Mingw-w64 is a compiler toolchain based upon
gcc targeting Windows systems which is packaged with the
msys2 distribution. It started as a fork of the
mingw toolchain. A fair amount of useful information about
mingw-w64 can be found on the project's wiki.
Executables produced with the
mingw-w64 toolchain will link only against
msvcrt and a few native Windows libraries (e.g.
mingw is a compiler toolchain based upon
gcc targeting Windows systems. The project is now unmaintained.
mingw is not used by
msys2 distribution used by GHC; instead it packages the
msys (short for "minimal system) is a component of the
mingw project which provides Windows ports of a lightweight Unix-like shell environment. It does not provide a compiler toolchain; this is provided by
Note that GHC uses neither
msys; rather we use
The Microsoft Visual C runtime. This is the
libc of the Windows world. It also offers a number of POSIX compatibility routines (e.g.
exec) which aren't POSIX compliant.
mintty is a terminal emulator shipped with the
msys2 distribution (and Cygwin). It's not so great; you probably want to use something else (e.g. ConEmu).
Windows Subsystem for Linux (WSL, also known as the Linux on Windows (LoW) or Drawbridge) is a project undertaken by Microsoft seeking to add a Linux subsystem to the Windows kernel, allowing full user-mode emulation of a Linux environment. Currently we don't use LoW for GHC development. It exhibits a few infelicities relative to "typical" POSIX systems (e.g. file locking, and mmap performance).
Version 2 of WSL abandons the user-space emulation approach in favor of full hypervirtualisation and various driver- and userspace-level interoperability bridges.
- Dependencies is a very useful tool for diagnosing dynamic linking issues
- CFF Explorer is useful for exploring the structure of portable executable objects
- In the Windows SDK:
gflags.exetool can be used to enable "loader snaps" for a particular executable. When enabled, the dynamic linker will emit debug output when the executable is run under
windbgis the Windows debugger, apparently last updated circa 1992
- The version of
windbgin the Windows Store appears to be much better than that in the SDK (even supporting time-travelling debugging)
x64dbgis an alternative FOSS debugger
- The sysinternals tools
DebugViewallows one to view debug output from the system (e.g. the loader snaps mentioned above) without Windbg
- Process Explorer provides a nice view onto the process tree and process state
Process Monitor provides an
strace-like view of system calls
- Windows Performance Record/Analyzer is another mechanism capable of tracing system calls
- ConEmu is a decent terminal emulator for Windows
this gdb fork can open minidump files, as produced by GHC's
Collecting a crash dump
If you have a program that is crashing, one helpful way to attack the problem is to generate a crash dump (similar to a core dump on Unix-like operating systems) for inspection in a debugger (e.g. WinDbg).
There are a few ways to accomplish this:
- GHC itself can generate a dump in "minidump" format with the
+RTS --generate-crash-dumpsflag. This can be opened with WinDbg.
gflags.exeutility (specifically the "Silent Process Exit" tab) can be used to enable dumps globally on crashing processes.
procdump.exeSysinternals utility can be used to collect a dump from a single process.