kernelEx is outrageously outdated and doesnt run anything modern.
1 Like
you are wrong
then how do i run firefox 52 (xp) in windows 98? kernelex doesnt let that.
the oldest version that runs firefox 45 is 2000, 45 still works with modern web
kernelex works in 98 ? cool
lmao, it works in 98 and ME only.
But the last version of Firefox supported by Windows 2000 was not 3.x?
No, it can run up to version 11.0.0 and some 12.x betas
and according to an user in the mozilla forums, it runs up to 28.0.
Wow.
tl;dr - Youâre stuck with 4.7.0106 and older.
The latest version that works with both Windows 98 and Escargot, as far as Iâve tested, is 4.7.0106.
Versions up to 7.0.0820 will run on Windows 98 but due to protocol requirements (TWN authentication used in newer protocols requires particular SSL compatibility) they cannot connect to Escargot. This is due to the way that Escargot handles SSL certificates across multiple domains, which is different to how Microsoft used to handle it.
Additional: According to my notes on the Escargot wiki, versions up to 5.0.0340 do still optionally support MD5 authentication, so if you were able to force them to log in using MSNP7 instead of the newer MSNP8 (which requires SSL) then you may be able to use those. Be aware that theyâre pre-release versions, however, and if youâre concerned about security then they wonât help you fix that.
WINDOWS MESSENGER 4.7 DONT WORK IN WINDOWS 8 #ILOVECAPSLOCK Body seems unclear, is it a complete sentence?
1 Like
tl;dr - Ignore this post if you just want stuff to work, youâre still stuck with version 4.7.0106 or lower.
Had a quick go at naively patching 5.0.xxxx to downgrade to MSNP7, it doesnât appear to work. Version 5.0.0124 does log in, but cannot retrieve the contact list. Versions 5.0.03xx donât seem to respond to being autopatched (the strings arenât found). Versions 5.0.05xx attempt to authenticate via TWN regardless of the my MSNP8 -> MSNP7 patch, however this could be because Iâve also accidentally patched the string it uses to decide which method to use.
Edit: No luck, perhaps the MD5 authentication code mightâve been ripped entirely out of later versions of 5.0, I canât tell at a glance. Not that it wouldâve been super useful anyway, just to enable a couple of builds of Messenger 5 to run on 98/Escargot, but I figured it was worth a quick test. Version 4.7.0xxx it is thenâŚ
Edit 2: Doh, I forgot that 5.0 betas use internal testing domains, which probably has something to do with what autopatcher missed them. Doesnât change anything, I just thought Iâd mention that in case anyone reads this.
I have verified that 4.7.0106 works on Windows 98, however, so Iâll update my âtl;drâ above, which is one build behind.
2 Likes
Out of curiosity, how did Microsoft emulate SSL for Win9X compatibility?
MSN Messenger relies on Internet Explorer for its web connectivity, so it really comes down to what the version of IE installed supports. I donât have specifics written down, but I believe MSN Messenger 7.0 requires IE6, and it wonât install without it. Not absolutely certain about MSN Messenger 5.x and 6.x, though my experiments just now with 5.x were with IE5.01 installed.
The problem, however, isnât that Windows 98 or IE5/6 lack the necessary SSL support, MSN Messenger can absolutely use SSL with those configs. To the best of my knowledge, Microsoftâs servers all had SSL certificates and IPs specific to the (sub)domains with which they were associated, and my own development server does the same - and MSN is fully compatible with that, even on Windows 98.
The issue with Escargot is that it uses SNI (Server Name Identification) in order to use just one server to host everything, which is an extension to SSL which enables the client to specify which domain itâs expecting to receive an SSL certificate for. Without this, any SSL connection you make to the server could receive the wrong certificate and the connection would fail.
This works fine as long as the client (MSN, or IE) is modern enough to support that. This is why Windows XP and earlier have issues with, or simply cannot connect to, Escargot. Vista and later (or probably more specifically, IE7) support SNI, and thatâs why itâs possible to use MSN/Live Messenger 5.x-8.x without issue.
From peeking at the GitLab, it seems that Escargot uses a âCaddyfileâ for HTTPS stuff. I wonder if thatâs what causing the problem (or if itâs just aiohttp, but who knows?).
EDIT: Just realized that the âCaddyfileâ is for handling non-SNI requests. But Iâm not really sure of that. 
Iâm not really sure if it could be properly fixed without using multiple IP addresses, I donât remember how many domains 5.0 requires, but from memory it could be anything up to 4; nexus.passport.com, login.passport.com, gateway.login.live.com, and login.live.com. There are others, but I think those are the ones necessary for earlier versions which auth via TWN. Even if you could set the non-SNI default to one of them, itâd break when MSN tries to hit the next domain, because itâd receive the same certificate as the previous (different domain) connection. Iâm no SSL expert though, so I might be missing something.
Edit: I wonder, maybe itâs possible to change the port number? Letâs say, for example, that MSN connects to ânexus.passport.comâ, thatâs 18 characters, what if MSN was to try to connect to (made up example) ânexus.log1p.xyz:81â? Then, if it requests âlogin.passport.comâ, it could hit âlogin.log1p.xyz:82â, and so on? I donât know if itâs possible, or where, to change all of those different domains, but perhaps that could be a workaround for older OSs? Maybe itâs too much of a pain to try, but just some food for thought I guess.
Iâm a bit confused, I believe the SNI issue was dealt with quite some time ago by making the default site on 35.185.201.91 to be the m1.escargot.log1p.xyz certificate/site. You can use MSN Messenger 7.5/escargot on XP just fine, as long as IE8 is installed (for TLS), TLS is on, SSL 2 is off and the root certs are updated, per your troubleshooting tool. And XPâs http.sys has no SNI support, regardless of IE version.
Then the next issue became the lack of a modern cipher suites that XP supports, the âbestâ being TLS_RSA_WITH_3DES_EDE_CBC_SHA, which wasnât being supported by escargot/caddy at the time, but I believe valtron dealt with that, at least thatâs when it started working for me and others on XP.
So I believe getting the TLS 1.0 support and the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher working on 9x would be the real issue methinks. Unless, Iâve missed something here.
1 Like
Iâm not sure how Escargot could work on multiple IPs (the auth service would have to contact the main server somehow to set and get auth data, which I see as impossible with my limited knowledge on server-server connections), but if it is possible, cool. 
Oh, really? Apologies then, seems Iâm a little behind the times, Iâve been rather busy lately so Iâve been unable to follow the project fully. Having said that, since we canât use IE7/8 on Win98, weâre still boned 
Edit: Perhaps downgrading the SSL protocol would work for 9x/2K then? I mean, thatâs not a perfect solution because itâs intentionally weakening the security, but⌠well, somethingâs gonna have to be traded off to make it work, if thatâs a goal that Escargot wants to hit. (Having said that, I donât think valtron is especially bothered by the lack of compatibility that far back, so Iâm just thinking out loud.)
Edit 2: Disregarding the element of historical preservation, looking at the situation purely in terms of the practicalities of running an MSN server so people can chat, Iâm sure 4.7.xxxx is quite sufficient for Windows 98. Letâs face it, Windows 98 comes with its own set of issues, and nobodyâs seriously running it as their everyday OS.
Weirdly enough, valtron set up the âm1.escargot.log1p.xyzâ domain, along with some others, to use TLS 1.0. But he hasnât set them up to use the âTLS_RSA_WITH_3DES_EDE_CBC_SHAâ cipher yet (whew, that was a mouthful). I wonder if thatâs the issue here?
When I wrote my own server I had the SSL stuff (admittedly very hackily) divided across various IPs on the same machine, which worked, and would work even on a live server, you just need a server that listens on multiple IPs (or one server listening on each IP which can communicate with the others/the database). But it would require lots of public-facing IPs to do it that way, which is expensive, so thatâs not ideal. I tested briefly on Amazon EC2, and it did function, but more IPs = more fees, so the cost would really add up over time - not great, given that Escargot already runs just fine on one server, except for the issues with older OSs).