3 ms·

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

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

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