The WLM 2009 betas didn’t need much work for them to connect to Escargot without any problems. For some reason, this is where MSNP17 is treated as its own protocol, so I had to do some more tweaks for the server to accommodate. Now those betas can login and send messages. I even did a test chat with two dummy users:
I also made fixes for signature sounds to work, which work perfectly.
Unfortunately, it seems that these betas have the same issue as the final version of the client, too, as the build I used to test, 14.0.3921.717, didn’t work with the Escargot-supplied msidcrl. This might mean that other beta builds won’t work with our current patches, which is a shame really.
Since WLM 2009’s going nowhere right now, I thought implementing MSNP21 would be interesting to look into. Unfortunately, it’s situation is much worse than WLM 2009’s, custom DLLs aside. Whenever it tries to authenticate to Escargot’s RST service, it fails instantly, and Fiddler doesn’t seem to pick up anything this time. It might be that Microsoft got a bit more sneaky with the authentication process, but who knows.
That’s for patching strings. When it comes to replacing program functions or more complex data, like structs, that’s when reverse engineering has to come into play. This is where the problem WLM 2009 and our msidcrl DLL falls into.
Also it can conflict with other programs or services. The login.live.com URL having to be added to HOSTS for MSN to be able to login is a good example of this, especially since all of Microsoft’s services and applications still use that URL, two being Outlook.com and Windows 10’s Mail app.
If i type a wrong password on Windows 8.1 with login.live.com set on localhost (for the wlm 2009 server from that tutorial), it says that “your pc is offline”.
If it didn’t had that, then it would say “your password is incorrect”.
It appears that the host way doesn’t work on the famous 2009 betas, always gave me a 80004002 error