Arkose: Virtualisation largely relies on the underlying architecture being the same, e.g. an x86 guest OS running on an x86 host OS, which is how it can achieve such impressive performance. Emulating the CPU itself is much more demanding (just look at DOSBox), especially since ARM lacks the raw power of x86.
DOSBox is actually my primary example of success with virtualization. As for ARM power, it's catching up.
Arkose: HAL is for the OS itself; it does not translate running software which often relies on the underlying architecture (with some exceptions like .NET applications). While Microsoft could potentially implement some sort of compatibility layer themselves they have so far maintained that x86 software will need to be recompiled in order to run on ARM versions of Windows 8.
Running software is not architecture dependent. It's container dependent. The container is traditionally the OS. Modern alternatives include the Java and .Net virtual machines/environments.
When I am writing (non-driver level) windows code (I am a programmer) the only "architecture" related concern I have is how long a pointer is. (Well and if the system has enough memory for the data structure and caching scheme, if the CPU is fast/wide enough for the level of threading, how reliable/wide/latent the network connection is ...) These days that's 32 or 64 bits.
Take Microsoft's previous support of
and [url=http://en.wikipedia.org/wiki/Itanium#Software_support]Itanium. There was not a separate version of win16/32/64 for these processors. Nor did code need to be recompiled for these different processors.
These differences even exist between x86 chips from the same manufacture. I remember having to do a HAL swap on a lab full of machines after they got imaged from a machine using a different HAL. Both the source and the destination were Intel x86 machines, there was still enough of a difference between the processors that a different HAL was needed for Windows to start up.
