To reply to an earlier point of Andrew's (I can't find the quote now, sorry), one of the biggest difficulties developers face on Windows is the lack of common install locations/practices. Windows software is usually distributed as a binary, which may or may not include header files. These files may be installed in any of numerous locations, such as C:\Program Files\, the user's home directory, the system directory, or directly off the drive root. Defaults are not common among different programs or even versions of programs, and install locations are frequently changed by users anyway. Libraries and headers are usually not located on the PATH environment variable, and there's no standard INCDIR or LIBDIR variable either. While it is Cabal's job to find the location of necessary libraries, header files, and tools, there simply is no feasible way to do so on Windows without searching most of the hard drive. Even then, there's no guarantee the right version will be found (google "DLL Hell" for examples of the chaos that ensues). This is particularly true for developers, who frequently have multiple versions of libraries installed. The only workable approach is to have users specify the locations of these files, which unfortunately requires more sophistication than can be expected of most Windows users (and even some Windows developers). On a related matter, many packagers resort to using configure-style configuration setups to assist with binding to C libraries. Cabal is now sophisticated enough to handle many of these steps (although not all), however packagers may not have had an opportunity to update their build process to remove the dependency on "configure". These packages will continue to require cygwin or mingw for the "configure" step. One last wrinkle: many distributors of C libraries do not have Windows machines available to test, and (understandably) have little interest in supporting a platform they don't have and aren't familiar with. As a result, many C libraries are not well supported on Windows and require somebody familiar with gnu build tools (i.e. gcc, make, and autoconf) to be usable on Windows *at all*. This means that, as a Haskell developer wanting to use these libs, you need to use gnu build tools because you're not just binding to the library, you're maintaining a Windows port of it. C and unix are pretty much designed to work together, and have been for decades, so I think it's reasonable to expect that Windows is the side that needs to adapt to support their model. MS hasn't done so, which means that C developers would need to unacceptably compromise unix support in their packages in order to better support Windows. Cross-platform support precludes windows-native solutions, so you're left making the best of it with Linux tools (mingw and cygwin) on Windows. John