You're reading the chart wrong. The chart states that the iPhone 3G, released in June 2008, ran the current OS for three years after release, which is correct: the iPhone 3G was updated to iOS 4.2.1, which was released on November 22, 2010, and it continued to run the current major iOS 4.x series until iOS 5 was released in October 2011. (Granted, it stopped receiving updates in March 2011 with iOS 4.3, but that was still the same major version series.)

The iPhone 3GS, meanwhile, will likely get support for at least 4 years, given that Apple is still selling the iPhone 3GS and, historically, provides at least 2 years of support.

As for the Samsung Galaxy, which Galaxy? The Samsung i5500 is pre-loaded with Android v2.1, in the summer of 2011. That's 2 major releases behind!

The Samsung Galaxy S II, meanwhile, was shipped with Android v2.3, which is still the current version (4.0 hasn't shipped yet). It's rumored to be getting ICS, which is good, but previous Samsung phones were also promised to get updates...which never happened. So we'll need to wait-and-see.

Why would Apple want to kill this?

MonoTouch is not significantly different from Unity 3D, which has been used to create over 40 games for iPhone already.

The primary difference is, instead of needing to create user interfaces purely atop GL, you can use the CocoaTouch libraries and get native buttons, frames, html controls, etc.

Microsoft did rebuild Windows from the ground up as a modern operating system. That was Windows NT (as compared with Windows 3.0) back in 1993. Thus, they predated the "let's rebuild the OS from scratch" thing that Apple did by 8 years.

That said, even as a modern operating system, it has a number of anachronisms kept primarily for backward compatibility with legacy 16-bit code, and has even more backward compatibility "hacks" for poorly written 32-bit apps (see the oldnewthing archives -- lots of apps do stupid things), but their priority is keeping existing code working, instead of breaking existing (poorly written) apps. I can't fault them for this.

The only thing removing such anachronisms would do is prevent older programs from working, which really does no one any good (unless you like the thought of Microsoft shooting their own lower-torso off...)

Don't get me started on the x86 (little endian, lack of registers, CISC instruction set, etc.)

Why not?

What's wrong with little endian? Aside from the fact that network-byte-order is big endian, I see nothing wrong with it. In fact, little endian has an advantage, at least in theory: arbitrary sized arithmetic. You could always add two numbers together, a byte at a time, check the carry flag, and then progress to the next byte, for *any* size number. This would allow trivial addition of multi-gigabyte numbers in very little assembly.

Lack of registers is largely rectified in AMD64/ie32e, in which 16 GP registers exist. Sure, it's not the 32 registers of PPC (or the 128 of Itanium), but it's sufficient for most code. It really doesn't matter anyway, since the CPUs keep track of dozens of registers internally as part of the internal register renaming system...

CISC? You must be kidding. Sure, the instruction set is CISC, but the internals of x86 CPUs have been RISC-like since the Pentium, with a hardware instruction decoder that converts legacy x86 instructions into internal RISC-like instructions. It's largely a non-issue today. (Yes, the hardware decoder takes up more die space, but it's a fixed size, and a constantly shrinking amount of die space as the dies keep getting bigger with Moore's law.) Plus, CISC acts as a sort of compression scheme, so that CISC programs are smaller than the equivalent RISC programs, resulting in lower memory pressure when loading/executing the code -- all good things when memory keeps getting slower and slower relative to the CPU.

There's really nothing fundamentally wrong with x86. If there were, it wouldn't be used as widely as it is (because if it were fundamental it couldn't be easily fixed).