5 ms·

> If Microsoft could fix their frankly horrid x86 compatibility on aarch64 device I don't think Microsoft is the real problem there, though. NT was developed

> If Microsoft could fix their frankly horrid x86 compatibility on aarch64 device I don't think Microsoft is the real problem there, though. NT was developed to be portable and was working on architectures other than x86 in the beginning. So it was interesting when I heard things about "Windows on ARM" half a decade ago--and then the Surface RT. The RT was crap, but it did have real Windows NT working on non-Intel ARM, as was the OS on their Windows Series 10 phones or whatever. So Microsoft is already there on an OS level. It's the big software vendors that have to be corralled to switch somehow (Autodesk, Adobe, etc.) Honestly .NET overall was probably at least in part Microsoft trying to get developers on something more CPU-agnostic to reduce dependence on x86.

q-big 5y ago
> I don't think Microsoft is the real problem there, though. > [...] > So it was interesting when I heard things about "Windows on ARM" half a decade ago--and then the Surface RT. The RT was crap, but it did have real Windows NT working on non-Intel ARM, as was the OS on their Windows Series 10 phones or whatever. In this specific case, Microsoft is the real problem: Microsoft deeply locked down the Surface RT; you needed a jailbreak to run unsigned applications on it.
atq2119 5y ago
Parent's point was that Apple made the switch without having to get software vendors on the project, due to excellent emulation of x86 on their ARM.
- webmobdev 5y ago
  Apple has more control over developers - these idiots pay them money for the "privilege" of developing on it. And Apple started by deprecating support for all 32 bits app. That forced many developers to refactor or port their code. The x86 emulation support will end in the near future and will force the remaining developers onto the ARM platform.
  - cs2733 5y ago
    Rosetta 1 was supported for 6 years. I don't think that's too bad.
codeflo 5y ago
I'm not so optimistic. There are some technical things Microsoft did poorly when going from x86 to x86-64, which in my opinion delayed the transition of a lot of software by a decade. And this is with processors that can run both instruction sets natively, where no actual software emulation was required. To give some context (this started with Windows Server 2003 64-bit and is still how it works in Windows 11): Instead of implementing fat binaries like OS X did, they decided to run old x86 applications in a virtualized filesystem where they see different files in the same logical path. This results in double the DLL hell nightmare, with lots of confusing issues around which process sees which file where. For many usecases around plugins, this made a gradual transition impossible. (Case in point: The memory hungry Visual Studio is currently still 32-bit. Next release will hopefully finally make the switch.) Also, it’s surprising how much stuff in Windows depends on loading unknown DLLs into your process, like showing the printer dialog. So you run into these problems all the time. Have they learned their lesson? It doesn’t look like it. Last I checked, x86 on ARM uses the exact same system as x86 on x86-64. If they ever emulate x86-64 the same way, that’s triple DLL hell right there. And I don’t think they’ll get a decade to sort things out this time around.
- vanilla_nut 5y ago
  I very nearly want them to double down on this disastrous strategy so in 3-5 years we’ll all be saved from Windows by an MS-run Linux distro (with windows theming, naturally) that just runs Wine+some MS internal goodies for backwards compat. It’s really not that different from Apple’s approach with Rosetta 2 in M1.
  - philistine 5y ago
    It’s crazy that this now aligns with Microsoft’s goals and could conceivably happen. Microsoft has the capacity to realize that the value of Windows is not the codebase, but the compatibility. They could let the Linux subsystem swallow Windows and wrap Windows itself inside it. However, I believe we’ll continue to see their colocation system instead, where Windows and Linux are both wrapped inside a system managing both.
mschuster91 5y ago
> NT was developed to be portable and was working on architectures other than x86 in the beginning. NT itself yes, but the userland? Not in the slightest. Apple provided Rosetta runtime translation at each arch transition, MS did not. As a result, no company even thought about switching PCs over to ARM which meant that there also was no incentive for the big players you mentioned to port their software over to RT.

q-big 5y ago

> I don't think Microsoft is the real problem there, though. > [...] > So it was interesting when I heard things about "Windows on ARM" half a decade ago--and then the Surface RT. The RT was crap, but it did have real Windows NT working on non-Intel ARM, as was the OS on their Windows Series 10 phones or whatever. In this specific case, Microsoft is the real problem: Microsoft deeply locked down the Surface RT; you needed a jailbreak to run unsigned applications on it.

atq2119 5y ago

Parent's point was that Apple made the switch without having to get software vendors on the project, due to excellent emulation of x86 on their ARM.

webmobdev 5y ago
Apple has more control over developers - these idiots pay them money for the "privilege" of developing on it. And Apple started by deprecating support for all 32 bits app. That forced many developers to refactor or port their code. The x86 emulation support will end in the near future and will force the remaining developers onto the ARM platform.
- cs2733 5y ago
  Rosetta 1 was supported for 6 years. I don't think that's too bad.

codeflo 5y ago

I'm not so optimistic. There are some technical things Microsoft did poorly when going from x86 to x86-64, which in my opinion delayed the transition of a lot of software by a decade. And this is with processors that can run both instruction sets natively, where no actual software emulation was required. To give some context (this started with Windows Server 2003 64-bit and is still how it works in Windows 11): Instead of implementing fat binaries like OS X did, they decided to run old x86 applications in a virtualized filesystem where they see different files in the same logical path. This results in double the DLL hell nightmare, with lots of confusing issues around which process sees which file where. For many usecases around plugins, this made a gradual transition impossible. (Case in point: The memory hungry Visual Studio is currently still 32-bit. Next release will hopefully finally make the switch.) Also, it’s surprising how much stuff in Windows depends on loading unknown DLLs into your process, like showing the printer dialog. So you run into these problems all the time. Have they learned their lesson? It doesn’t look like it. Last I checked, x86 on ARM uses the exact same system as x86 on x86-64. If they ever emulate x86-64 the same way, that’s triple DLL hell right there. And I don’t think they’ll get a decade to sort things out this time around.

vanilla_nut 5y ago
I very nearly want them to double down on this disastrous strategy so in 3-5 years we’ll all be saved from Windows by an MS-run Linux distro (with windows theming, naturally) that just runs Wine+some MS internal goodies for backwards compat. It’s really not that different from Apple’s approach with Rosetta 2 in M1.
- philistine 5y ago
  It’s crazy that this now aligns with Microsoft’s goals and could conceivably happen. Microsoft has the capacity to realize that the value of Windows is not the codebase, but the compatibility. They could let the Linux subsystem swallow Windows and wrap Windows itself inside it. However, I believe we’ll continue to see their colocation system instead, where Windows and Linux are both wrapped inside a system managing both.

mschuster91 5y ago

> NT was developed to be portable and was working on architectures other than x86 in the beginning. NT itself yes, but the userland? Not in the slightest. Apple provided Rosetta runtime translation at each arch transition, MS did not. As a result, no company even thought about switching PCs over to ARM which meant that there also was no incentive for the big players you mentioned to port their software over to RT.