I think you're looking at it wrong. Let me walk you through what I see/saw as someone who's been an active Linux, Windows, and Mac user since about 1996.

In 1993, I'd write a Windows 3.1 app with Win16, a Mac app with the Mac Toolbox, and a Linux app with one of Athena, Xlib, or (I don't remember if this was around at the time) Motif.

In 1996, I would have made some trivial modifications to my Win16 app to make a Win32 app for Windows NT or 95 (and Microsoft made this a lot easier with things like message crackers and typedefs); my Mac app would need a recompile to target PowerPC, but otherwise be fine; and my Linux app still requires no changes either. So far, so good.

By 2001, my Windows app still works perfectly. It'll look dated unless I make some changes to the manifest to indicate that I'm ready for the new common controls, but this is pretty straightforward to do; it's not a big rewrite. I can start heavily using COM without rewriting my whole code-base. My Mac app will have required a port to Carbon--significantly more work than the Win16 to Win32 migration, but not horrible, and my app's now native for the upcoming OS X.

But Linux? Wow. I mean, I guess I can keep running my app--it executes--but no one uses Athena, no use uses raw Xlib. I really need to port to Gtk+ 1.2 or Qt 2.0 if I want to look anything vaguely close to acceptable. And this is a major rewrite for me to undertake; they look very little like their predecessors. Yes, the toolkits are open-source, and yes, they still work, but let's be real here: I need to rewrite.

Let's move forward to 2005. My Win32 app still works, without changes. Granted, I might want to start using the nascent .NET, but Managed C++ and COM interop makes that pretty easy to accomplish piecemeal. On the Mac side, the writing's getting on the wall that Carbon's going to die, so I'm going to want to start porting to Cocoa, and that amounts to basically a full rewrite. I'm also going to want to start porting my app to Intel.

And on the Linux side, I've got to move to Gtk+ 2.0 or Qt 4.0. And that's again a big deal. If you weren't using Gtk+ or Qt back then, you should know that it was (at least in my opinion) a relatively large amount of work to upgrade. Not a full rewrite, mind you, but Qt redid piles of classes, methods, and hierarchy, and Gtk+ introduced glib, reworked signalling, themes, and tons else I'm forgetting. It was a lot of work.

Jump to 2010. My Win32 app fucking still works. Managed C++ is really mature right now. And if I wrote C# or VB or anything in WinForms, it'll also still work, and it can use COM objects I export from my old C++ app, and expose COM objects to my old C++ app. My Mac app, rewritten in Cocoa, still works fine, as long as I ported it to Intel, too; otherwise, users can't easily run it without installing Rosetta, an automated, if separate, install. I'm also going to be seriously thinking about trying to get it also running on Cocoa Touch for the i* devices, which have a radically different GUI toolkit. On the Linux side, the GUI of my app should still be in fairly good shape, although G-d help me if I did anything involving sound or 3D effects, since that API's gone through many wholesale changes in the last few years. And if I didn't write plain Qt and Gtk, but instead using GNOME and KDE, then...wow. I've had a lot of pain. I went through to KDE 4, which was a huge deal.

Now, we're leaving out that, in the 2005-2010 timeframe, Microsoft introduced WPF and Silverlight. So let's assume, in addition to my old C++ app that still works, I've now also got a few Silverlight and WPF apps I've written.

Now it's 2011. What happens on these three platforms?

On the Mac side, I'm in the same place: I need to be really thinking about Cocoa Touch, but my existing Cocoa app still works fine. If I didn't port to Intel, my app is dead, but that wasn't hard, so let's assume I did it.

On the Linux side, having gone through the KDE 4 transition, I'm now dealing with the GNOME 3 and/or Ubuntu-being-a-weirdo transition.

On the Windows side, in Windows 8, my old app still runs. My Silverlight apps and my WinForms apps and my WPF apps still run. The bad news is that they run in the legacy Windows desktop. So now, what has to happen to fix that?

My C++ app's GUI is fucked. Total rewrite. Really total, even worse than the Gtk+ 1.2 to 2.0 transition. WinForms, too. They're not coming to Metro.

But my Silverlight and WPF apps? Are you serious? It's very little work to get these running on Metro. Metro uses XAML really heavily, and has a very Silverlight-like view of the .NET libraries, actually. Most of the changes I'm going to make are mechanical and look-and-feel. This isn't trivial, but it's at worst a lot easier (IMHO) than the movement from Gtk 1.2 to 2.0 or Qt 3 to 4.

So you know what? At the end of the day, Microsoft looks really good to me. Great binary backwards compatibility, and really good toolkit compatibility. They've given me a really clean migration path from Silverlight/WPF to Metro that does most definitively not require a full rewrite. This is better than both other platforms listed above.

Me? I'll take it.