The real reason why you’ll never get Windows 10 on your Surface RT tablet

"What Intel giveth, Microsoft taketh away". That was the mantra my colleagues and I adhered to when I was leading Intel’s PC benchmarking efforts in the early 2000s. As the resident "HOC" (Highly-paid Outside Consultant) to the company’s Desktop Architecture Labs (DAL), my job was to help Intel’s engineers design the most complex desktop runtime environments possible for the purpose of showcasing the performance advantages of each new PC chip generation. And thanks to a steady stream of increasingly CPU-hungry Windows and Office releases, our thirst for new and interesting stuff to stack atop our shiny new Pentium III and IV test rigs was always satiated.

Then came Windows Vista, and for the first time the CPU demands of Microsoft’s software stack outpaced the average performance of even state of the art Intel designs. Suddenly, Windows was "too fat" to fly, and the subsequent backlash saw the long overdue departure of Vista’s architect Jim Allchin, the ill-fated rise of Steven Sinofsky to Windows development boss, and the much anticipated emergence of Windows 7 as the anti-Vista: A new version that was actually less demanding (in terms of CPU, memory and disk footprint) than its predecessor.

This trend continued with Windows 8 and 8.1. Both versions sported overall runtime overheads comparable to Windows 7. If a PC performed well under Windows 7, it would likely continue to perform well under Windows 8.x.

But then a funny thing happened on the way to version 10: Windows started getting fat again. Not in any outwardly obvious ways -- memory consumption and on-disk footprint remained in check -- but in the underlying complexity of the core runtime environment. In their headlong pursuit of a "One Windows, Many Devices" strategy, Microsoft’s engineers introduced a number of subtle changes designed to make the platform more flexible and adaptable.

For example, they rewrote significant portions of the Windows shell in XAML (eXtensible Application Markup Language) in order to make it more dynamic and "skinnable". They also tweaked the Desktop Window Manager (DWM) process and introduced an entirely new helper process -- ShellExperienceHost -- to enable integration between the new class of Universal Apps (which are also written in XAML) and the reengineered Windows shell.

All of the above could be considered positive steps. They make Windows more flexible, more adaptable and easier to update in the new piecemeal, SaaS model coming post-Windows 10. But they also introduce significant new layers of code, and this translates into additional CPU overhead vs. the previous generation, DirectUI-based shell of Windows 8.x.

In fact, a quick poke around Performance Monitor running under both Windows 8.1 and Windows 10 shows the latter generating significantly higher CPU utilization (71 percent vs. 35 percent) when conducting simple tasks like invoking the Start Menu (or Start Screen), navigating File Explorer windows, searching for installed apps or settings and generally mucking around the base UI. Breaking it down further, the two aforementioned processes -- DWM and ShellExperienceHost -- are gobbling up a combined 35 percent average CPU time, over triple the overhead of Windows 8’s DWM implementation. All of which can be traced back to the new, more complex code path for drawing and managing the Windows shell.

Note on Methodology: The above tests were conducted in identical test Virtual Machines running under Oracle Virtual Box 5.0.4 on Windows 10 Pro. Both VMs were configured with 1GB of RAM, a 10GB (Dynamic) Virtual Disk Image, and otherwise followed the default recommended settings for each OS. Metrics data (specifically, the Processor and Process objects) was collected via Windows Performance Monitor over a 10 minute period of activity involving the basic tasks outlined above. The test scenarios were repeated three times and the values averaged across the scenarios.

Here’s the kicker: I suspect that it’s this added overhead (and not "poor sales" or the myriad other excuses) that ultimately forced Microsoft to abandon any plans for porting Windows 10 to the legacy Surface RT and Surface 2 platforms. Simply put, Windows got "too fat" again, and its growth outpaced the feeble Tegra 3 and Tegra 4-based CPUs underpinning Microsoft’s first and second generation consumer tablets.

With single and multithreaded processor performance as much as 2x slower than the Intel Atom-based Surface 3, and with memory bandwidth performance as much as 60 percent below the newest consumer Surface, even the relatively current (you could still buy one from Microsoft as recently as January of this year) Tegra 4-based Surface 2 is lagging well behind today’s CPU trends. And if Surface 2 struggled at times to pull the weight of the much less demanding Windows 8.x code base (nobody every accused any ARM-based Surface of being particularly fast), it’s not hard to imagine how badly such a device would choke on the much more complicated Windows 10 software stack.

And that is exactly what I suspect happened internally at Microsoft: It ported Windows 10, realized the fancy new XAML-based UI was swamping the CPUs of their underpowered ARM-based tablets, and aborted the project. In its place, it gave users Windows RT 8.1 Update 3 and a less demanding, DirectUI-based "Start Menu".

Note that this also explains why Microsoft is requiring a new breed of Windows 10 Mobile handsets in order to support the forthcoming "Continuum" technology (it’ll need to have enough CPU "horsepower" to handle Windows 10’s demanding XAML-based runtime model). And it also means that those questioning why Microsoft’s engineers don’t just "port Windows 10 Mobile to Surface RT/2" are missing the point: "They would if they could, but they can’t so they won’t".

My old Intel DAL colleagues will be most pleased.