In September, we began asking users on 8.1 clients to upgrade to the latest version of messenger to ensure that they had the most up to-date and secure release. (see post)
Starting today, users on version 8.5 will also be required to upgrade before they can sign-in to the service. Starting on the November 9th, users on Messenger 2009 (version 14) will need to upgrade their clients too. Users who have already installed the latest version, which was released Aug 18th 2009 (Build: 14.0.8089.726), will not be required to upgrade.
If you are using Messenger 2009 and are curious what version you have, you can go to the Help –> About Menu.
If you have any issues or questions during the upgrade process, here are the places you can go to get some answers.
| This post from the support team provides some guidance into how to determine what error you are getting and steps to resolve many of these. | |
| You can also try the online help pages. On the left hand side, you can select ‘Table of Contents’ (near the bottom) and get information on troubleshooting and error codes. | |
| If you have already tried the going through the online help suggestions and still having difficulties then you should consider contacting the Messenger support team and providing them with more information about the problems that you are encountering. |
Note: Users on Windows XP will need to ensure that they have installed Service Pack 2 (SP2) or higher, otherwise the upgrade will not work. Instructions to install the latest Service Pack (SP3) can be found here. Additionally, here is more information about the system requirements.
Thanks for everyone’s continued support.
Sincerely,
The Windows Live Messenger Team

I've sometimes thought that optimizing web applications is as much a science as dowsing. (No offense intended, dowsers of the world — but you have to admit it's a hard thing to explain even when it does work out.) Even when you are completely willing to invest time and energy into optimizing an application, how do you actually go about it?
Our team, along with everyone else in the world who cares about web application performance, has had to essentially guess at where time goes inside the browser. We've spent countless hours debating each others' wild-eyed speculations as to the true sources of latency afflicting a wide variety of applications. Indeed, web apps can be slow for all sorts of opaque and unintuitive reasons. Don't be fooled into thinking that bloated, slow JavaScript is the only culprit. We've seen pathological situations in which a few seemingly insignificant CSS tweaks can improve performance by a factor of 5 or more. Another dark gem: rearranging a mere few lines of JavaScript that were inadvertently calling DOM-related methods in an unfortunate sequence (which caused multiple redundant layouts) turned a life-negating 5 second operation into a sprightly 50 millisecond blink of an eye. That one took 5 days to find the offending 4 lines of JavaScript and then about 3 seconds to actually make the code change. #nowiamwaybehindingooglereader
We couldn't take it anymore. We decided we had to find a way to transform the witchcraft of optimizing web apps into a legitimate engineering task, once and for all.
My team began working on a series of changes to WebKit and Chrome to collect precise metrics on where time is, in fact, going within the browser. When, exactly, does layout occur? How long does each layout take? Can layout happen synchronously while my JavaScript is executing, or is it deferred? How much time is spent on CSS selector matching? How long does parsing (versus executing) JavaScript take? Does the process of actually painting pixels on the screen take much time? We instrumented the browser way deep down inside to produce a stream of such metrics, being very careful to keep observer effects to a minimum.
Happily, we've managed to land these changes into both WebKit and Chrome over the last several weeks. Soon you'll see the first examples of tools that make these metrics available to web developers using WebKit-based browsers. Of course, we have a lot more instrumentation planned, but the ball is really rolling now thanks to lots of help from the friendly folks on the WebKit and Chrome teams (especially Pavel Feldman and Timothy Hatcher). We've gained many new insights, some of which I mentioned in my Measure in Milliseconds talk at Google I/O earlier this year. When you see these metrics yourself for your own web apps, you'll likely be surprised — and you'll almost certainly wonder how anyone tried to write high-performance code without this sort of insight. Be sure to keep an eye on the Chrome Dev Channel and the WebKit nightly builds for new Inspector features based on our work.