This is lunacy. It will break compatibility with nearly all software out there. From games to productivity apps. Like the stuff I actually use a PC for.
As somebody that used a DEC Alpha running Windows NT and x86 applications thanks to FX!32 code translation back in the late 1990s, I think you're underestimating the usability of the code translation solution demoed by Microsoft et al. Sure, it may be Win32-only (at least for now) but if and when these platforms take off more UWP (sp?) applications will be released to take advantage of native performance. This is likely a very viable solution.
Productivity apps are almost never developed in assembly language. They are developed in some high level language, so for each of such language, assuming the Windows 10 APIs are the same (which they WILL be, no need to change them):
- Java
Java applications will not require any recompilations, they will run immediately because they run on a JVM
- C#/VB/F#
Those applications still will run right away because they run in the .NET CLR virtual machine.
- C++, C
These applications, considering they are already using the Windows APIs, should recompile with few changes.
Games, nowadays, are also developed using frameworks. They mostly depend on the GPU nowadays, and the GPU was never x86 architecture either, so no big change there.
I believe Java and C# enforce specific byte orders to get around this issue, so I doubt you'll see a problem there unless interacting with C++ libraries.
Seems like a rather poor decision on Microsoft's part. Fortunately rather few things interact with data this way anyways, most serialization formats are text based or include endian information.
Lunacy? Nah, the vast majority of software that regular people use is massively I/O bound. For the stuff that isn't (photoshop, e.g.), it will get ported. All of those non-photoshop apps will work just fine under emulation. Chrome and Edge will be ported, they'll work just fine.
I predict that this will have a negligible impact on PC games. They're CPU/memory/GPU bound and will not work well under emulation. They're not likely to get ported. But gamers are not the target market for this product.
In the end it's an hen and egg problem -- you need widespread adoption of the hardware to get software ported, but also widespread porting of the software to get the hardware adopted.
And intel/amd will fight hard. As long as they can instill v fear that maybe the program I'm using, or the one I want to use next week/month/year won't run, people will flog to x86. It doesn't matter so much how real that problem is, it only needs to be perceived as a problem.
Virtually all modern software vendors already write software for multiple platforms and are leaning more on cloud computing, so porting software to a new platform won't be the nightmare it used to be.
Adoption will depend on the killer features, which is currently "LTE" and "uses less power", neither of which PC users care about, so that's why this is doomed to fail.
a) only 32bit
b) At what speed though? x86 emulation isn't trivial, and arm seems to be sufficiently different in architecture to incur a large translation overhead.
Microsoft has had videos out for a while of their x86 emulation. They have a demo of loading Photoshop CC, and it looks close to native speed, though I notice a bit of window refresh. Looks usable, but I'd like to see more demos.
Not only that, but if you are making UWP packages (for the windows store? I'm not sure if they are standalone as well), you can ship both x86 and ARM binaries together. I'm probably butchering the details, but the presentation and accompanying HN discussion was interesting[1]. The video is pretty cool, as they demo real running x86 and ARM binaries on the same system, and explain some seriously cool stuff WRT x86 emulation.