[flavio81]

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.

[Nullabillity]

> 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.

[MichaelGG]

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

[problems]

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.

[MichaelGG]

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.

[problems]

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.