Uru Live’s weird (and, puzzlingly enough, still unfixed) JPEG bug prompted me to create a GUI application to let average users work around it, by running their Uru Live-created images through a process that would remove the corrupted data.

Images output by Uru Live have their first four bytes filled with the file’s size, or rather what it would be if it weren’t for those four additional bytes. Only then does the JPEG header begin, and soon after the related data. I call it a bug because, while one support contact has described it as “the intended behaviour”, this conflicts not only with common sense, but also with the account of other employees.

For someone who knows their way around hex editors, this is trivial to fix, but not very convenient. For anyone else, it’s so hard they’ll simply give up. A GUI app certainly helps.

So in December, I released a small Windows tool that did just that. It lets you select JPEG images, looks whether their header is a JPEG one, and if not, strips off the first four bytes under the assumption that that will fix things. This will break awfully if you try and run it on non-JPEG images, let alone other kinds of files, but it not only provides a backup option (which is on by default), but also warns the user of this problem.

I had written that app in C# and .NET using Visual Studio 2005 Express, which wasn’t my first experience with the IDE, the framework or the language, but the first time I spent enough time in all of them to actually ship something.

Seeing as a Mac version of Uru Live will come up, and will likely have the same bug (though one would home they’d have it fixed by then, but I doubt it), I decided to port the app to Mac OS X (with Objective-C, Cocoa and Xcode), where “port” isn’t quite the right word. I took a brief glimpse at how the Windows code works just to recall the basics, but then proceeded to implement virtually everything from scratch.

You can see the source code for both versions over at Google Code’s MYSTlore project, though I wish Google Code would offer a more suitable source browser.

That’s that. Ideally, of course, the actual processing could would be written separately in backend code shared by the two frontends. Since C# and Objective-C are both, in a way, related to C, it would make sense to write this part in C itself. For such a tiny project, it isn’t really worth it, though, and in general, I lack the expertise and inclination to write C code.