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.

I recently finished a new project; Name days in Google Calendar.

This calendar works very similar to my Google Calendar Week Numbers, but instead adds flag icons to each day. Simply hover the mouse over the flag to see a tooltip with that day’s names. Click the flag to read more about the names (on Wikipedia).

Currently there are only Swedish name days, but if this becomes popular then I am willing to work to support more countries.

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.

Today I want to release a few Elasto Mania maps that I made about 4 years ago. There are 4 levels, and I have made recordings of my best times on them. You can download them here.

Here are the levels:

rec1 – “Noobs only”: A pretty easy level where speed is important. My best time is 1:26:23. Screenshot.

rec2 – “Climbing Hour”: A tricky level in which you can save a lot of time by properly bouncing to an apple. My best time is 51:49. Screenshot.

rec3 – “Bumpy Ride”: A very short level with a lot of bumps. My best time is 14:97. Screenshot.

rec4 – “Authorized Elites Only”: A pretty long and difficult level. There are plenty of risky timesavers here. My best time is 3:35:02. Screenshot.

I will try to put the recordings up on youtube as well. They are now up! I also have a fifth level in the works, but I’m not sure if I will release it.

Let me know if you beat my times!

Today I want to write about something that I made back in April 2007. This was about two weeks after Command & Conquer 3: Tiberium Wars had been released. Command & Conquer is a franchise that I really like. Well, before EA decided to kick Westwood in the butt anyway.

What I really like about C&C is the story. It has a truly awesome story. So after I had played through C&C3 I wanted to see how the planet had been ravaged by Tiberium. What is sad is that there were very little information outside of the game. The only place where you could see a globe with information about what places had become blue/yellow/red zones was in the introduction video, and it was really hard to make out the details.

In any case, I somehow got the idea to make a map of my own. I found a map with the various zones online. So I went to Google Maps and re-created the map there. When I was done I imported the map into Google Earth and recorded a short video.

Video in mkv container. Watch with VLC.

After that I made a thread on the official C&C forums (which no longer exists) and a thread on the Pure Pwnage forums, linked to the video and explained what I had done, and there were much rejoicing. A few people noted that my source image was inaccurate but overall the reaction was positive. Those who posted agreed that information on how the various places in the world had turned out was really scarce.

Not much happened after that…. But after about two weeks, EA announced that they were releasing something called Tiberium Earth. Looks familiar? Well, it should! The idea is identical to mine. In plain text: they ripped me off!

And did I get any recognition at all? No!

This is as good as an example as any of EA’s inherent evilness. I would have settled for an email from Apoc telling me “Good job. Thanks for the idea.” or something like that. I wouldn’t have required anything except a little recognition! But no, they don’t care.

In any case, the effort from EA seems to have died right after they launched Tiberium Earth. I have seen no news about it after the announcement. The Tiberium Earth site have not been ported over to the new C&C site either. The KMZ file is no longer available at their site… I had to look it up on the web. You can get it here: TiberiumEarth.kmz

Final words? Apoc: It’s not too late to give me recognition for the idea.

Planetoids is a game me and a buddy made in school last year. I wouldn’t say that it’s fun but it is something you might find interesting if you want to see how it works. It uses formulas we learned in physics class to calculate gravitational forces between bodies in space. You can download either a binary-only archive or an archive that also includes the source code. The program is written in C++ and the source code is licensed under GPLv3 or later. You can also create your own planetary systems, let me know if you create one.

Click the image to view it larger

Just spent a couple of hours updating the installer for ShutdownGuard. Upgrading should be smoother now. Will port the code to my other projects later.

I will try to blog more actively.

I’ll post things about stuff I create on this blog. Will mostly be related to the stuff in the About tab.