Tag: Messenger

Compatibility out of the box

My current boss wanted to know if the LiveScratcher Script-to-DUI interface would work with Windows Live Messenger 8 too. I’d kept in mind that I wanted it compatible with WLM8, but hadn’t tested it yet. To my suprise, there were only two tiny (non-fatal) errors, and I could get the advertising removal script working with just one extra line.

Behold, the Windows Live Messenger 8 *and* 9 compatible advertisement patch:

//Compact method
function CL_onCreatedElement(resid, root) {
	if (resid=="mainContentResID") {
		var ads=root.FindDescendent("TabsAndAds") || root.FindDescendent("AdBanner");
		ads.LayoutPos=-3;
	}
}

//Verbose method
function Convo_onCreatedElement(resid, root) {
	if (resid=="convframeresid") {
		var adbannergutter=root.FindDescendent("adbannergutter");
		if (adbannergutter)
			adbannergutter.SetValue("LayoutPos",Value.CreateInt(-3));
	}
}

//Patches contained in this file
Patches=[
	{
		id: "ContactListAdvert",
		name: "Remove Contact-list Advertisement",
		version: "1.0",
		author: "A. Nonymous",
		website: "http://www.google.com/",
		onCreatedElement: CL_onCreatedElement
	},
	{
		id: "ConvoTextAdvert",
		name: "Remove Conversation Text Advertising",
		version: "1.0",
		author: "A. Nonymous",
		website: "http://www.google.com/",
		onCreatedElement: Convo_onCreatedElement
	}
];
//Register patches
for (var i in Patches) {
	RegisterPatch(Patches[i].id,Patches[i]);
}

The whole thing started off as an extension to a DUI compatibility layer I wrote for Iminent, but with every hour I stick in I’m falling in love with it more 🙂

What if…

… You could write Messenger patches in JavaScript? I guess it could look something like this:

function CL_onCreatedElement(resid, root) {
	if (resid=="mainContentResID") {
		var TabsAndAds=root.FindDescendent("TabsAndAds");
		if (TabsAndAds)
			TabsAndAds.SetValue("LayoutPos",new Value(-3));
	}
}

function Convo_onCreatedElement(resid, root) {
	if (resid=="convframeresid") {
		var adbannergutter=root.FindDescendent("adbannergutter");
		if (adbannergutter)
			adbannergutter.SetValue("LayoutPos",-3);
	}
}

//Patches contained in this file
Patches=[
	{
		id: "ContactListAdvert",
		name: "Remove Contact-list Advertisement",
		version: "1.0",
		author: "A. Nonymous",
		website: "http://www.google.com/",
		onCreatedElement: CL_onCreatedElement
	},
	{
		id: "ConvoTextAdvert",
		name: "Remove Conversation Text Advertising",
		version: "1.0",
		author: "A. Nonymous",
		website: "http://www.google.com/",
		onCreatedElement: Convo_onCreatedElement
	}
];
//Register patches
for (var i in Patches) {
	RegisterPatch(Patches[i].id,Patches[i]);
}



The above code works just like you’d expect it to, thanks to a new project I’m working on. For now it features only a very very small subset of the DirectUI library, just enough to make the above work (+ some debugging, obviously), but I plan to expand it to create an incredibly flexible platform for writing patches, skins, and later maybe even plugins.


It’s the spiritual successor of the abandoned Project M or Modumes project. Basically Project M was too complex, by using Windows JScript and allowing any other language to write modules in, I faced some problems (mainly threading) that I could not reliable fix.


To create something that could reliable interface with the DirectUI, I needed to have an enviroment where everything, or at least the parts interfacing with DirectUI, would be running from the main thread. My eye first fell on LUA, later on Squirrel, but in the end I figured that although those two scripting languages were incredibly powerful and small, I wanted something a tad more manageable. Eventually I figured the best language would be JavaScript, and Google’s V8 Engine allowed me all I needed:


    

  • Quick execution (although Mozilla’s TraceMonkey is apparently slightly faster, V8 does a really good job, and was easier to embed)
    • 

  • Easy embedding
    • 

  • Easy extensible (adding new objects)
    • 

  • Easy to learn (Plus! uses a variant of JavaScript too, and all client-side web development is JavaScript too)
    • 

  • No threading issues
    • 



A weekend plus several hours in the evenings further, and I have a working prototype, yay! 🙂


My current goals:


    

  • Ability to write quick patches

      

    • Without having to replace the entire UIB/XML
      • 

    • Without having to convert back and forth from UIB
      • 

    • Without having to update for each and every minor update
      • 

    

    • 

  • Ability to bind to element events (e.g. onMouseOver, onClick)
    • 

  • Ability to interface with the Messenger API
    • 

  • Ability to set timers from patches
    • 

  • Ability to interface with outside programs
    • 

  • Ability to share functions between scripts
    •

Messenger Addons

Since the new version of Messenger 9, none of the major Messenger add-ons have been updated to support it: I myself have attempted to port the current StuffPlug 3 code to WLM9, but concluded that there have been so many changes that for it to be fully compatible I’d have to do a re-write. Patchou had made a quick beta compatible with the earlier WLM9 beta, but he hasn’t posted anything on his own forums since December, and as far as I know his latest version of Plus! is not compatible with the (January released) WLM9 Release Candidate. Messenger Discovery only states “limited support for 9.0”, and to top it all off all current patches (with the notable exception of A-patch, who did a limited version) are not compatible with the new messenger file format.

Basically I think that the comment absorbation made on my earlier post was probably dead on: everyone seems to have moved on to other projects. I’ve seen my own interest in Messenger getting lower at times, resulting in no updates for StuffPlug, but now it’s not only me: even Patchou, the one person who’s kept updating Plus! for ages even when SP and MD would not, seems to be moving on to other projects.

I sometimes wonder how it is that old developers are moving on while no new ones are taking any interest in Messenger anymore. Is messenger development going too slow? too fast? is it because they completely abandoned all the APIs available? Is it because the messenger team has been more and more secretive, and the only real outwards communication being mainly focused on normal users while no longer appealing to developers? I’d really love to hear people’s opinions on this, and would be especially interested in hearing what people at Microsoft think of it. Please, if you read this and have any thoughts about this subject at all, share them with us through the comments below.

On a slightly different note, I’d like to comment on what warmth said in reply to an earlier post. Yes, StuffPlug currently is pretty much dead: the code I have is just no longer compatible with the changes in WLM9, and I’d have to start a re-write sometime. Problem is that most of StuffPlug’s features aren’t really relevant anymore on Messenger 9, and so trying to re-write the entire beast for WLM9 won’t really get me anywhere. I’d much rather start off with something small and build it up from there, much like StuffPlug was in the beginning. So if you have anything, anything at all, that bothers you about Messenger 9, please do tell me, and it might spark that required bit of passion to start working on something again.

As for helping development of other projects; I have actually helped and contributed to both Plus! and MD in the past, and if I can help them again I’d still love to, but setting up an environment for different people to work on the same (hobby) project takes time and effort, and I’m not sure either of us are really ready to make that kind of effort.

So, if you read this: please do leave a comment if you have any views on the whole lack of third-party development on Messenger 9, or if you have something that you’d like to see changed in Messenger 9 by a third-party add-on.

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. Mess.be 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.