3 ms·
It's supposed to be an API translation layer. So there's no VM, no interpreting of machine code, none of the usual "emulation stuff." Running a Windows binary o
by mikepurvis 7y ago
It's supposed to be an API translation layer. So there's no VM, no interpreting of machine code, none of the usual "emulation stuff." Running a Windows binary on Linux via WINE is your x86 processor directly executing the real x86 machine code, just with a compatibility layer providing equivalents whenever the binary tries to call Windows or DirectX APIs.
WSL1 did the same thing in reverse, though WSL2 abandoned that course and does in fact use virtualization.
- als0 7y agoI find the change in direction particularly interesting. Intuitively, virtualization would have been one of the first and easier suggestions for any system. But they decided to take on the monumental task of implementing a translation layer. It’s probably not their first time either since they did support POSIX in some old versions of Windows. Then they switched to virtualization. I’m guessing it was simply not a sustainable effort? Still a bold move and an interesting part of Windows history.
- my123 7y agoThey had to use the syscall translation path because of the earlier plans. WSL is what could be saved from the Astoria subsystem to run Android apps on Windows 10 Mobile, with the ARM virtualization story being nonexistent at the time for shipping smartphone SoCs.
- mikepurvis 7y agoIf you're interested, the Build talk where WSL2 was introduced is pretty in-depth and does a great job of talking about the motivation. See starting around this point: https://youtu.be/lwhMThePdIo?t=1070 https://youtu.be/lwhMThePdIo?t=1070