Home > Uncategorized > MinGW and mingw-w64

MinGW and mingw-w64

February 23rd, 2010 Leave a comment Go to comments

MinGW is a port of the gcc compiler to Windows. I have used it for all my Windows programs, like AltDrag and SuperF4, and it has served me well for years. Recently though, I have become increasingly frustrated with MinGW’s stagnated development.  Simply put, nothing has happened for years.

It started with missing #define statements in the header files, and I eventually encountered missing library definitions for dll files. MinGW doesn’t even have all the correct definitions for Windows XP, some of which I want to use. A temporary workaround to these problems was to simply add a bunch of #define statements in my own code, and sure, this worked pretty well. The missing library definitions were a lot more troublesome to work around, but I eventually managed to do it (more about this here).

Off topic: one of the things I hate to do while programming is having to do things that doesn’t really concern the functionality of my program. Some things worth mentioning here is GUI, documentation and compilers. The basic reason why these compiler problems exist in the first place is because I only want to use free software programs in my toolchain. All the processing of my code to a working binary is entirely done by free software, which I think is pretty important. This might be a controversial statement since the programs are for Windows, a closed operating system, but I will leave that issue for another blog post.

When I started looking for a 64-bit compiler for Windows, it wasn’t long before I found out that the MinGW project had no intention of adding that anytime soon. I soon found the mingw-w64 project, a fork of MinGW. mingw-w64 is not only adding 64-bit support, but it is a lot more cutting edge; instead of gcc 3.4.5 (MinGW) there is gcc 4.4.3. They are also developing a 32-bit version called mingw-w32, which is basically MinGW but a lot more cutting edge. When I first found mingw-w64, the documentation wasn’t that great and I had a lot of troubles getting it to work. It is still a little difficult to find the stable downloads, but here are links to help you: mingw-w64 1.0, mingw-w32 1.0.

When I first tried mingw-w32, it was also missing the library definitions, but after I visited the IRC channel and asked them to add the definitions, they did so on the spot, and the next daily build worked flawlessly. I have seen many forum threads trying to get the MinGW people to add the very same library definitions, but with no success. I have been idling in the IRC channel ever since, and I am seeing constant development happen. This project is very much alive. I would like to encourage all MinGW users to check out mingw-w64 and decide if they want to switch to it.

Currently only the 64-bit parts of AltDrag 0.8 is compiled by mingw-w64 (the 32-bit files were compiled with MinGW). I am planning to compile all future releases with mingw-w32 and mingw-w64, which means I will start offering 64-bit binaries. All my programs can still be compiled by MinGW, but I don’t think I will be actively maintaining support for it.

Tags: ,
  1. Dennis Decker Jensen
    August 23rd, 2011 at 01:53 | #1

    Hi Stefan,

    I came by your blog post when searching the web for information on mingw compilers and free software compilers for windows in general.

    Like you, I have a keen interest in free software, and have been using GNU-Linux and BSD systems for years, although I am confined to Windows at work. Usually I have been using Cygwin in those cases, but wanted to find out about mingw/msys, open watcom, etc. Would you mind elaborating your statement: “This might be a controversial statement since the programs are for Windows, a closed operating system, but I will leave that issue for another blog post.”

    I ask, because that other blog post isn’t there yet ;-)

  2. recover
    August 23rd, 2011 at 08:34 | #2

    I just want my toolchain to be free software. You could say that it doesn’t matter since I am coding for Windows, a closed operating system. Why I even bother making sure my toolchain is free software when the rest of the operating system is closed, that is something that might be controversial (or at least arguably not worthwhile, given the troubles explained in the blog post). I don’t think I ever intended to write that second blog post though. :)

  3. Fran Pena
    February 22nd, 2012 at 19:37 | #3

    Hi,

    I was searching for the differences between both sourceforge projects, Mingw and Mingw-w64, and I found your blog. Thank you for your explanation. If I understood well, Mingw-w64 adds new features that mingw misses. Is it that correct?

  4. recover
    February 23rd, 2012 at 00:57 | #4

    @Fran Pena Last time I used ordinary MinGW, it lacked a lot of features and it still used a quite old gcc version (3.4.5 as noted above). I don’t know if this has changed, but I see no reason in going back. Also, it’s easy to get help with mingw-w64, simply go to #mingw-w64 on OFTC, they are a helpful bunch.

  5. Asgard
    June 25th, 2012 at 02:12 | #5

    @recover In the link you posted, http://code.google.com/p/altdrag/wiki/Build it said that we need both toolchain to build for 32 bit and 64 bit. Then what exaclty is -m32 and -m64 option?

    Also, recently, few day ago, i installed mingw32 on one of my computer. The gcc version is 4.7., so now im wondering that since they updated their GCC version, what is the difference beetween mingw32 and mingw-w32?

  6. Kai
    November 23rd, 2012 at 05:09 | #6

    @Asgard There are some difference between mingw.org and mingw-w64 ventures about their runtime. In general mingw-w64’s runtime supports x86 32-bit and x64 64-bit, unicode-startup (by -municode switch) is available, math-runtime is improved, there is consistent POSIX-printf/scanf (also for widecharacter-set) support, platform headers are much more API complete, there is a direct-x sdk, there is a more up to date ddk sdk, there is idl support, etc.

  7. Ehtesh Choudhury
    September 18th, 2013 at 05:46 | #7

    recover :
    I just want my toolchain to be free software. You could say that it doesn’t matter since I am coding for Windows, a closed operating system. Why I even bother making sure my toolchain is free software when the rest of the operating system is closed, that is something that might be controversial (or at least arguably not worthwhile, given the troubles explained in the blog post). I don’t think I ever intended to write that second blog post though.

    You should take a look at [chocolatey](http://chocolatey.org), which aims to make developing for Windows more open. Also, it’s a package manager, like homebrew on OS X, apt-get on Debian/Ubuntu, yum, pacman, and others!

  1. No trackbacks yet.