Hacker News Reader

Comment by albeva | Hacker News Reader

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.

View on HN

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.

Memory model and byte order is enough to add breakage to stuff written in all of those languages.

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.

Not if you're converting bytes into integers, for instance. E.g. https://msdn.microsoft.com/en-us/library/system.bitconverter... - it's arch specific.

Interesting, similar functions in the Java world are always big endian:

http://docs.oracle.com/javase/6/docs/api/java/math/BigIntege...

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.

> Java applications will not require any recompilations, they will run immediately because they run on a JVM

Except for the native libraries that they depend on.

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.

AFAIK Photoshop uses the GPU via DirectX, so it should work fine

Microsoft has already shown Photoshop running in the emulation and it boots OK. Don't know how much load it will carry but it will run.

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.

> the new operating system will include x86 emulation, giving it the ability to run 32-bit Windows desktop applications unmodified.

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.

https://www.youtube.com/watch?v=A_GlGglbu1U&t=80s

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.

1: https://news.ycombinator.com/item?id=14318406

But isn't Photoshop a prime example of a program you'd want to run in 64bit mode? Mo'ram mo'better?

I think Microsoft had been working on emulation for x86 on ARM.

Reply on news.ycombinator.com