Yesterday, when I heard the news from Microsoft’s WinHEC announcements stating, “Windows 10 is coming to ARM through a partnership with Qualcomm”, my brain went through a set of loops, trying to get what this really was, and what it really meant.

Sure, most of us have seen the leaks over the past few weeks about x86 on ARM, but I hadn’t seen enough to find much signal in the noise as to what this was.

But now that I’ve thought about it, most of it makes sense, and if we view the holistic Windows 10 brand as step 1, this is step 2 of blurring the line of what a Windows PC is.

Before we look forward, a bit of history is important. Windows RT was a complex equation to try and reduce – that is, why did it fail? The hardware was expensive, it wasn’t <ahem/> real Windows, it couldn’t run legacy applications at all, and the value proposition and branding were very confusing. Wait. Was I talking about Windows RT, or Windows on Itanium? Hah. Tricked you – it applies to both of them. But let’s let sleeping dogs be.

So if the lack of support for Windows legacy applications is a problem, and ARM processors are getting faster, how to best address this? Windows 10, the last version of Windows. Now available in a complex amalgam that will be ARM64 native, but run Win32 x86 applications through emulation.

Let’s take a look at a couple of things here, in terms of Q&A. I have received no briefing from Microsoft on this technology – I’m going to make some suppositions here.

Question 1: What is meant by x86 Win32 applications? Everything? How about 64-bit Win32 applications?

This is actually pretty straightforward. It is, as the name would imply, x86 Win32 applications. That means the majority of the legacy applications written during the lifetime of Windows (those capable of running on 32-bit Windows 10 on x86) should work when running on 64-bit Windows 10 on ARM. In general, unless there are some hardware shenanigans performed by the software, I assume that most applications will work. In many ways, I see this emulation behaving sort of like Win32 virtualization on AMD64 systems, albeit with very different internals.

Question 2: Ah, so this is virtualization?

No, this is emulation. You’re tricking x86 Win32 applications into thinking they’re running on a (low-powered) x86 processor.

Question 3: Why only 32-bit?

See a few of the next answers for a crucial piece of this answer, but in short, to save space. You could arguably have it add support for Win64 (x64, 64-bit) Windows desktop applications, but this would mean additional bloat for the operating system, and offer rapidly diminishing returns. You’re asking a low-powered ARM processor to really run 64-bit applications and make the most of them? No. Get an x64 processor and don’t waste your money.

Question 4: What is the intent here?

As I said on Twitter this morning, “This is not the future of personal computing. This is a nod to the past.” I have written far more words than justified on why Windows on ARM faced challenges. This is, in many ways, the much-needed feature to make it succeed. However, this feature is also a subtle admission of… the need for more. In order to drive Windows the platform forward on ARM, and help birth the forthcoming generations of UWP-optimal systems, there is a need to temper that future with the reality of the past – that businesses and consumers have an utterly wacky amount of time and money involved in legacy Windows desktop applications, and… something something, cold, dead hands. Thus, we will now see the beginning of x86 support on these ARM processors, and a unified brand of Windows that addresses “How do I get this?” For consumers, it will mean a lack of confusion. Buy this PC, and it will be a great tablet when you want a tablet, but it will also run all of that old stuff.

Question 5: Why not just use Project Centennial, and recompile these old desktop apps for UWP?

First, for this to succeed, it must be point-and-shoot. No repackaging. No certificate games. No weird PowerShell scripts. No recompilation. Take my ancient printer driver, and it just works. Take my old copy of MS Money that I shouldn’t be using. It just works. Etc. We’re talking old apps that should be out to pasture. On the consumer side, there is no code, and no ISV in their right mind will spend time going back and doing the work to support something like this. On the business side, there’s likely nobody around who understands the code or wants to break it. Centennial is a great idea if you are an ISV or enterprise and you want to take your existing Win32 app and begin transmogrifying it into a UWP application through the non-trivial steps needed. But it’s certainly not always the best answer, and doesn’t do the same thing this will.

Question 6: Wait. So won’t I be able to get ransomware too, then?

I would have to assume the answer to that is… yes. However, it is important to note that Terry showed off Windows 10 Enterprise edition in yesterday’s demo. Why does that matter? Because there, you have the option to use DeviceGuard to lock down the device, on these PCs that will ship with OEM Windows. That is one step, for orgs willing to pay for Enterprise. I also assume that there will be the option to turn off the Win32 layer through configuration and GPO.

Question 7: So this is like Virtual PC on PowerPC Macs?

Not exactly. That’s a fine example of emulation, but that was Windows stacked on top of the Mac OS. This looks to be, as it should be, a more side-by-side emulation. Run a UWP app, and all of your resources are running on the ARM side natively.  Run a legacy app, and all your resources are running on the x86 side. Again, the experience should be much like running 32-bit applications on 64-bit Windows, without directory tricks to do it. That’s certainly what I saw in Terry’s demo. Importantly, this means a couple of things. First, you service the whole thing together. This isn’t a VM, and doesn’t require additional steps to service it. Second, where Terry mentions “CHPE = Compiled Hybrid Portable Executable” here, unless I’m misunderstanding, he’s saying that Windows 10 on ARM is basically running fat binaries. It’s two, two, two OS’s in one.

Question 8: Wait. What does that mean?

Well, if I’m understanding their direction correctly, the build includes resources for A64 and x86 in one binary. Meaning that you only need to service one binary to service both… modes? of the OS. Significantly, this also means some on-disk bloat. You’re going to need to have more space for this to work, as you’ve basically got two installs of the OS glued together. Significantly, this is also why you don’t have x64 support too. Because if my theory above holds, adding Win64 would… do amazing things to your remaining disk space.

Question 9: Ah, so UWP is dead?

Heck no. If anything, as I said earlier, this helps UWP in the long run, by reestablishing what Windows is. UWP is still what developers must target if they care about selling anything new, designing for touch, or reaching the collection of devices that Microsoft is driving UWP forward on. I also can envision that this functionality only works when a device is Continuum’d. That is, when you’re docked and ready to work at your desk. This is all about legacy, and your desktop.

Question 10: Ah, so Intel processors are dead?

LOLNO. This is an ARM processor running x86 software. No x64 support. Performance may wind up being fair, but an ARM system will hardly be your destination if you want to do hardcore gaming, data work, development, run VMs… and then there’s the server side, where ARM still has a huge uphill battle ahead of it. This will fill a hole for consumers and low-mid tier knowledge workers. If you cared that the new MBP didn’t have more than 16GB of RAM, well… I digress.

Question 11: Ah, so Windows Mobile is dead?

No. At least not yet. Windows Mobile won’t include this layer, which will likely mean that it also won’t require the storage space. In the long run, a Windows-based ARM64 phone could indeed run Windows 10, and finally blur the line as to what is a Windows phone and what is a Windows PC – and also make Continuum incredibly useful.