If porting Intel compiled binaries (dll/exe) to ARM is as easy as this article makes it look, then Microsoft has some explaining to do about Windows RT and legacy apps compatibility.
It is not an emulator in VMware/VirtualBox's sense of emulation. However it does implement small subset of Windows APIs, so it is a porting layer.
Apparently winulator just translates the windows api calls to the proper (native) android function, however why wouldn't you just port wine to android then? you'd probably just need to add a few missing posix functions, according to: http://mobilepearls.com/labs/native-android-api/STABLE-APIS....
...or does it??
http://my20percent.wordpress.com/2012/02/27/android-x-server...
http://www.emulator-zone.com/doc.php/n64/ultrahle.html
That was interesting because the typical PC of the time was not exactly speedy.
Microsoft is not willing to tweak every single application to make sure it works on Windows RT, and neither are the developers of most of those programs.
Perhaps the problem is performance - the original StarCraft ran on a 100Mhz CPU with 16MB RAM.
Archivers generally have highly optimized compression/decompression routines, which generally means more esoteric instructions and in some edge cases means abusing properties of the microarchitecture to make things faster.
Media players have the same optimized-code issue that archivers do (via codecs), but on top of that demand very accurate audio/video synchronization and support a wide variety of output formats and hardware, which means that media players often add difficult-to-translate display and audio output pipeline hacks on top of difficult-to-translate optimization.
Starcraft I ran on x86 CPUs without MMX or SSE, and I wouldn't be surprised if it didn't use x87 floating point either although I'm venturing into speculation territory there. Plus, Starcaft I used DirectDraw and what amounts to a framebuffer - the easiest possible output device to emulate.