For a few weeks now, Uru Live has had a rather peculiar bug. Even more peculiar is that it would take so long to fix, but with all the stuff that’s been going on, it’s probably only fair to give Cyan a break. Moreover, this issue is rather unimportant (especially seeing as there’s a workaround) compared to the big problems to tackle, such as lag.

There are two (more?) instances where the Uru Live client creates JPEG images on the local computer: either when you’re in the avatar customization screen and make a “portrait photo” of the result, or when you’re creating or downloading a KI image. Both of these cases are one-way: you get a local copy of what’s stored on the server, and can edit it and share it as you like, but you can’t upload the result back onto Uru Live’s server. This is mainly done to avoid various obvious and less obvious forms of abuse.

The locally stored JPEG files, however, are currently all broken. It is honestly rather hard for me to imagine why this would happen; surely there’s many, many libraries that create perfectly fine JPEG image files, and how previously, Uru Live (and earlier iterations of Uru) had been able to output flawless files. Somehow, though, Cyan happened to pick a library that’s broken.

A regular at Uru Live Forums, Tiran did some investigative work on what precisely was wrong. It turns out that the first four bytes in the files contain a little-endian representation of the file size (or, rather, what the file size would be if it wasn’t for these four additional bytes). One can only assume those bytes were meant to go inside some header; whatever the case, they don’t belong there.

The fix is, then, simply to cut off those first four bytes. But that’s not exactly something the average user has the tools for. Tiran had created a Python script that gets the job done, but wrapping a GUI around that would be an awful idea. So for a few weeks now, I had pondered the idea of creating a little app that does the same in a more user-friendly manner.

Last night, I did. I wasn’t sure whether I would succeed, or even care to. After all, it was the first time for me…

1. that I used .NET in any serious manner.
2. that I wrote remotely useful C# code.
3. that I wrote code that deals with reading and writing binary data from and to files.
4. that I used Parallels Desktop productively, and the first time buying a license has started becoming justifiable.

I could have done it ‘natively’ through Boot Camp, of course, but using the new “Coherence” mode in Parallels Desktop actually added to the intrigue for me. Plus, having icons for Visual C# and Document Explorer pop up in your Dock is, to say the least, a rather unique experience. (Microsoft needs to get rid of their inflated names, though. Do I really need to read “Microsoft Visual C# 2005 Express Edition” in the taskbar? I know it’s from Microsoft, and I know the version and edition as well, thankyouverymuch!)

So I got on to it, creating a little window with a small description, two buttons (one that would show an “Open File…” dialog, and one that would start the processing), two radio buttons (to choose whether to overwrite the original file or whether to create a corrected copy) and a progress bar (take a guess). Some of those controls took a while to get used to, and it seems I didn’t really pick the right ones for everything (the multiple-line text box with the description in it, for example, allows a selection, which it shouldn’t, and I can’t see how to turn that off).

The bigger problem, as one might expect, was the code itself. C#’s sharp is fairly simple to get used to get used to, especially when, like me, you’re familiar with the syntax of the likes of Ruby, PHP, Perl, and C itself. There’s some about the syntax that I like (and prefer over Objective-C), and some of the opposite. The UI of Visual C# is extremely helpful sometimes (and I don’t mean that sarcastically at all), and other times, it’s also very, very much in the way and needlessly complex. I probably wasted most of the time trying to find stuff in the API. While MSDN’s documentation feels quite comprehensive, especially as compared to some, er, ‘lesser’ areas of ADC, MSDN can also be very disorganized. Even though Document Explorer is set to search for .NET- and C#-specific documentation, it frequently brings up stuff from pre-.NET Visual Basic, or the Win32 API. For instance, I wanted to find the right constant or API call to get the path of “My Documents”, but all I could find was references to Visual Basic 6’s object hierarchy, or a simulation thereof on top of .NET — even though the latter is .NET Framework 2.0-only, suggesting there is no way to do this on .NET 1.x, a concept I had a hard time believing. Indeed, as Adam showed, there was a perfectly simple, .NET-’native’ manner to do this. Why Document Explorer failed to find it eludes me.

In any case, the project would assume a workable state within a few hours, and the very first time I tested it on actual broken files, it worked as expected (typically, I’m huge at random oversights and always have been, so this was unusual for me).

The crazy thing happened after I posted a thread at UL Forums to announce this solution: it turned out, then, that four minutes(!) earlier, someone else had created exactly the same kind of app; also in .NET 2.0. Their app was several times as large, but this can mostly be attributed to the random End of Ages screenshots all over the UI.

Their app, as compared to mine, mainly has the additional ability to ‘preview’ the file to process. Or, more accurately, it shows you the result during the processing. On the other hand, their app’s open dialog only allows you to pick one file at a time, making it a tedious process for those with many images (click, browse, select, click, click — for each file), and that app also doesn’t allow you to create a backup of the originals, though this is realistically a minor problem at best.

My app, KI Image fixer, is explained and discussed in this thread. Theirs, Uru Live Jpeg Fixer, in this one.

I can’t help but blink at the strange coincidences that two people wait several weeks, then do essentially one and the same thing and finish it within minutes of each other. But, it doesn’t matter in any case. Within weeks from now, perhaps even just days, the bug will likely be fixed, and both apps will be nothing but a memory.

But for me, the project the app resulted from is what matters. It has been a hugely worthwhile learning experience.