Comment by AaronFriel | Hacker News Reader

Comment by AaronFriel | Hacker News Reader

Parent Full thread

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/...

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

Unfortunately, Google's anticompetitive moves with SafetyNet will ensure that many Android apps will only run on Google-blessed hardware and software platforms.

WSL 1 & 2 are amazingly innovative platforms, as is WINE. Microsoft has undoubtedly created untold value for developers and their shareholders with WSL. The anticompetitive limitations implemented in SafetyNet, however, serve to stifle such innovation, and prevent many Android apps from running on other platforms.

> Microsoft has undoubtedly created untold value for developers and their shareholders with WSL.

If there is a larger purpose around WSL, VS Code, and "MS <3 Linux" messaging, it is definitely this. They have really changed their reputation among developers.

In my opinion, Microsoft is the same Microsoft they were two decades ago. The company is still as efficient as they were back then at destroying what goodwill they have with developers[1].

However, I can't ignore that they've certainly created value for engineers that use Windows to develop software that runs on Linux, similar to the value created by WINE's developers. It's just a shame that similar value and innovation are stifled by the limitations set by Google's SafetyNet when it comes to running Android software on other platforms.

[1] https://news.ycombinator.com/item?id=28779342

VSCode has been a HUGE deal. Being able to use the same editor for all your languages and all your operating systems is just enormous to most developers.

However, the goal wasn't to make "Linux" a first class citizen so much as to bring "non-Windows" developers underneath the mothership.

It's even beginning to affect the embedded world: https://www.nordicsemi.com/News/2021/10/Nordic-launches-nRF-...

VSCode Remote Development is a revolution. I with it open sourced.

It really is a huge amount better than pretty much everything else, yeah.

... now if only the language servers it relies on could be anywhere near as polished :| rust-analyzer is a stunning example of what's possible with language services, gopls is only barely functional enough to be worth running.

Seconded! If for nothing else but to support systems they don't currently provide binaries for :(

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.

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.

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

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.

WSL was born from the previous Android on Windows project, known as Project Astoria.

I agree, WSL2 is the third iteration of Astoria.

Which Android apps is anyone interested in running on a Windows platform?

I use a different set of platforms, but there are a couple of iOS programs I run under MacOS.

In general the experience is worse than using a real macos app but it as terrible than running in Web browser/electron (e.g. Slack, Spotify), or a macOS app that looks like it was written under duress by someone who didn’t give a shit (e.g. WhatsApp)

IReal Pro

Judging by https://www.bluestacks.com, games.

Reply on news.ycombinator.com