ezwinports -- MS-Windows ports of Unix and GNU software
This project is a collection of ports to MS-Windows of GNU and Unix
software packages, which either don't have precompiled Windows
binaries available, or whose existing ports are buggy or broken or
outdated. All the ports are built using the 32-bit MinGW development
environment, with or without MSYS. (MSYS is used to run the
`configure' scripts and the subsequent build with the Make utility,
where these make heavy use of Unix-isms.)
The ports are not necessarily of the "latest and greatest" versions
you can find upstream. But they are well tested and "work for me" in
daily usage (on a couple of XP SP2/SP3 boxes and on Windows 7).
For each package, you will find here 2 compressed archives: a source
archive and a binary archive.
The binary archive includes all the executable programs, dynamic
libraries, header files, and all the documentation files -- in
general, everything that is installed by running "make install". For
those of you who don't have Groff installed, I've included formatted
versions of man pages, so just a port of Less should be enough to
display them. If the executable programs need additional DLLs, they
are also included, to make the zip archive self-contained.
To install a binary archive, simply unzip it, preserving the directory
structure recorded in it, and make sure the 'bin' directory is on your
Path. If you already have a public 'bin' directory, unzip the binary
archive from that 'bin's parent directory. The other directories,
like 'include', 'lib', and 'share' are populated with the rest of the
package; in particular, the man pages are in 'share/man' and
'share/cat', and the Info docs in 'share/info'. It is advisable to
unpack all the archives you download from this site into the same
tree: this will ensure all the packages work seamlessly together.
The source archive includes everything needed to build the binaries;
in particular, the sources are already patched with all the changes
necessary for the Windows port to function correctly. The source
archive also includes the results of configuring the package: the
generated Makefile's, the famous config.h header file, etc. It is
possible that some of the generated files includes traces of my local
directory tree (e.g., I have a Unix-style directory hierarchy under
`D:\usr'), in which case you may need to edit those files to adapt
them to your machine. In most case, but not always, there's a "diffs"
file somewhere that shows the changes I made relative to the original
Most of the ports use a small number of DLLs for libraries, such as
libiconv or libintl, which I didn't build myself. The GPL requires
that the sources of those libraries be available from this very site.
Therefore, I provide those sources in the Dependencies/ subdirectory
of this directory. The file README.txt there explains how to find the
source distribution for the library you are interested in.
Here's a short description of each package you will find in this
This is a port of the official RCS v5.7.13 source to MS-Windows. I
did this port because the existing GnuWin32 port was broken: any RCS
command that required running another program as a subprocess (e.g.,
rcsdiff) would either crash or produce an error message, due to an
unhandled problem in the Windows versions of the spawn* library
This is a Windows port of the `flip' utility, which converts newline
format between Unix LF and DOS/Windows CR-LF conventions. Its home
page is http://packages.debian.org/sid/flip. I like this utility
better than unix2dos/dos2unix, because (a) it's a single program,
(b) it doesn't try to convert character sets, (c) it changes files
in-place while keeping their time stamp intact, and (d) it keeps its
claws off any binary files, so it's safe.
This is a Windows port of the GNU Texinfo package, version 4.13a.
My reasons for making this port are (1) the makeinfo.exe available
from GnuWin32 crashes for any non-trivial Texinfo source; and (2)
info.exe refuses to work on Windows because no one bothered to make
its terminal display code work on Windows. This port solves both of
This is a Windows port of the ministat program, you can find the
original sources here:
AFAIK, there's no Windows port of this program anywhere. The
program is handy for computing statistics and significance testing
of a series of measurements, e.g. running times of some program (for
A Unix `man' command for Windows. Unlike all the other packages on
this page, this one is not a port. It is a clone of its Unix
namesake, and has absolutely no code common with its cousins. I
wrote it originally as part of the DJGPP project
(http://www.delorie.com/djgpp/), and later updated it to compile
with MinGW and run on MS-Windows as a native Windows program.
If you want to view unformatted man pages, you will have to install
a port of Groff (it is available from this page, see below).
A Windows port of GNU Grep.
The latest port available from GnuWin32 is of version 2.5.4, which
was released in Feb 2009, quite some time ago. Also, it always
annoyed me that color highlighting of Grep matches is not available
on MS-Windows. This port of the latest release 2.10 of Grep fixes
To use Perl-style regular expression, Grep needs to be built with
libpcre, so you have this as a bonus below.
Library of Perl-compatible regular expressions. I needed this to
build Grep capable of "grep -P" mode.
A Windows port of GnuTLS 3.0.9. I needed this to build wget
The previous widely available Windows port of GnuTLS was of version
2.11, which is now a major release ago. So I thought it was high
time to have a newer version.
The binary package includes both static and dynamic libraries.
A Windows port of wget 1.13.4.
The GnuWin32 port is of version 1.11.4, which was released a few
years ago. This is the latest released version, as of this writing
A Windows port of file 5.09.
The latest GnuWin32 port is of version 5.03, released in May 2009.
It has a subtle bug that breaks libtool, and also a few Windows
specific gotcha's (e.g., try "file NUL" or "file -"). This port of
the latest upstream release fixes those bugs.
Windows ports of, respectively, GMP (the GNU Multiple Precision
Arithmetic library), Libidn (the GNU IDN library), Nettle (a
cryptographic library), and p11-kit (a package to load and enumerate
PKCS#11 cryptographic modules). I needed them to build GnuTLS and
wget, but they can be useful on their own right, so I provide them
A Windows build of libxml2 2.7.8.
The available Windows ports are compiled with MSVC, which means they
are not 100% compatible with MinGW. The libxml2 sources include a
JScript configuration script, suitable for running with cscript, and
a bunch of Makefile's to go with it. But it looks like this
suffered some bitrot, and it doesn't support running the test suite,
which was important for me to make sure the build is dependable.
So instead of using this Windows-specific stuff, I configured the
package with MSYS and built it using the Posix configury. The
result passed all the tests.
To compile and link programs against libxml2, you will need to
install libiconv, whose headers and import libraries need to be
available to the compiler and linker. You can find the MinGW port
of libiconv on the MinGW site:
(The libxml2 binaries found here were linked against the
A Windows port of GNU Which v2.20
GnuWin32 does offer a port of this latest version of Which, but it
has a few bugs. This port improves on that one:
. Under -a, it shows the executables in exactly the same order as
the shell would look them up.
. It behaves like on Unix when run by a privileged user.
. Supports home directories both if pointed to by the HOME
environment variable and (if HOME is not set) if pointed to by
the USERPROFILE variable.
. Is more consistent in its support for backslashes and forward
. It fixes a couple of minor bugs.
This second upload fixes a bug whereby 'which' would sometimes crash
when invoked with the -a switch.
A Windows port of Lzip, "a lossless data compressor based on the
The only port of Lzip I'm aware of is the one available from the
Lzip download page, which is of version 1.11, quite old. Here you
have the latest version as of this writing.
A Windows port of xz, lzma, and liblzma.
With many GNU projects starting to use .tar.xz archive as their only
format of tarballs, having this on your development box is really a
A Windows port of bzip2 and of libbz2.
GnuWin32 has only a very old version. MinGW does offer version
1.0.6, but it was built in a way that makes the binaries dependent
on the DLL version of libgcc. This means that anyone redistributing
these binaries would have to also provide the humongous 75-MB source
tarball of GCC, to comply with the GPL license. I think this is
ridiculous, so I made my own port, which is free of this
restriction. While at that, I also fixed a couple of bugs in the
existing ports (e.g., try "bunzip2 -c SOMETHING.bz2 > nul", which is
important for measuring decompression speed, if for nothing else).
Note that bzip2.exe in this port is statically linked with libbz2
library, so it doesn't need the DLL to run -- another advantage.
A Windows port of libarchive and of bsdtar and bsdcpio programs.
GnuWin32 has an old version 2.4.12 released in 2008. MinGW offers a
newer version 2.8.3, but it is still old (more than a year ago).
This is the port of the latest release, and it fixes a few upstream
This latest release of bsdtar is really wonderful: it supports most
every format of compressed archives on Earth. gzip, xz, lzma, zip,
rar, 7-zip, even CAB! You name it, it supports that. More
importantly, it does all compression and decompressing in memory,
without invoking external programs, so it's faster (but still uses
the same algorithms and code via the corresponding libraries it
links against). It also supports UTF-16 file names on Windows,
therefore you can now unpack archives created in other Windows
locales, and still have the files unpack under correct names.
In general, the degree of Windows support is very good in this
package, so I think I will abandon GNU Tar, whose current
maintainers are much less friendly to Windows support, and switch to
this package instead.
A Windows port of mairix, a program for indexing and searching email
As far as I know, there are no native Windows ports of mairix
available. I needed it to be able to search my vast email archives
using the Emacs mairix-el package. I only tested this port with the
mbox mail folders, which is all I have, so caveat emptor.
A Windows port of ncurses 5.9. I don't think there's a native
Windows port of this available anywhere. I needed it for Readline
and for Gawk (below), but it should be useful for many other
programs as well. AFAIK, there was never a curses library for
Windows, except for a very old port of PDCurses.
A Windows port of the GNU Readline library. The versions offered by
GnuWin32 are very old. This is the port of the latest release, and
it is built with ncurses, so no Windows-specific hacks were necessary
in the sources.
A Windows port of the OpenSSL package. I needed it for porting XAR
(below), and the build offered by openssl.org seems to be compiled
with MSVC and also it was unclear to me which of the various packages
to install for my needs. So I just built my own.
A Windows port of XAR, the extensible archiver from
http://code.google.com/p/xar/. I'm not aware of any Windows ports of
this available, and I'm not surprised: the code is full of stuff that
is only available on latest Posix systems; porting that was quite a
job. The main reason why you'd be interested in the result is that
it has full support for NTFS security, and can record and restore the
entire NTFS security descriptor of each file, complete with its
owner, primary group, and DACL. (Caveat: use this feature and the
associated -p command-line option with caution: if you don't know
what you are doing, you can easily restore files in a way that will
prevent you from modifying or deleting them.)
This is a Windows build of the GNU MPFR library version 3.1.0 with
the cumulative patches as of 12 Mar 2012 applied. I needed this for
building a development version of Gawk, but I understand many
projects that use extended-precision calculations can use this
(together with GMP, upon which MPFR is built). MinGW, the only
alternative, offers a relatively old port, which is at least partly
dependent on the GCC runtime DLL.
This is version 2.65 of GNU Autoconf configured for use with the MSYS
environment. The MSYS site does not offer a download of this
version, which is needed for configuring GNU Emacs. Unzip the
archive from the root of the MSYS tree (_not_ the MinGW tree!).
This is version 1.11.6 of Automake configured for use with the MSYS
environment. It is required for configuring and building GNU Emacs
from its bzr repository. Unzip the archive from the root of the MSYS
tree (_not_ the MinGW tree!).
This is a Windows port of GNU ID Utils. ID Utils and the
corresponding Emacs front end is an essential part of my Emacs-based
development tool-chain. Without ID Utils, there's no easy way of
finding your ways in a large and complex software project.
Unfortunately, the port available from GnuWin32 is broken and does
not work (mkid emits an error message and quits). So I made my own
Windows port of ID Utils version 3.2d (an interim version that was
only available from alpha.gnu.org in the past, and now deleted even
from alpha.gnu and not available anymore on any GNU site, although
you can still find it on the net if you are persistent enough).
That port was done in May 2005. Later, I upgraded that port using
the user-visible changes from ID Utils 4.5, because I needed ID
Utils to support Java and Lisp, which was not available in v3.2d.
If you wonder why not just port ID Utils 4.6, then you should know
that I found out to my astonishment that 99% of the changes between
4.6 and 3.2d have no user-visible effect. The bulk of the changes
were "portability enhancements". As result of these "enhancements",
the number of files imported from gnulib (in the lib/ subdirectory)
went up from 38 to 143(!), the configury of the package became much
more complex, but the net gain for users in terms of functionality
was almost nil. Needless to say, none of the real problems that
made the Windows port buggy were fixed by these "enhancements"...
So instead of porting ID Utils 4.6, I copied the few changes that
actually contributed to user-visible functionality to the old 3.2d
sources, added to lib/ 3 files that were required for those changes,
fixed a couple more of Windows-related problems (e.g., that `sbrk' is
not available, and therefore "mkid -s" would not display meaningful
memory-usage statistics), and that's what I have now. I call this
version 3.2.99, because its source code base is still largely 3.2
vintage. The ChangeLog file in the top-level directory describes the
Windows-related changes I made in more detail. The file
DIFFS-3.2d-3.2.99.dif shows all the diffs wrt version 3.2d, which
include modifications copied from ID Utils 4.5. I also modified the
Copyright notices of all the old files, to have their years extended
This 2nd upload fixes an upstream bug (only corrected in ID Utils
4.6) whereby "lid -F" would mishandle open-ended ranges like
2000.. or ..200.
This is a Windows port of GNU Findutils 4.2.30. It includes all the
binaries in the original distribution, even those, such as code.exe,
frcode.exe, and bigram.exe that you are not supposed to need. I
made this port because the GnuWin32 port of v4.2.20 had several
grave problems: find.exe was abysmally slow, xargs.exe didn't work
at all, and neither did locate.exe. This port includes updatedb.bat,
which is a stripped-down replacement for the original updatedb Unix
shell script. Please note that xargs.exe in this distribution has
some issues that cause it to fail sometimes. But find.exe and
locate.exe work flawlessly for me for several years.
This fifth upload solves a bug whereby 'find' would sometimes
infloop when some of the directories it traverses are symlinks to
other directories. The solution is to never descend into a
directory that is a symlink (i.e., this port always behaves as if
the -P option was specified).
As an additional bonus, this port includes 64-bit binariesin a
separate findutils-4.2.30-4-w64-bin zip file, prepared by Erwin
Waterlander <email@example.com>. If you are running a 64-bit
Windows version, you may wish to use these 64-bit executables, as
they are about 5 times faster than the 32-bit ones.
This is a Windows build of the latest version 5.2 of the GNU Texinfo
package. Note that makeinfo was reimplemented in Perl in this
version, which made it about 18 times slower. So I recommend to keep
makeinfo.exe from version 4.13 around for the time being. If you do
want to use this new makeinfo, you will need to install Perl.
This is a Windows build of the latest version 1.2.8 of the venerable
zlib library. MinGW provides this version also (under the name
libz-1.dll), but it depends on GCC's libgcc_s_dw2-1.dll, which has
the same problems as described under bzip2 above, and in addition
tends to crash programs at exit (due to a grave bug in the libgcc
DLL). So I provide here a build that don't have this problem.
You should be able to replace your older zlib1.dll with this
version, as the latter is binary-compatible with the old one.
This second upload fixes a problem with the zlib.pc file which would
fail compilation and linking against zlib in packages that use
pkg-config to determine the necessary compilation and link flags.
A Windows build of the latest version 4.0.3 of TIFF library and
Available ports of this library are way outdated.
This is a Windows build of the latest version 2.40.1 of librsvg, the
library for manipulation, conversion, and viewing of SVG images.
The only other existing port of librsvg that is known to me is from
the GTK project, but is outdated, uses much more dependencies that
is strictly needed on Windows, and also involves a small "DLL hell",
since various dependencies need different versions of the same
library (freetype and libpng). By contrast, this port requires only
the minimal set of dependencies (see below), and only one version of
This second upload fixes a problem with packaging the binary
archive, which could result in librsvg not working unless installed
Pango is a library for laying out and rendering of text, with an
emphasis on internationalization. This is a Windows build of the
latest version 1.36.1. It is required for librsvg (see above).
This second upload fixes a problem with packaging the binary
archive, which could result in Pango not working unless installed in
This is a Windows build of the latest version 1.12.16 of Cairo, a 2D
graphics library with support for multiple output devices. This
minimal build provides only the win32 back-end and a minimal set of
"surfaces" (including SVG) which are are needed for librsvg (above).
A Windows build of the latest version 0.32.4 of Pixman, a library
that provides low-level pixel manipulation features. It is required
for Cairo, and thus needed for librsvg (above).
This is a Windows build of libcoroco, a standalone CSS2 parsing and
manipulation library. It is required by librsvg (above).
The Gdk Pixbuf is a toolkit for image loading and pixel buffer
manipulation. This is a Windows build of the latest version 2.30.2
of Gdk Pixbuf. It is needed for librsvg (above).
A Windows build of the latest version 2.38.2 of Glib, a set of
low-level libraries useful for providing data structure handling for
C, portability wrappers and interfaces for such runtime
functionality as an event loop, threads, dynamic loading and an
object system. It is required for librsvg (above).
This is a Windows build of version 3.0.13 of the libffi library,
which provides a portable, high level programming interface to
various calling conventions. It is required for Glib, and therefore
indirectly required by librsvg (above).
LZO is a data compression library which is suitable for data
decompression and compression in real-time. This is a Windows build
of its latest version 2.06. This library is required for one of the
components of Cairo (above).
If you use git (msysGit) on Windows, you will have merge problems
when merging from branches that modified ChangeLog files. This
merge driver solves those annoying problems, but msysGit
distribution doesn't provide it for some reason, and there doesn't
seem to be a build-ready source archive available anywhere.
Building out of gnulib git repo, where the sources live, on a
Windows system is not for the faint at heart. So here you have the
package, complete with sources and binaries. See the file
README.txt for installation and configuration instructions.
This second upload fixes a bug whereby the merge would always
produce a file with DOS-style CR-LF end-of-line (EOL) format, even
if the original files used Unix EOLs. This is an upstream bug,
fixed in this port.
This is a Windows port of Hunspell v1.3.2. Hunspell
(http://hunspell.sourceforge.net/) is a spell-checker with support
for peculiarities of many languages and with Unicode character
codepoints support out of the box. To the best of my knowledge,
there's no other Windows port of Hunspell. In addition, this port
includes fixes for bugs, both Windows-specific and
platform-independent. The result works well for me as the back-end
of the spell-checking features in Emacs. The interactive
curses-based user interface also works, although (due to limitations
of the ported ncurses) only characters in the current ANSI codepage
The binary distribution includes dictionaries for US English and UK
English. You can find the dictionaries for other languages on the
Internet; install them into share/hunspell sub-directory of your
Hunspell installation directory.
This third upload fixes a subtle issue with running Hunspell under
Emacs 24.4 and later, whereby the default dictionary would not be
set correctly during initialization. All the previous bugfixes are
also included, such as failure to rename the temporary file with the
text corrected by spell-checking to the original name of the file
submitted to the speller, and a couple of other minor bugs reported
lately to the Hunspell bug tracker.
A Windows build of the latest version 4.1.1 of Gawk. This was linked
against Readline, and so has a fully functional command-line editing
interface, including command history, when using the Gawk debugger.
Also, this port was linked against the MPFR library, and so supports
arbitrary-precision floating-point arithmetics, when invoked with the
-M or --bignum command-line options. See the node "Gawk and MPFR" in
the manual for the details. The new dynamic extensions feature is
also supported, see the node "Dynamic Extensions" in the manual.
Last, but not least, this version supports network and co-routines.
This is a Windows build of the latest version 5.1.0 of the giflib
library. Gnuwin32 has only an ancient version 4.1.4, and I didn't
find any Windows port of the 5.x series. (The 'lua-files' project
seems to have a binary, but no sources.) The few problems that I
found and corrected while testing the previous port were accepted
upstream, so this release builds with MinGW out of the box; thus no
This is a Windows build of the latest version 1.6.12 of libpng, the
official PNG image library. It includes several important security
and stability fixes, and is binary-compatible with the previous
1.6.x releases, so you are well advised to upgrade.
As GnuWin32 libpng ports are very old, and even the GTK site falls
behind, there's a need to have the latest PNG library available for
Windows. So here you have that.
This is a Windows build of the latest version 9a of jpegsrc, the
IJG's library for JPEG image compression.
Like with libpng, it's high time Windows users had the latest JPEG
library available to them.
This is a small library to encrypt and decrypt a block of data.
This is needed for Guile and GDB below.
This is a Windows build of the Boehm-Demers-Weiser garbage collector
(a.k.a. "Boehm GC"). It is used by Guile below. I'm not aware of
any Windows binaries of this library. The library was built with
Win32 threads (_not_ pthreads!), so if you need to use it with a
package that uses pthreads, these binaries are not for you.
This is a Windows port of libunistring 0.9.3, a library that
provides functions for manipulating Unicode-encoded strings, and for
manipulating C strings according to the Unicode standard. The MinGW
site offers a binary distribution of the same version, but it is
severely broken on Windows: it cannot be used after setting a
non-default locale by calling 'setlocale'. This port fixes the bugs
which cause this breakage, and which render Guile (below) unusable
for i18n features.
This is a Windows build of the latest version 3.1 of the libffi
library, which provides a portable, high level programming interface
to various calling conventions. It is required for Guile below.
Note that the DLL which comes with this version is libffi-6.dll, so
it does NOT replace (and does not conflict with) libffi-5.dll that
came with version 3.0.13; you still need the latter for librsvg and
Glib, if you downloaded them.
This is a Windows port of the latest Guile 2.0.11. It is heavily
patched wrt the upstream sources, and supports all features that can
be reasonably supported on MS-Windows. One notable exception is
threads: this port was configured without threading support, because
Guile built with threads (using the Windows port of pthreads) is
unusable: it hangs or crashes in many simple and trivial programs,
and cannot even compile its own Scheme files. The Guile binary and
library in this distribution pass all the tests in the test suite.
I'm not aware of any reliable Windows port of Guile anywhere.
If you install this anywhere but d:/usr, you will need to set 2
where "x:\foo" is the directory from which you unzipped the Guile
binary zip file.
This 2nd upload fixes a couple of minor problems in the code, and
also includes DLL shared libraries in addition to static libraries.
A Windows build of the latest version 7.8 of GDB. The MinGW site
offers only an outdated version 7.6.1, which was on top of that
built without Python support. Here you have the latest release that
supports Python. It also includes the lately added Guile support.
One caveat: you will have to download and install Python 2.6.6 from
https://www.python.org/download/releases/2.6.6/; gdb.exe in this
archive depends on the Python library and DLL, and will not run
without it being available on your system. (I don't want to
distribute Python binaries, because then I would also need to
provide the Python sources from this site, which is way too much.)
If you install this anywhere but d:/usr, you will need to set 2
where "x:\foo" is the directory from which you unzipped the GDB
binary zip file. These variables are required for the Guile support
in GDB to be able to initialize itself.
If GDB complains at startup about being unable to load Python
modules, you may need to set the PYTHONPATH environment variable to
point to your Python 2.6.6 installation, like this:
(assuming you installed Python in C:\Python26).
This 2nd upload includes all the Guile support files, so you no
longer need to install Guile separately.
This is a MinGW build of the latest version 4.1 of GNU Make. There
are 2 different binary zip files here: with and without Guile
support. The zip without Guile is much smaller, so if you are sure
you won't need Guile scripting in Makefiles any time soon, I
recommend to install the "without-guile" version. The sources for
both these binary zips are in make-4.1-w32-src.zip.
For the "with-guile" version, if you install it anywhere but
d:/usr, you will need to set 2 environment variables:
where "x:\foo" is the directory from which you unzipped the Make
binary zip file. These variables are required for the Guile support
in Make to be able to initialize itself.
A Windows port of the latest release 1.22.3 of GNU Groff.
I successfully used Groff-1.19.1 from GnuWin32 for several years.
However, the latest man pages emit more and more error messages,
because Groff 1.19 doesn't support several new roff features.
GnuWin32 offers version 1.20, but it was released in Jan 2009, and
at least its source GnuWin32 distribution suspiciously lacks several
Therefore, I built the latest release 1.22.3 using MSYS and MinGW,
and here you have the result.
Note: this distribution was built without Ghostscript being
installed, so the HTML back-end (grohtml) and the PDF formatter
(pdfroff) were not tested, and might even not work due to some
missing file or font.
This second upload fixes subtle problems with using Windows-style
file names with backslashes on Groff command lines. The changes to
fix that were accepted upstream, so the next release will have them
out of the box.