Work and Hobby

When I started StuffPlug, it was my hobby. Messing around with messenger was something I liked doing, and getting a useful program out of it was simply a pleasant side effect. However, lately my interest in messenger hasn’t been what it used to be, and as such no real update on StuffPlug has taken place. I sometimes feel I should try and force myself to work on it just for the sake of getting out a WLM9 compatible version and keeping it alive.

At the same time I’m currently working for Iminent on a temporary consulting job, and today I suddenly realised the whole “but I want StuffPlug to stay a hobby or else it won’t be StuffPlug”-feeling that I’ve carried around since my parents have been pushing me to commercialize it wasn’t just a feeling: Whenever you specifically work on a project, your goal is to get out the product. If you have to cut corners, you’ll do so. If you need some specific research, you’ll probably only research as much as you need. But this goes directly against how StuffPlug started: I’d do some research, mostly for fun, and stumble upon things I could use. Sometimes I’d dig in a little deeper with a specific purpose, but I’ve always just researched stuff for fun, instead of with a specific feature in mind.

I’m doubting now about StuffPlug. Should I just push myself to write something for WLM9 that resembles StuffPlug and try to replicate features, or should I just let it be until something new triggers my interest? I’m afraid that with the first option I’ll never be able to make StuffPlug in what it used to be, simply because I’d be doing it with a completely different mindset…

What are good sources nowadays?

I love messing around with Messenger, but lately it seems that the whole community is falling apart. MSN Fanatic, once one of the biggest communities of messenger hackers, is mostly just an archive of time long gone. only rarely updates with something worth mentioning, and seems to have an enormous amount of advertising compared to the actual news, and only the forums are of any real value to me nowadays. The only forum still really active seems to be the Messenger Plus! forums, but they seem to cater more to the average joe that wants a random script done instead of people genuinely interested in doing some more advanced stuff.

So I’m asking myself (and, through this blog, you), what are good places to hang around as a messenger hacker these days? And what are good news sources when it comes to the more underground what-microsoft-doesn’t-want-the-public-to-know stuff ?

UIB Update

Thanks to a little hint of someone at MS, we now know that the current UIB version is 0.5, which means that we now know the meaning of all used fields 🙂 The only command we don’t know yet is one that saves a value somewhere that, according to our research, isn’t ever used again. Luckily, none of the UIB files in messenger seem to be using that command, so we don’t really care 😉

On a related note, my current UIB parser can currently handle almost all resids in messenger, with the exception of two files using rcbmp (I still have to implement that), and a bunch of resids that are corrupt (but those are not used in messenger anyway, so who cares ;)?). After this I’m going to write some kind of library that allows patchers to load the UIB as an in-memory representation of the user-interface, apply patches to it, and then write back to UIB. Hopefully that will get both A-patch and MessPatch up to speed with the new messenger. After that I plan to write a bunch of other UIB tools, and at some point Steve and I still intend to document the UIB format fully and release it to the public.

But for now: Let’s just celebrate that we know all the fields 😉

Clarifications on the new WLM9 “protection”

With Windows Live Messenger 9 Wave 3, Microsoft abandoned the XML-like UIFile format to describe their user-interface layout.  Instead, a new proprietary binary format was introduced named UIB (named after the first three bytes in the files), which TheSteve and I are now reverse engineering.
What bothers me is that somehow people have misinterpreted this move, and are labelling it “protection”, insinuating that Microsoft did this intentionally to block skins and patches.

So allow me to clear that up. First of all, the new format is not actually a protection. The format is, once you figure out how it works, rather simple and elegant, in no way designed to mislead anyone trying to understand it. I personally think that the developers at Microsoft made the switch to a proprietary format because parsing XML for each and every window is just slow and quite a resource hog. Switching to their own optimized-for-this-purpose format allows them to make it faster and more memory efficient, and also smaller.

Secondly, in the first beta to feature UIB, the XML files were still included and (using a registry switch) messenger could be forced to load those instead of the UIB. In the new release candidate this switch as well as the XML files have disappeared. Contrary to what the following information alone would suggest, I don’t think that this was done to “piss us off” either. Beta builds are regularly built as “Debug” versions, which include extra information to facilitate troubleshooting: e.g. logging extra information to a file, dumping more verbose messages to the debug output, and possibly allow for developers to quickly change minor things (like the user-interface) without having to do a full-blown recompile (which can take quite a bit of time on big projects). Releases and release candidates are often compiled in “Release” mode: everything that might slow the program down or make it unnecessary big will be stripped, and only what is needed to actually run the program is included. If you then look at the name of the registry entry to allow UIFiles (“DUIDebug”), you will see that it was only there as a debug feature, to allow the developers to quickly change the UIFile/XML files to test certain cases, without having to convert them to UIB all the time.

One last misconception I heard a lot is that the format “changed” from the beta to the release-candidate. While this is technically true, it’s only minor. Think of it as a change from Word 97 .doc files to Word 2000 .doc files: They’re still the same format, yet the 2000 one has a few extra features that the 97 one doesn’t have. But in the end, the file format is largely the same, and that’s also the case for the new UIB files: the beta used UIB 4.0 (or 0.4, we’re not sure yet), the release candidate UIB 5.0 (or 0.5).

So to conlude:

  • The new format was most likely not introduced as a security measure, but rather to speed up our favourite messenger client.
  • There is no encryption, protection, or whatsoever that would prevent us from trying to understand the format or reproduce it.
  • There were no major changes in the format from beta to RC.
  • The trick allowing messenger to load UIFiles in the beta was most likely just a debug feature.
Some other quick things:
  • Converting from UIB to UIFile is possible, but not foolproof (e.g. named constants are not preserved, layoutpos=none will be turned into layoutpos=-3, although those have already disappeared in the UIFiles from the first beta)
  • Converting to UIFile to UIB is possible, but writing such a program would be a rather tedious job, and would likely be error-prone. It’s more likely that Steve and I will come up with an inbetween format that would be readable and editable by normal human beings, but would still be close enough to UIB to be less error-prone.
  • The UIFile/XML parser that we know of is no longer available in the release-candidate: tricking it into loading XML will likely be rather difficult.
That’s all for now. Please put any comments or questions you have in the comments section.