Today I was reading some news(1, 2, 3, 4) about Microsoft Windows 8 and saw that one of the new features is that it can run over a ARM processor based system. This make me wondering the reasons that it cannot be done with the current release version of Windows(Seven).

What are the actual limitations to Windows 7 to be aware of installing it on a ARM processor based system? It would have to do with kernel version, drivers, architecture or even a mixture of these factors?

Until I know, I can install Linux on a ARM, so I cannot even install Windows Seven under VMWare virtual machine on a ARM?

  • 1
    Note that Windows 8 is slated to run on ARM. windows8news.com/2011/01/05/… Aug 26, 2011 at 18:36
  • 1
    You can install Windows 7 in a virtual machine running in an ARM operating system. You just need to find a virtual machine program that both runs on ARM and is capable of running an x86 guest. Aug 26, 2011 at 22:58

3 Answers 3


For binaries to run on an ARM processor, they have to be compiled for that processor specifically or be run in an emulator.

Since Linux systems are open source, people can compile them specifically for ARM systems and rewrite any x86 specific code. Because the source for Windows is closed, unless Microsoft releases an ARM version, it cannot be recompiled and run on it.

There are other problems with moving to ARM systems, but this is probably the biggest.

As far as I know, VMware will not emulate an x86. I think qemu may be able to, but I have not used it for ARM emulating x86 before, just x86 emulating ARM. There will be a significant performance hit if it does work.

While any program needs to be compiled for the architecture it is intended run on, an operating system often needs to be much more customized to the specific architecture. Operating systems are responsible for things like scheduling and task switching, which work with the processor at very deep levels.

  • 8
    Note that you could generalize the first sentence by removing the word "ARM" and still have a true statement - as a rule binaries always have to be either compiled for the architecture they're running on, or else have an emulator or interpreter layer.
    – Shinrai
    Aug 26, 2011 at 14:28
  • 4
    @jhulst I've used qemu to emulate x86 on PowerPC, and, yes, it is incredibly slow.
    – Cajunluke
    Aug 26, 2011 at 14:28
  • Supposedly VPC (which MS bought) did x86 on PPC decently with dynamic recompilation. Granted, this was ages ago, and i never actually tried it myself. QEMU is horrible other than its portability IMO. It does some things VERY well (like not needing kernel hooks) but its inefficient.
    – Journeyman Geek
    Aug 26, 2011 at 14:37
  • This QEMU port to ARM host platform doesn't look very mainstream and I couldn't find any others. Aug 26, 2011 at 14:44
  • Device drivers would also be an issue, especially for any unique stuff limited to ARM systems.
    – CarlF
    Aug 26, 2011 at 14:49

The simple answer is "MS hasn't released a port" (though Windows 8 is supposed to be ported to ARM), simply cause it made no business sense at the time. If you want to go into, if MS could...

Well, historically, the NT family has run on a range of processors - NT ran on Alpha, PPC and MIPS , and there were planned ports for the Clipper and SPARC architectures. This is possible because Windows NT abstracted the hardware dependant parts of the code (the HAL) and rewriting just that section and recompiling everything else should do the trick (though in theory .NET based software is supposedly hardware independent).

Unlike Linux, which, if i recall correctly has seperate kernel branches for each architecture, supposedly ONLY the HAL is hardware specific, and the rest is common – I believe that once a HAL for the ARM platform in question was created, it should be relatively trivial, and no different from coding for various bits of hardware, especially if the system was otherwise conventional, say, using PCI-E and other industry-standard interfaces.

Assuming Microsoft released a ARM port of Windows 7, any software that isn't interpreted, or running on a VM of sorts like JVM, LLVM or CLR would need to be recompiled or run on a translation layer, like Rosetta or the old 68K compatability layer on older macs, that's aware of x86 specific code (and runs that in emulation transparently), and there's sufficient processor power for translation.

  • .NET software can run on almost any major architecture using Mono, which is an Open Source compiler/runtime for .NET programs that runs under most major operating systems. This isn't directly relevant to the original question, of course.
    – CarlF
    Aug 26, 2011 at 14:42
  • Well, no. It is relevant for the part where 'software would need to be recompiled'. I do believe CLR is potentially platform independent, and/or .net code is optimised/compiled on install. I totally forgot about mono, unfortunately, its one of those things that works quietly in the background ;p
    – Journeyman Geek
    Aug 26, 2011 at 14:46
  • @CarlF the caveat to that is that you can't use P/Invoke to access any win32 binaries. The moment you need to do that you lose your cross platform support. This is less of an issue than it was as the .Net framework has grown; but if your app needs to interface tightly with any 3rd party systems dependencies are native code become fairly common. Aug 26, 2011 at 17:42

You cannot run binaries on processors which are a different architecture than the architecture the binaries where compiled to.

You cannot run a AMD64 Linux on ARM, just as you cannot run AMD64 linux on an i386 (32-bit) processor. Your only options are to emulate a whole processor (see qemu) and then try your best.

VMware / VirtualBox are not processor emulators, thus you are out of luck there as well.

Not the answer you're looking for? Browse other questions tagged or ask your own question.