4 ms·

I've noticed a lot of speculation about how they will translate code between X86, X86_64 and ARM. Well, the simple answer is not to translate at all. MS have be

by iuguy 16y ago

I've noticed a lot of speculation about how they will translate code between X86, X86_64 and ARM. Well, the simple answer is not to translate at all. MS have been pushing managed code via things like Silverlight and .NET for some time. My tuppence worth: Windows 8 on ARM won't support legacy x86 code, but will run .NET, Silverlight and any other managed code shamalamadingdong it needs to run. I can see Windows 8 on x86 supporting legacy code, but just as 16-bit support is gone completely in x86_64 Windows now, I'm expecting no support for unmanaged x86 code in the ARM version. Where all this gets interesting is with things like Mono and Moonlight. If MS goes down this route, they could really be exposed as Mono and Moonlight mature.

jallmann 16y ago
> Windows 8 on ARM won't support legacy x86 code, but will run .NET. I can see Windows 8 on x86 supporting legacy code Hmm, I don't believe so. That'd introduce fragmentation that Microsoft's typical users (mom and pop) should not have to deal with. Also that'd be a pretty drastic policy shift for Microsoft seeing the pains they've gone to maintain compatibility with older software. My guess is that, at the very least, Win8 apps running native code will be packaged into a universal binary of some sort. I find that half-hearted though, since it requires recompilation of the original software. wtracy suggested the possibility of JITing x86 to ARM, that's ballsy and it'd be awesome if Microsoft pulls that off.
- iuguy 16y ago
  > wtracy suggested the possibility of JITing x86 to ARM, that's ballsy and it'd be awesome if Microsoft pulls that off. JITing x86 - ARM might not even be fully necessary for most modern apps. It might be possible to do some sort of interception and JIT-style translation for certain parts of code but it might also be possible to provide a DLL level compatibility layer as fallback. That way when DLL functions are called they're called natively, and the main module executes via JIT. I'm not suggesting that would be easy, it'll be balls to the wall hard, but that's the only thing I that immediately springs to mind that wouldn't come with a massive performance penalty. The fragmentation argument is valid and an excellent point to make, however we don't really know who this is being targeted at or the defined primary use cases at this point. If Microsoft can fck up the user experience so badly with Vista and Windows 7 Starter, they can fck up the user experience with ARM and not worry too much. It might also be worth bearing in mind that if a recompile is needed, it's going to be in the next Visual Studio, which will support a lot more managed code features through the CLR than unmanaged code on x86_64 (by which I mean the CLR supports more languages and has fairly tight integration - if you use C++ in Visual Studio you're probably using less of Visual Studio overall than if you're writing ASPX in C#).
bradhe 16y ago
>Windows 8 on ARM won't support legacy x86 code On one hand I doubt this as MS has a penchant for backwards compat and there is an emulation layer for EVERYTHING in Windows as is. On the other hand, I'm seeing them move away from their backwards compat religion and CISC to RISC sounds fucking horrifying to me.
- iuguy 16y ago
  I absolutely agree with you about the penchant, but I know first hand from Microsoft employees that the backwards compatibility issue is a complete pain in the arse. Supporting ARM on managed only paves the way to ditch unmanaged code in x86_64 in the future. Supporting native unmanaged code might require a recompile and some testing, but might be possible (given the Xbox 360) but then you're going to have trouble with x86_64 only references in your code. Implementing some sort of x86 -> ARM is going to be a nightmare of epic proportions, Rosetta-type technologies be damned.

by iuguy 16y ago

jallmann 16y ago

> Windows 8 on ARM won't support legacy x86 code, but will run .NET. I can see Windows 8 on x86 supporting legacy code Hmm, I don't believe so. That'd introduce fragmentation that Microsoft's typical users (mom and pop) should not have to deal with. Also that'd be a pretty drastic policy shift for Microsoft seeing the pains they've gone to maintain compatibility with older software. My guess is that, at the very least, Win8 apps running native code will be packaged into a universal binary of some sort. I find that half-hearted though, since it requires recompilation of the original software. wtracy suggested the possibility of JITing x86 to ARM, that's ballsy and it'd be awesome if Microsoft pulls that off.

iuguy 16y ago
> wtracy suggested the possibility of JITing x86 to ARM, that's ballsy and it'd be awesome if Microsoft pulls that off. JITing x86 - ARM might not even be fully necessary for most modern apps. It might be possible to do some sort of interception and JIT-style translation for certain parts of code but it might also be possible to provide a DLL level compatibility layer as fallback. That way when DLL functions are called they're called natively, and the main module executes via JIT. I'm not suggesting that would be easy, it'll be balls to the wall hard, but that's the only thing I that immediately springs to mind that wouldn't come with a massive performance penalty. The fragmentation argument is valid and an excellent point to make, however we don't really know who this is being targeted at or the defined primary use cases at this point. If Microsoft can fck up the user experience so badly with Vista and Windows 7 Starter, they can fck up the user experience with ARM and not worry too much. It might also be worth bearing in mind that if a recompile is needed, it's going to be in the next Visual Studio, which will support a lot more managed code features through the CLR than unmanaged code on x86_64 (by which I mean the CLR supports more languages and has fairly tight integration - if you use C++ in Visual Studio you're probably using less of Visual Studio overall than if you're writing ASPX in C#).

bradhe 16y ago

>Windows 8 on ARM won't support legacy x86 code On one hand I doubt this as MS has a penchant for backwards compat and there is an emulation layer for EVERYTHING in Windows as is. On the other hand, I'm seeing them move away from their backwards compat religion and CISC to RISC sounds fucking horrifying to me.

iuguy 16y ago
I absolutely agree with you about the penchant, but I know first hand from Microsoft employees that the backwards compatibility issue is a complete pain in the arse. Supporting ARM on managed only paves the way to ditch unmanaged code in x86_64 in the future. Supporting native unmanaged code might require a recompile and some testing, but might be possible (given the Xbox 360) but then you're going to have trouble with x86_64 only references in your code. Implementing some sort of x86 -> ARM is going to be a nightmare of epic proportions, Rosetta-type technologies be damned.