Last time in “Windows Live Messenger 8.5 is Resurrected” I mentioned about that I removed the limit of single process per user session on a Windows system as well as the update-reminding balloons. This time I am going to tell you how the WLM originally works on such both things and you will find that there no difficulty to patch them yourself.
1. Constraint on the number of WLM process
This is done by trying to create an event object with invoking the CreateEvent() API function using a constant event name. In our case of WLM 8.5, it is MSNMSGR. If you use tools to probe opened handles in a WLM process, you may find some thing like Figure.1. According to the MSDN document, if you try to create a named event that already exists, CreateEvent() will return the handle to the already-created event object, and a subsequent GetLastError() invocation returns ERROR_ALREADY_EXISTS. So during WLM’s initialization, it tries to create a named event object and check the return value from GetLastError(): if the value indicates an existed object, the process signals it and terminated itself.
Figure.1
To present this flow in a more detailed perspective, I made the following pseudo code:
HANDLE hEvent = CreateEvent(NULL, true, NULL, "MSNMSGR");
if (hEvent == NULL) {
goto OnError;
}
else if (GetLastError() == ERROR_ALREADY_EXISTS) {
// we do this to notify the existing WLM process
// to pop up its main window
SetEvent(hEvent);
goto ExitProcess;
}
// do some subsequent initialization
....
2. Retrieval of current version number from server
After the identity authentication passed, the WLM client send its current version information to the server by posting a VER message in the microsoft defined protocol (it is a plain text format). The server then respond a CVR message with the latest stable version number of client software and perhaps a URL to the new client download, depending on the information sent by the client earlier. If the server response contains a URL, then it means that the client side is recommended to upgrade its program, and an annoying balloon will come out. This portion of code is merely some string comparison, which parses the server response.
DWORD dwHead = *((DWORD*)szMsg);
switch (dwHead) {
case 0x20524556: // VER
...
break;
case 0x20525643: // CVR
...
break;
...
}
A fast but somewhat brute method to disable this behavior is to break the pattern used to be matched by parser. We only need to modify the string CVR in the executable image to anything else, so the program will not be able to recognize the latest client version and URL to download it. This does work and for now no side effects have been found by me, since the information provided with a CVR message will not be used ever after.
