Internet Black Holes

My previous post was about preserving MSN Messenger versions, and since that post I’ve been trying to collect yet more to record and test. It turns out that the internet is transient (who knew?) and so many links have been broken. Various files removed from their previous homes, various FTP servers no longer operational, and various websites long gone, to be replaced by holding pages and parked by web hosts.

Some versions were leaked or betas but functional, and so archived to some extent by the MSN community. Others were less fortunate, being leaked but non-functional, or only briefly available, to be replaced by more functional (and officially available) versions, these are more difficult to come by. What use is there in keeping a piece of software that only existed for a week and didn’t work anyway?

Despite this, I have managed to collect more versions, towards what is probably one of the largest collection of MSN Messenger/Windows Messenger/Windows Live versions anywhere. If it’s not, I shall be very disappointed, as I’m running out of places to look for these versions.

Now to the fruits of this endeavour:

Three interlinked blogs listing all of the versions I’ve managed to find, of MSN Messenger, Windows Messenger, and Windows Live Messenger respectively. Technical details and screenshots are included where possible, and when I get over the ludicrous amount of installing, uninstalling, reinstalling, screenshotting, and recording protocol information, I may add more data to these pages. I don’t expect it to be useful to anybody, but there it is, my input into preserving the history of MSN Messenger and its descendants.

Time Compression

Obligatory acknowledgement of blog neglect.

Now that’s over with, here’s a new project I’ve been working on, and an observation that although an online service can feel like it’s been around forever it’s not as long-lived or immortal as one might imagine.

In the UK during the 2000s, when many Americans might’ve been chatting to their peers using AOL’s AIM or Yahoo’s Y!IM messaging clients, the platform of choice seemed to be MSN Messenger. Spawned from Microsoft in 1999, this instant messaging service was much like any other, offering a free chat platform with basic text conversation and contact management functionality, and a desktop client with which to connect to and use the service.


MSN Messenger 1.0 running on Windows 95

For teenagers with a computer, or access to one, this provided a private channel to conduct their social lives through, as nobody had invented Facebook yet and mobile phones were still reasonably expensive (and generally not very smart either). As a result, it left a mark on lots of people who were growing up at the time, searing a brand into memories that today evokes nostalgic pangs whenever someone reminds them it existed. Long story short, Microsoft bought Skype in 2011 and then decided to throw the well-loved MSN Messenger (or, by this time, Live Messenger) brand and clients totally out of the window, shuttering the service in 2013 (or 2014 for China).


MSN Messenger 2.5.0 for Mac, running on MacOS 9.2.2

Unfortunately, this means that anybody wishing to timeshift and experience the look and feel of the client over the years is unable to do so, as without the back end service to connect to the clients will do nothing and are stuck showing a login window and perhaps throwing an error about how they can’t connect. I don’t particularly like when things like this happen, so I set about trying to revive the clients by providing them a service to connect to again.


Windows Messenger 4.7 running (and available only) on Windows XP

There have been a few servers written to emulate the service as it was, mostly in Visual Basic 6, although most attempts (although quite functional) are unable to support versions of MSN Messenger/Windows Messenger later than 4.7 as a result of protocol changes. This gets you to about 2002, about three or four years worth of MSN nostalgia. But there’s another decade of history to be had, so I thought I’d have a crack at trying to support later protocol/client versions.


It’s not pretty, but it works. A bit.

I’m pleased to say that I’ve managed an improvement over those early servers, reaching Windows Live Messenger 8.5 (also known as WLM 2008). Partially.


Windows Live Messenger 8.5 running on Windows XP

I’ve not yet implemented much of the required back-end workings and some of the protocol is poorly implemented and incomplete, but at least the majority of clients (spanning about a decade of the 14-15 year existence) are able to log in. I’ve been having issues trying to get later versions to connect, as at this point Microsoft had altered the login process substantially for a third time. But perhaps in time, who knows? For some reason, after version 8.5, Microsoft decided when putting together a version 9.0 beta that the number should jump inexplicably from 8.x to 14. This means that after this 2008 version there were only three more major versions; 2009 (version 14), 2011 (version 15), and 2012 (version 16), released as parts of the respective Windows Live Essentials suites. Technically the Windows 8 Messaging client is an MSN client too, effectively version 16, but unless I support it accidentally I’m not too fussed about it (did anybody actually use it?). So far I haven’t looked at what’s required for webcam, voice, file transfer, or other non-chat functions, but these are on my todo list for future investigation. Chatting with more than one other contact in a single conversation is possible but currently buggy.

I’m not hugely fond of my own code, but it would seem to be a shame to work on this project under the guise of historical preservation and then simply stash it away in a graveyard hard drive, so I do intend to release it in some form. I don’t know when, or in what form, because I’d like it to be more complete first. There are also complications because to successfully support most versions requires multiple servers to manage authentication and, later, contact lists, and the way that’s¬†implemented requires multiple IPs addresses (even though a single machine is sufficient) so some sort of configuration guide (and non-hardcoded test code) would be required. I’m also fudging security aspects of the logon process (pretty much entirely in later versions), so as it stands my server is unsuitable for general use and is ultimately a novelty. I wouldn’t expect that anybody would use it for any serious purpose anyway, but it should be noted that its only design goal is to enable the clients to (mostly) function and that it shouldn’t be considered a viable, stable, or secure method of communication.

In the event that it’s useful to somebody, I have added a list of MSN/WLM client versions that I know to exist or have tested here. It is incomplete, but will probably be updated as I find/test more versions.

Edit: Check out this post instead. It contains links to the current iteration of this information.

Hell Is Other Peoples’ Code

My primary target for the set top box project is, of course, the Raspberry Pi 2 – it’s a handy platform to build simple embedded appliances on, just like a little set top box, but I wanted to expand its reach a bit for showing offtesting. My first thought was to port it to Windows, but after much arsing about with msys2 and mingw32 and getting precisely nowhere, I eventually gave up and turned to Linux. Many hours and much staining of my desk with the blood from my forehead, I have just about managed to port something resembling my project sufficiently that it runs in a Debian VM. See exhibits A and B below:

You’ll note that it’s not perfect, the text rendering is boned and I’m going to have to attempt to fix it, because it looks horrible, and video streaming is touchy at best (potentially requiring transcoding, which is too CPU-intensive for dozens of concurrent channels, at least without dedicated machines to do it).

But, during this painful misery of hacking at crap code, I have learnt one thing: just because a framework exists does not mean it’s a good idea to use it. I’m using openFrameworks to build this project on, I discovered it some time back and latched onto it because it allowed me to quickly set myself on the path to being able to program graphical things for Linux. All very well, of course, it did very much speed my path to being able to do so, but it turns out that it’s not as “standard” as you might expect. It uses different video libraries on just about every platform, and it doesn’t do a terribly good job of hiding that fact. Admittedly, my Pi code makes use of ofxOMXPlayer, which is a plugin designed explicitly for the Pi and nothing much else, but on Linux in general it uses GStreamer (inefficient and slow on the Raspberry Pi), on OSX it appears to use QuickTime, and on Windows it… well, I can’t even work out what it uses, but it sure didn’t work.

My solution to this seemed simple. Pick another plugin, one that’d work cross-platform, VLC perhaps. Alas, I was thwarted by the fact that the early efforts to include VLC by what I believe to be one of the openFrameworks devs had been abandoned, and the only other option looked like it was probably a lot of hassle to work with. Other plugins seemed to be platform-specific or incomplete too. Call me lazy if you like, but what’s important to me when I’m writing code for a project is being able to write code for my project, not spending days fruitlessly wrestling with stuff that’s probably not going to work no matter how hard I try, or helplessly pawing at my keyboard in the vain hope that I might be able to pretend I know what I’m doing with just enough capability to hack something towards functionality.

So ultimately I ended up with Windows not being an option, Linux being just barely possible (with work), and the Pi version being about as unstable as it ever was. I don’t mean to be an arse about people contributing free code to the world, and mine certainly isn’t brilliant, but I really do wish that this stuff was easier to work with. In this case, it’s openFrameworks and all its associated third party plugins, and if it worked the way it claims to it’d be brilliant, a simple cross-platform framework that includes more than the basics, a plethora of tools and code to get you started. But that’s the bait that get you hooked. It turns out hooks are painful.

A Remote Chance of Success

Progress, as I’m sure you can establish from the (in)frequency of posts here, has been rather slow, but I have attempted to resume development of my Sky prototype reproduction. I’ve added the basis of the menu system (besides the EPG, which I had already written), so I should be looking to add the actual menus in time. Below you can see the beginnings of the menu system:


The interactive “page” is actually a placeholder even in the real firmware, for a year or so at least, the interactive services hadn’t yet launched, but the boxes had been released with the future functionality in mind. They promoted the not-yet-available functions as a future perk, which would be added when it became available (which it was, in 1999, I believe). Luckily for me, that means I don’t actually have to do anything more in this section, beyond tweaking the “coming soon” banner to be sized more like the real thing.


If you’ve used a Sky receiver before, you’ll know that the icons at the top of the screen aren’t usually yellow and blue, but I have a bit of a problem here. I partly chose blue and yellow just for the sake of testing, it’s nice and easy to see the difference, easier than two shades of blue. However, to the best of my knowledge there are no screenshots or demos of this area of the UI dating as far back as the EPG screenshots I’m basing my work on. This might be because they hadn’t designed/written the menu system yet, or just because they didn’t feel the need to show it off, I don’t know, but the problem is that the icons on the retail firmware are blue and white. But I can’t use white, because the prototype design uses a white background. So I’m left to guess or improvise, and blue/yellow is what I’ve chosen for the time being.


I’ve also picked up a FLIRC IR receiver dongle, and I can now control what I’ve written so far with an official Sky remote control, which feels much more natural. However, the FLIRC dongle has a habit of sending certain button presses a number of times at once, so I’ve had to artificially slow the responsiveness of the UI in an attempt to prevent unintended actions. I don’t know how else to fix this issue at present, but it’s hardly the first issue I’ve had, so it’ll go on the list of “things to attempt to fix properly at some point”. I’ve also added the ability to use the channel up/down buttons to navigate for channel hopping, however this exhibits some problematic behaviour at present, either reloading the current channel or skipping several at once.


See that? That’s the absence of teletext. I know it works, it works on my TV, but try as I might (and I have, I bought yet another capture device for the job), I can’t get my PC to “receive” teletext for capturing examples and demos. It might be DScaler, the capture application, but there seem to be so few options for doing things like this, particularly on more modern operating system versions.

Segmentation fault

I’m still having to wrestle with, or more accurately grudgingly tolerate, the instability of the libraries the application is based on. It’s exceptionally good at segfaulting, which is incredibly unhelpful. I think it could probably be worked around by ensuring that the network connection is rock solid and the video files are encoded in a codec as friendly to the video decoder as possible. It’s not foolproof, but it’ll have to do, unless I figure out how to fix that as well.

That’s about where I’m at right now, I’ll continue to incrementally improve it as well as I can, and I hope when I’m “done” it’ll pass for a functional application.

Pictures. Except moving.

A couple of test videos, to show the UI in action, at various stages of workingness.

It turns out the version of ffmpeg included with ofxOMXPlayer is a bit on the iffy side, which was mildly problematic. There’s a branch with a newer build, which at least solved an issue where if a stream ended then the whole thing would segfault, but several issues remain. Specifically, if a stream doesn’t exist it’ll hang the program for a little over 2 minutes while it waits to timeout and the difficult to miss frame smearing primarily in the bottom half of the video. I’m sure these issues will be fixed in time (the latter appears to be related to a buffer or something, I gave up looking for the time being).

Now, streams, a TV receiver isn’t much use without TV channels, is it? As mentioned, ofxOMXPlayer (and the project it’s based on, OMXPlayer) is based on ffmpeg, so that’s the receiving side of the equasion. The sender is currently VLC, which has some handy command line options so I’m able to stuff everything into a batch file, run it, and instantly have 6 channels (7 if you include the EPG music, which is also a stream), all live at the same time, running with very minimal CPU usage (by choosing not to transcode on the fly). I suspect I could run dozens of channels at least, so room for expansion. In the second video, you’ll see an Amiga advert transition to a Sega advert, these are two different clips and I’m very pleased with the way they run together so smoothly. I think this setup does a pretty decent job of simulating a TV channel, but I’ll have to figure out a way of getting the programme data to the interface’s EPG at some point.

No Signal

Alright, so that’s the very basic now/next bar and the channel menu, what else is there? What if there’s an error, a channel is off-air perhaps, or you’re not subscribed? You’ll get a blue screen instead of a TV picture, and an informational banner, like so:


Easy peasy, let’s have a crack at that:


That’ll do nicely. This image also shows what’s displayed when a channel’s EPG data is unavailable and there’s nothing to display. There’s something a little off about my fonts and UI element sizes, but I’m having to work from assorted rough screenshots and poor quality videos, I’ll try to refine them as I go along.

Short post this time, I’m running out of progress to report, but hopefully there will be more in time.

Time Travel

So what was up with that font? Well, as it happens, there are a (precious) few sources for even earlier examples of the UI, as far as I’m aware they’re from before the launch of the service. This video, captured from the service’s information channel in 1998, shows what appears to be a version of the UI using the slimmer font for the programme info:

Time to go a little deeper, perhaps, what if we want to browse for channels instead of simply flicking up and down in a tiny box? This is where it gets a little exciting for me, I’ll show you what it normally looks like first, and then I’ll explain why mine doesn’t look like it:

2003 TV Guide-650-80

That one’s a capture from 2003, and I believe that’s more or less how the SD receivers still look. But let’s go back, all the way back, somewhere around early ’98, possibly even late ’97*:

_161218_digital_channel_guide300 skyepg1 skyepg2

I blindly tripped over these beauties lurking about the web, as all good things do, and they look quite different from the 1998 launch interface, which looked like this:


The layout is similar, but what’s up with the logo? In 1998, Sky rebranded and their shiny new digital service got a fresh new logo, as seen in the above image, but before this rebranded they used the “egg” logo you see in the three previous images. To the best of my knowledge, this version of the UI never reached the public, but some set top boxes and accompanying remote controls with the old logo did hit the shelves. For how long, I don’t know, but this is a very small glimpse into the window of time between the rebrand and the launch of the service, which is pretty neat. I’m not absolutely certain that the images showing what I’ll call the prototype UI are, in fact, official or actual working firmware, but they look pretty legit to me, they’re clearly early models of the release interface and it seems to me to be a convincingly small step from one to the other. One other thing to note, the channel numbers given to the movie channels aren’t the final numbers, because the low 100s (the listings begin at 101) were general entertainment on launch, starting with BBC1 and BBC2, as seen in the release EPG. There were no BBC channels on Sky’s analogue service, so it’s possible that the content the service was to carry hadn’t been finalised yet.

So what might that have looked like, if we’d had good screenshots of it? Something, I reckon, a little like this:


I don’t have the guts of the EPG going yet, so I can’t populate the guide, but the navigation works except the +24h and A-Z because I haven’t done the rest of the menu system yet. I can scroll up, down, page up, page down, and select a channel.

Post-article speculation:

* A bit of detective work reveals that many of the movies listed on the 3rd and presumably earliest image were released to cinemas late ’96. If the date is anything more than a placeholder, it could be April or July ’96, or September or December ’97, and given that two of the movies were in cinemas in Nov/Dec ’96, it seems likely that it would be one of the ’97 dates, which would probably be a reasonable length of time for the movies to find their way to pay TV. That would mean less than a year before the Oct ’98 launch date of the service, and allowing time for testing and manufacture, perhaps closer to 6 months between these versions and the retail firmware.

However, in the first image of the three, the movie When Innocence Is Lost appears, which was released to US cinemas in April ’97, and given the apparently textured background my assumption would be that this is newer. This screenshot could, again if the date is real, be Sep/Dec ’96 (before the movie), Jun ’97 (too soon after the movie?) or Feb/Mar ’98.

So for all that, we can probably guess that the earliest screenshot was from late ’97, and the latest from early ’98. Then again, all three screenshots seem to say they were taken on Tuesday, so perhaps it’s just a placeholder.