Stefan Sundin

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.

In the Windows API, there’s a function called Shell_NotifyIcon() which is used to manage the tray icon in your program. All my programs, like SuperF4 and AltDrag, have a tray icon — also the only UI they expose. As the number of users for my programs have grown, the number of bug reports regarding this function have increased. The problem with this API is that if (when) the Windows shell (explorer.exe) for some reason isn’t responding, the API call will fail. As a result, your tray icon won’t get updated, or worse yet, it won’t be added in the first place.

The first time I received a bug report about this was in December last year, almost exactly one year ago. A user was using AltDrag and complained that tray icon was not appearing when he started his computer, and that an error message mentioning Shell_NotifyIcon() appeared instead. After some googling, I found out that this most often happened on slow computers with antivirus software installed. The antivirus program slows down the computer so much so that explorer.exe hasn’t fully initialized when the autostart programs try to add their tray icons. I verified that the user had an antivirus program installed, and we managed to work out a workaround for the problem. The workaround simply tried to add the tray icon at least five times before giving up (code).

This worked great, and there were much rejoicing. It worked great until April this year, at which time I got two bug reports in rapid succession (one day between them). At this time I was using Vista and I had even encountered the error message myself, even though I have a fast computer and I don’t use an antivirus program. I eventually managed to track down why the retry code wasn’t working — it was because the code only tried several times when it was adding the tray icon — it didn’t retry when was updating the tray icon. Somehow the tray icon was added successfully, and then when the program tried to update the tray icon, explorer wasn’t responding and the update failed. For readers unfamiliar with my programs, they first initialize in a disabled state (and adds the tray icon), they then enable themselves (hook with the keyboard etc.), and finally updates the tray icon to represent the enabled state. Another fix was made to make the code always retry, no matter if it was trying to add or update the tray icon, and a delay of 100 ms was added between each retry (code).

This worked great, and there were much rejoicing. It worked great until a few months later, when bug reports about this started rolling in again. Another fix was made which increased the number of retries to 100. Combined with the 100 ms sleep, this means that the code should retry to add/update the tray icon for at least 10 seconds. This seems to have solved the problem for everyone.

I am now using Windows 7 and I have noticed that most people who reported the error also used Windows 7. It seems that Microsoft have worsened the situation with this release. I have also noticed that some of my other programs on autostart fail to add their tray icon sometimes (psst.. Xfire developers). The reason is this bug! Yes, it is a bug, but it’s not a bug in the program — it is really a bug in Windows. These programs don’t retry when they add their tray icon, they probably don’t even check if it was added successfully. I can understand why: This isn’t something a programmer should have to worry about at all, and the workaround is horrible and unreliable. The only reason almost no one knows about this bug is because almost no programs display an error message if their tray icon failed to add. Does your favorite app fail to add its tray icon on boot? That is because of this bug!

I have not updated all of my programs with latest fix yet. So far only AltDrag has the latest fix in its stable version, and SuperF4 has a hotfix released separately on its website. I will have to roll out a new version for all my programs — a version which only works around a bug that exists in the operating system.

My recommendation to developers: Add code that retries when you do any kind of operation on the tray icon, include a delay between each try, and try at least for 10 seconds before giving up. Also take a look at my code.

All of this touches on a much more deep and fundamental problem: Windows is unable to evolve. We are stuck with this problem because of application compatibility. Microsoft is afraid to trip on the wrong bit and cause mayhem with older applications, in which case they will eventually lose money. That is why Microsoft is unable to fix this bug. If a bug like this existed in an open operating system, it would simply be fixed, at the core, and the community would make sure that all applications are updated to work properly. This is impossible in Windows, and I promise you that we will still work around this bug in ten years from now. I guess that when Windows 8 is released, we will just have to increase the number of retries to 200.