Today I noticed this announcement from Intel, regarding the ARM versions of Windows 8: http://www.eetimes.com/electronics-news/4216110/Intel-says-ARM-gets-Windows-four-ways
It seems that Intel is trying to spread some FUD regarding ARM. As I mentioned in a previous blog, the ever faster variations of ARM CPUs being developed could actually take a piece of the desktop/notebook market when they can run Windows. By the looks of it, Intel is starting to worry about this as well.
They focus on the only redeeming value of the x86 architecture: legacy support. While this has always been an important factor in the DOS/Windows world, other markets have never been too hung up about legacy support, backward compatibility and that sort of thing. For example, the UNIX world tends to limit compatibility to the API layer, and just recompile portable C/C++ code for different architectures. There’s a large variety of UNIX OS flavours running on an even larger variety of CPU architectures.
Then there’s Apple, who switched CPU architectures twice on the Mac platform (started on Motorola 68000, moved to PowerPC, and now Intel x86). They solved the transitions using a CPU emulator built into the OS. These transition went quite smoothly as well, and Apple has been doing quite well in recent years.
Finally, there’s the mobile world, which is more or less where the ARM is coming from. On mobile devices, such as phones, compatibility is usually solved using a virtual machine at the base, such as Java or .NET (Android being a fine example of that, with Dalvik).
I expect the Windows versions of ARM to have a bit of everything. I think that .NET/Java will be the most important factor in the beginning. .NET/Java applications written for Windows on x86 will generally run as-is on the new ARM architecture, since the virtual machine will take care of the generation of the actual ARM code. Software such as OpenOffice should work right away. Aside from that, the focus will mostly be on mobile devices at first, such as phones and tablets. A lot of software for such mobile devices is already written in Java or .NET compact (e.g. for Windows Mobile/CE), and should run as-is.
Then the next step is the recompiling of C/C++ code. Like UNIX, the Windows API in itself is designed to be portable to different architectures. Over the years, Windows has run on various CPU architectures, including x86, x64, Itanium, PowerPC and MIPS. As long as applications have been written neatly, they should recompile to ARM with little or no effort (and writing applications neatly has become increasingly important with the recent migration from x86 to x64). So we will probably see a lot of applications becoming available for native ARM as well.
Finally, there will probably also be an x86 emulator. Even if Intel is correct about Windows for ARM not supporting binary compatibility with x86 out-of-the-box, that doesn’t mean that there won’t be a third-party solution for this. Granted, it might not be the most feasible option, especially at first, since ARM CPUs tend to be considerably less powerful than x86 CPUs anyway, at this point, and having an extra emulation layer would only make them slower. But for a lot of applications, performance will probably not be that much of an issue.
At any rate, it will be interesting to see how this whole issue develops.