> The question is: How much does it actually cost them (in dollars) to support XP?
It's not straightforward to convert the cost into dollars. There's an opportunity cost, because the people who are working on the XP codebase could be doing other things. If they're at all good at what they do, Microsoft would much prefer to have them working on other things (say, on bug fixes for Eight).
Part of the problem with maintaining an old code branch is that at some point you have to decide whether you actually want to maintain it or not. At some point the answer is always no, the newer versions are better, we no longer want to mess with doing X on the old version. Over time, the value of X escalates. There's an inherent progression, because as you do less work on the old code branch, it becomes not only more obsolete but also less familiar and less well maintained. When you stop doing new feature work on the branch because you're getting ready for release and want to sort out the bugs, you have entered the "Golden Age" for that branch of the code and started an inevitable progression. Without feature work, there is no motivation for infrastructure work or refactoring. With nobody doing feature or infrastructure work or refactoring on the codebase, the level of familiarity with it fades. Bugs take longer to track down and fix. Worse, the consequences of any changes that you make are not immediately obvious to anyone (because, remember, nobody is intimately familiar with this branch of the code any more), and furthermore users have come to expect a certain level of stability, and so the level of testing needed for each change increases. At some point bugs that aren't security relevant and don't cause loss of data no longer seem worth fixing. So you don't bother any more. Now your developers spend even less time working with -- and are even less familiar with -- the code. You go from "bug fixes only" to "important bug fixes only" to "critical and security-relevant bug fixes only" to "security fixes only" and eventually "critical security fixes only", and sooner or later you throw in the towel entirely.
This is not specific to Microsoft. Ask the guys at Debian why they no longer provide security updates for sarge (which is newer than XP by several years; in fact, I think it's newer than SP2). They no longer provide security updates for etch or lenny either. Updates are available for stable (currently, that's wheezy) and oldstable (currently squeeze). The precise economics of how security updates are provided and what resources are expended in providing them are of course very different for Debian as compared to Microsoft. But certain things are the same, and one of those things is, producing security updates for old no-longer-actively-maintained branches is proportionally more resource intensive than producing security updates for current and still-actively-maintained branches. Given the tendency of old branches to accumulate, at some point you have to have a cut-off date.
I say this as a network administrator who still has a number of Windows XP systems on the network at work, and not enough budget to replace them all in 2014. My current plan is to replace as many as possible of the remaining "front-line" Windows XP systems (i.e., the ones that are connected to the internet and directly used by ordinary users on a day-to-day basis). Non-internet-connected Windows XP systems will not be replaced in 2014, nor will ones used mainly by IT personnel, and a couple others might get converted to Debian wheezy (which runs better on old hardware than Seven -- we are not deploying Vista or Eight at this time). That'll only buy them an extra year or two, but it might allow our replacement hardware budget to stretch just far enough. Not every system is eligible to be considered for conversion to Debian, for various reasons, but it's a possibility for some of them.
Nonetheless, I don't begrudge Microsoft the privilege of discontinuing support for XP. You know when you deploy a new system that eventually it's going to be end-of-lined. If anything we artificially shortened this timeframe for ourselves by choosing NOT to deploy any Windows XP systems until after SP2 came out. If I had to do over again, I wouldn't change that.