There are now several forks of MinGW and each has its pros and cons. However, there are now enough negatives to using them, that I've found it necessary to build MinGW from scratch myself. The MinGW64 project uses a later version of gcc, has better compatibility for building Open Source projects and has its own thread library instead of using Red Hat's pthreads-w32. Some custom builds of MinGW64 even have POSIX threading set as the default instead of Win32 threading. That means better compatibility for C++ thread related code (since the GNU C++ library relies on POSIX threading for parts of its implementation). The MinGW project has always been more careful about licensing and making sure that the code it was using was properly licensed and legal for usage. The MinGW project did follow the example of the MinGW64 project in one key area. They switched from public domain to a MIT license for their runtime library and Win32 API. When they did so without clearly indicating that an exception could be made similar to the GNU gcc runtime license exception, I felt it was time to stop using that version of the MinGW compiler.
I'm currently working with gcc 4.9.2 compiled from source. I'm still using the older public domain APIs, but I've made several modifications for compatibility with the Win32 API (including some modifications that aren't available in the MinGW64 libraries). I have a minimal thread library that was custom written for portability. It's based on C11 thread support and includes POSIX functionality. The gnu compiler is built with POSIX threads as the default so C++ threading works as expected.
So far, I've had no reason to want to work with any other MinGW forks. The version I have does everything I need and supports all the programs I want to compile on Windows. My particular fork is continually evolving. I continue to add support for new Win32 API changes, Win32 API omissions, new C/C++ features as I need them. At some point, I hope to completely replace the runtime library with code that better supports internationalization (better UTF-8 support), C standard compatibility and other useful features.
If anyone else is finding limitations with the compilers maintained by the various MinGW and MinGW64 projects or other related forks based on these projects, I highly recommending building the GNU compiler from source on your own with the options you need most. If you're interested in discussing the GNU compiler further or want to know more about my modifications, you're welcome to use the CppDesign mailing list ( http://groups.yahoo.com/group/CppDesign ) as a forum for further discussion.
I'm currently working with gcc 4.9.2 compiled from source. I'm still using the older public domain APIs, but I've made several modifications for compatibility with the Win32 API (including some modifications that aren't available in the MinGW64 libraries). I have a minimal thread library that was custom written for portability. It's based on C11 thread support and includes POSIX functionality. The gnu compiler is built with POSIX threads as the default so C++ threading works as expected.
So far, I've had no reason to want to work with any other MinGW forks. The version I have does everything I need and supports all the programs I want to compile on Windows. My particular fork is continually evolving. I continue to add support for new Win32 API changes, Win32 API omissions, new C/C++ features as I need them. At some point, I hope to completely replace the runtime library with code that better supports internationalization (better UTF-8 support), C standard compatibility and other useful features.
If anyone else is finding limitations with the compilers maintained by the various MinGW and MinGW64 projects or other related forks based on these projects, I highly recommending building the GNU compiler from source on your own with the options you need most. If you're interested in discussing the GNU compiler further or want to know more about my modifications, you're welcome to use the CppDesign mailing list ( http://groups.yahoo.com/group/CppDesign ) as a forum for further discussion.