3 ms·
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 o
by 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 agoI 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 agoIt’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.
- mmerlin 5y agoInternet Explorer became Chromium under the hood (MS Edge) Windows might be fully Linux under the hood one day! WSL2 is one of the early bridges across the divide.
- yjftsjthsd-h 5y ago... Windows subsystem for Windows? (Although I guess maybe wow64 was that already)
- plushpuffin 5y agoWhat you described is actually closer to Apple's strategy for moving from Mac OS 9 to Mac OS X, with a virtual machine for running classic apps on the new OS.
- emptyparadise 5y agoMicrosoft-made Linux distribution finally making Linux on the desktop happen, did somebody wish for it on a monkey paw?
- MarkSweep 5y agoMicrosoft announced ARM64EC. It’s an ABI for ARM64 that is similar to x64. They say it allows mixing x64 and ARM64 DLLs in the same process. https://blogs.windows.com/windowsdeveloper/2021/06/28/announcing-arm64ec-building-native-and-interoperable-apps-for-windows-11-on-arm/ https://blogs.windows.com/windowsdeveloper/2021/06/28/announ...
- robocat 5y agoCool - perhaps that opens the way for a x64+ARM big.LITTLE processor, with a few hot fast x64 AMD cores (big) and a lot of slow efficient ARM cores (little).
- fomine3 5y agoI think it's not related. If you need to run ARM code on performance x64 core, ARM to x84 emulator is needed. I believe this is for make applications like DAW (that often uses native plugins, some aren't updated well) port to ARM.