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.