6 ms·

Are they really, is there anything to back up the claim WSL2 is a huge team internally? Because the way I see it WSL1 was much more novel and likely required a

Are they really, is there anything to back up the claim WSL2 is a huge team internally? Because the way I see it WSL1 was much more novel and likely required a dedicated team to manage the kernel API to windows API shim layer, but now with WSL2 it's just a gussied up hyper V integration.

sz4kerto 5y ago
Probably not a huge team, but I guess the number of people involved has easily 3 digits, as MS needs to pay the developers, marketing people, manage the releases through Windows Updates, collect feedback, check compatibility etc. At the scale of MS a "major" Windows feature can't be cheap, even if it looks simple. Seriously, look at how difficult it is for them to port the old style control center or improve notepad.exe.
- spoonjim 5y ago
  You’re right that at MS scale teams are bigger, but also dollars are even proportionally much easier to come by.
AaronFriel 5y ago
My hunch is that the monumental amount of work to make virtualized GPU support and zero-copy hardware accelerated graphics work from WSL2 to the desktop (a technology called "VAIL", which hasn't shipped yet) is in order to support Android apps on Windows, and that's always been the goal of this team and a series of high profile projects. WSL2 is actually the third iteration of this technology, not the second, and I believe has the same original goal and they've dedicated a large amount of engineering effort to that goal. Here's my case: Windows 10 Mobile had "Project Astoria", which involved working with app developers to port apps to Windows Phone. This involved library support and translation layers to enable APKs to run on Windows. WSL1 abandoned the approach of requiring developers to modify apps, and used "pico processes" with kernel driver and Windows kernel's support for alternative subsystems to Win32 to map Linux syscalls to Windows equivalents. This enabled binary compatibility for most apps, but fell short. WSL2 switched to the lightweight Hyper-V integration (now using the host compute system APIs to manage lightweight containers/VMs) but added deep driver integration with graphics to enable machine learning and hardware accelerated graphic workloads to work within Linux using vGPU drivers and RAIL respectively. And soon VAIL, to enable full fidelity graphical applications (i.e.: Android apps) to run on Windows without compromise. That's a lot of engineering time on 3 high complexity projects over a span of at least 6 years, publicly. Link to a talk on X11/Wayland and VAIL: https://xdc2020.x.org/event/9/contributions/611/attachments/702/1298/XDC2020_-_X11_and_Wayland_applications_in_WSL.pdf https://xdc2020.x.org/event/9/contributions/611/attachments/...
- easton 5y ago
  VAIL and WSLg are available now in stable builds of Windows 11. I think VAIL was originally designed to be able to connect to containers that ran Win32 apps so that they looked natural, but since containerizing Win32 apps and their 30 years of legacy cruft was considered too good of an idea to finish, it was repurposed for this.
  - AaronFriel 5y ago
    I think I disagree on both points. VAIL is not available yet, that I have seen, and I don't believe it was intended originally for Win32 apps. I don't think VAIL has shipped yet, and getting that working correctly and securely, as it involves sharing memory between the WSL2 VM with a Linux kernel and the host Windows kernel, seems to me the most likely blocking issue for why they haven't yet released Android app support on Windows. See this comment on the readme of the WSLg repo: > Please note that for the first release of WSLg, vGPU interops with the Weston compositor through system memory. If running on a discrete GPU, this effectively means that the rendered data is copied from VRAM to system memory before being presented to the compositor within WSLg, and uploaded onto the GPU again on the Windows side. As for originally being intended for Win32 apps, I do wonder if "Vail" and "VAIL" are different projects within the OS division. The Linux/X11/Wayland and vGPU interop part of VAIL requires different expertise and deep knowledge of the Linux graphical stack.
    - easton 5y ago
      I mean, I’m using it on stable Windows 11. The README says it shipped in build 21xxx which is 1000 builds behind Windows 11’s number. I can check though. And for the other parts, the interop bits are new, but the deck from when the WSL2 devs presented this specifically said it was a great solution because it was already being used for Azure Virtual Desktop (hosted Windows VMs).
      - AaronFriel 5y ago
        Are you using VAIL or just RAIL? The difference is not whether GPU applications do or do not work. They work with both. The difference is, do they work with zero copying via shared memory between the Windows host and the WSL virtual machine? RAIL enabled graphical applications - including those that use the GPU - to be presented as windows on the Windows desktop. But it involves extra latency on the order of several to tens of frames, depending on how expensive the framebuffer copying and synchronization steps are. VAIL enables performance (and input lag) that is on par with running Linux natively.
easygenes 5y ago
Not only that, but it severely underperforms vs e.g. the VMware Hypervisor, even on the latest Windows. (Good luck disabling Hyper-V so that you can even run a different hypervisor on Windows these days, btw)

sz4kerto 5y ago

Probably not a huge team, but I guess the number of people involved has easily 3 digits, as MS needs to pay the developers, marketing people, manage the releases through Windows Updates, collect feedback, check compatibility etc. At the scale of MS a "major" Windows feature can't be cheap, even if it looks simple. Seriously, look at how difficult it is for them to port the old style control center or improve notepad.exe.

spoonjim 5y ago
You’re right that at MS scale teams are bigger, but also dollars are even proportionally much easier to come by.

AaronFriel 5y ago

My hunch is that the monumental amount of work to make virtualized GPU support and zero-copy hardware accelerated graphics work from WSL2 to the desktop (a technology called "VAIL", which hasn't shipped yet) is in order to support Android apps on Windows, and that's always been the goal of this team and a series of high profile projects. WSL2 is actually the third iteration of this technology, not the second, and I believe has the same original goal and they've dedicated a large amount of engineering effort to that goal. Here's my case: Windows 10 Mobile had "Project Astoria", which involved working with app developers to port apps to Windows Phone. This involved library support and translation layers to enable APKs to run on Windows. WSL1 abandoned the approach of requiring developers to modify apps, and used "pico processes" with kernel driver and Windows kernel's support for alternative subsystems to Win32 to map Linux syscalls to Windows equivalents. This enabled binary compatibility for most apps, but fell short. WSL2 switched to the lightweight Hyper-V integration (now using the host compute system APIs to manage lightweight containers/VMs) but added deep driver integration with graphics to enable machine learning and hardware accelerated graphic workloads to work within Linux using vGPU drivers and RAIL respectively. And soon VAIL, to enable full fidelity graphical applications (i.e.: Android apps) to run on Windows without compromise. That's a lot of engineering time on 3 high complexity projects over a span of at least 6 years, publicly. Link to a talk on X11/Wayland and VAIL: https://xdc2020.x.org/event/9/contributions/611/attachments/702/1298/XDC2020_-_X11_and_Wayland_applications_in_WSL.pdf https://xdc2020.x.org/event/9/contributions/611/attachments/...

easton 5y ago
VAIL and WSLg are available now in stable builds of Windows 11. I think VAIL was originally designed to be able to connect to containers that ran Win32 apps so that they looked natural, but since containerizing Win32 apps and their 30 years of legacy cruft was considered too good of an idea to finish, it was repurposed for this.
- AaronFriel 5y ago
  I think I disagree on both points. VAIL is not available yet, that I have seen, and I don't believe it was intended originally for Win32 apps. I don't think VAIL has shipped yet, and getting that working correctly and securely, as it involves sharing memory between the WSL2 VM with a Linux kernel and the host Windows kernel, seems to me the most likely blocking issue for why they haven't yet released Android app support on Windows. See this comment on the readme of the WSLg repo: > Please note that for the first release of WSLg, vGPU interops with the Weston compositor through system memory. If running on a discrete GPU, this effectively means that the rendered data is copied from VRAM to system memory before being presented to the compositor within WSLg, and uploaded onto the GPU again on the Windows side. As for originally being intended for Win32 apps, I do wonder if "Vail" and "VAIL" are different projects within the OS division. The Linux/X11/Wayland and vGPU interop part of VAIL requires different expertise and deep knowledge of the Linux graphical stack.
  - easton 5y ago
    I mean, I’m using it on stable Windows 11. The README says it shipped in build 21xxx which is 1000 builds behind Windows 11’s number. I can check though. And for the other parts, the interop bits are new, but the deck from when the WSL2 devs presented this specifically said it was a great solution because it was already being used for Azure Virtual Desktop (hosted Windows VMs).
    - AaronFriel 5y ago
      Are you using VAIL or just RAIL? The difference is not whether GPU applications do or do not work. They work with both. The difference is, do they work with zero copying via shared memory between the Windows host and the WSL virtual machine? RAIL enabled graphical applications - including those that use the GPU - to be presented as windows on the Windows desktop. But it involves extra latency on the order of several to tens of frames, depending on how expensive the framebuffer copying and synchronization steps are. VAIL enables performance (and input lag) that is on par with running Linux natively.

easygenes 5y ago

Not only that, but it severely underperforms vs e.g. the VMware Hypervisor, even on the latest Windows. (Good luck disabling Hyper-V so that you can even run a different hypervisor on Windows these days, btw)