QuantumG's Blog

The never ending effort to recreate a game from 1993 continues. There's now nine developers in the project and none of us do much. Every now and then I get bored and fix something.. go to check it in and discover that, shock, someone else has checked something in too! Then I have to update and resolve conflicts. Take the good with the bad I guess. Anyway, in release 0.2 you will be happy to discover that we have done some work to get sound faithfully reproduced. For a while, we were focusing on music and trying to get the SDL midi synthesiser to play back this ancient XMIDI format. Believe it or not, this was actually acheived. Slight problem though, Syndicate used custom instruments. This was not uncommon at the time. The result was that the music just didn't sound good.. but it was good enough to ignore for a while. Having declared that I wasn't going to touch sound.. I got bored one day and changed my mind. I told myself that I really ment I wasn't going ...

I was recently asked what I would do differently if I was writing a decompiler from scratch today. Having worked on decompilers for the past 9 years myself and worked with others who have worked on decompilers for longer still, I like to think we now know enough about it to recognise some of the mistakes we've made and identify some areas of improvement. The primary difficulty of decompilation is that most analysis requires interprocedural information. Most everyone recognises this need early on so there's an assumption that you need to keep the intermediate representation for the entire program in memory at the same time. For many years we've had a hell of a lot of memory to play with (4 gig will be standard on desktop PCs next year) and with 64 bit architectures and virtual memory you can swap to disk for as much memory as you need. So it would appear that structuring a decompiler like a compiler, with intermediate disk formats for each compilation module is unnecessa...