MSN Messenger vs. Windows Messenger API confusion

MSN Messenger and Windows Messenger are two very different applications, each have a different purpose and target audience. As such, you are able to install both on Windows XP. This has caused much confusion with the API that exists in both of them.

Firstly, a little history: when Windows XP was released, we saw a new instant messaging product ship with it called Windows Messenger 4.0. All it appeared to be was a cleaner version of MSN Messenger 3.6. Because of the little differences and the close version number, which we can assume is because Windows Messenger built up from MSN Messenger 3.6; many users started using Windows Messenger and never looked back at MSN Messenger. Windows Messenger was even being referred to as “MSN”, even when it was a completely separate product.

Around October 2001, MSN Messenger 4.6 was released. This added more confusion as it looked almost exactly like Windows Messenger and again the version number was close, which we can also assume is because this version built up from Windows Messenger. When MSN Messenger 4.6 was installed on Windows XP, it basically morphed into Windows Messenger! Because of this, many users simply thought Windows Messenger was replacing MSN Messenger.

Moving onto their APIs, MSN Messenger (and/or Windows Messenger on XP) exposed an internal API which is simply referred to by its main interface: MsgrObject; this API has a lot of internal methods such as full access to all lists and sending messages (the most used features of the API at the time). Both also had another API library which was called the automation library, this was mostly limited to automating the user interface, getting basic information and only allow you to read the forward list.

MSN Messenger 5 was released in October 2002; it was very different to both the previous version of MSN Messenger and Windows Messenger. Version 5 was a big change for MSN Messenger and for the first time you were able to install both MSN Messenger and Windows Messenger on Windows XP together and use them at the same time. This also meant a lot more confusion for users.

Version 5 of MSN Messenger was generally a good change, but developers noticed the MsgrObject API was no longer exposed. Windows Messenger still had it, as well as the automation library, which remained in MSN Messenger. Here it was clear where Microsoft was going with this: Windows Messenger was being aimed at enterprises and MSN Messenger was for the consumers. Enterprises using Windows Messenger were able to develop their own solutions for interacting with Windows Messenger, while MSN Messenger users got the short straw. All add-ons that were developed for MSN Messenger 4.6 using MsgrObject failed to continue working. The only solution was to use Windows Messenger instead.

The thing is, both API libraries were pretty much identical in both programs (and the automation library still is). After all, they are based off each other. What ever client was running is what the instance of a new object would be created on. But, Windows Messenger takes precedence over MSN Messenger. If neither are signed in, then Windows Messenger will be fired up and that’s the object you get. So, if you created a new object and used the sign in method, Windows Messenger would sign in — MSN Messenger simply won’t be touched.

When a new object is created, Windows Messenger is called and checks if MSN Messenger is signed in. If it is signed in, then it passes the object from there and Windows Messenger is left alone. Otherwise if it’s not signed in or not running, MSN Messenger again is not touched. When Windows Messenger is called during the object creation, an instance starts up in the background, if it passes the caller the MSN Messenger object it is closed and the process is completely transparent to the user.

Many users have uninstalled Windows Messenger from their system. It is not meant to be uninstalled as it is a system component and there is very good reason not to because of the API. If you are familiar with COM, you are probably thinking, if Windows Messenger takes precedence over MSN Messenger, why don’t you just change the binary paths for the CLSIDs and the like. All I can say is, I am writing this in 2006 and the problem has been going on since late 2002, that’s over three years. Lots of people have come and gone trying to get around this, from VB6 newbie’s to C++ veterans who have a bible of COM in their head. No one has done it successfully.

If you’ve somehow managed to read through all the rot to this part of the article, I do have some tips:

1. Don’t uninstall Windows Messenger

   No matter how annoying Windows Messenger may be, do not remove it. Instead, just turn it off. Open it up and go into options, turn off the following two options:

   • Run Windows Messenger when Windows Starts
   • Allow Windows Messenger to run in the background

   For the most part, Windows Messenger won’t annoy you again.

   This tip is fine for yourself, but if you are distributing something to many users, there is no guarantee that everyone has Windows Messenger installed.

2. Don’t rely on the API

   This may sound like a stupid suggestion, but if you can find an alternative to using the API, such as reading/writing MSN Messenger’s registry settings for example — then go for it.

3. Dig deeper

   The best news is there is another way, but it’s not simple. Messenger Plus! uses some low level techniques for interacting with MSN Messenger, the author is quite secretive about what is done. A few are convinced it uses methods such as internally finding the pointer to the object and using it from there (since Messenger Plus! is mostly a DLL which is injected into the MSN Messenger process).

This is a rather broad/complex topic and there may be more to know, if you have something you think should be added that may help other readers, then feel free to contact us.