> Or are you just tired of your average sluggish, resource-hogging Android emulator?
If it's this one and you're cool with Linux, I recommend https://github.com/waydroid/waydroid , which likewise runs Android on top of a "normal" Linux distro, but with the advantage that it can just use the actual Linux kernel that's already there. There's also https://gitlab.com/android_translation_layer/android_transla... that tries to bridge further up the stack; this is arguably cooler and probably lighter but currently has very limited app compatibility.
This seems to be the same fundamental story as WSL1 versus WSL2 elsewhere. Worse being better, the latter’s clunky VM-based approach won out over the more elegant syscall translation layer of the former.
Windows 11 had a flavor of this - Windows Subsystem for Android and it was neat. I think they hid it behind the Amazon app store but you could side load apk files.
I am not sure if I consider the VM approach necessary worse than a syscall translation, especially considering that both Android and Linux are moving targets. It is different from creating an emulator for a console, that you can assume that the hardware/software will never change (or at least for modern consoles, it will never change for a specific version of game).
Also VMs can be really fast thanks to virtualization instructions and para virtualization techniques.
They don't, but a Linux userland sure does. WSL1 was plagued by a change glibc made around nsleep & realtime clock usage, causing random programs to just fail under WSL1.
At that point, either Linux distros have to consider Windows' "almost" Linux kernel as a target to support, or what Microsoft did, which was to use a VM and a "real" Linux kernel.
Microsoft created a doozy of a bug when OpenSSL changed gmt_unix_time to a random value. They were using that for startup sync of hosts.
Strategically, I don't think WSL is a real product that would be customer facing due to "WSL has been designed and built to use with inner loop development workflows. There are design features in WSL that make it great for this purpose but may make it challenging for production-related scenarios compared to other products."
And there's enough use of long lived distros (RHEL being the extreme case, but also Ubuntu and Debian) that most software supports older Linux versions. In fact, in the case of this particular discussion (Android compatibility), it's quite normal (unfortunately) to have ancient kernels. And also user apps rarely care about the kernel and just use the Android APIs that sit on top of it, so I'm skeptical that AoW would actually need to worry about rapidly changing its kernel emulation.
I, a once proud Gentoo GNU/Windows user myself for a bit back in the Win7/2008R2 era, too was disappointed when they strangled SUA to death and took the easy way out with VMs. Would have been way cooler to keep the POSIX subsystem and have a versatile kernel. Microsoft could have pivoted towards the FOSS ecosystem with a hybrid Win32/POSIX environment.
I have a lot of admiration for the WSL1-style approaches & hope they bear fruit. The major problem with WSL2 & Android VMs is that they're a pain in an already virtualised environment - there's then a need for nested virtualisation.
This is absolutely irrelevant to the above comment because there is no nested virtualization involved: the "high-privilege" VM will spawn other VMs as siblings of itself (in the root Hyper-V instance), not as nested VMs.
Even before the virtualization-based security feature was introduced this has been the Hyper-V architecture, on server and client SKUs. The management OS is referred to as the "parent partition" or "root partition," and it runs on top of the hypervisor: https://learn.microsoft.com/en-us/virtualization/hyper-v-on-...
It's various pieces are called Virtualization Based Security/Core Isolation/Hypervisor-Protected Code Integrity
> Virtualization-based security, or VBS, uses hardware virtualization and the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised.
> While VBS greatly improves platform security, VBS also changes the trust boundaries in a Windows PC. With VBS, the Windows hypervisor controls many aspects of the underlying hardware that provide the basis for the VBS secure environment. The hypervisor must assume the Windows kernel could become compromised by malicious code, and so must protect key system resources from being manipulated from code running in kernel mode in a manner that could compromise security assets.
As far as I know, this doesn't limit CPUs to 8th Gen and newer. Neither does VT-x and the other requirements.
Furthermore, there are supported ways of disabling VBS entirely so the gimped version of Windows 11 that doesn't use VBS you'd get for installing it on older hardware wouldn't be that different from an install you'd disable VBS on to get 15% better performance in video games.
Yes if you enable Hyper-V the main Windows installation is running under a hypervisor, but it's running with nearly complete access to the physical hardware.
It's not a problem for Windows, it's a problem for AWS: only metal instances support nested virtualization. To this very day you can't use WSL2 on most EC2 instances.
It's also a problem for Microsoft's new ARM64-based Surface devices: Snapdragon X doesn't support nested virtualization, even though Windows does.
I was sent a test device with Astoria by Microsoft, and I an still flabbergasted they abandoned it. It worked really well, Android apps did feel like the most sluggish apps on the platform... but only because they ran like Android apps.
Just one more stepping stone on Microsoft's constant inability to make good decisions.
Fundamentally though, the biggest issue probably was Microsoft was still far too afraid to fight Google directly, their monopoly was at its height but user perception of that hadn't caught up yet.
Enough high-potential Microsoft products died on the vine that it’ll take a serious and lasting change in corporate processes before I ever go back. I loved the thought that went into the Surface Book, but it was killed off for some half-assed alternative. The Surface Neo was a really cool idea that rotted away after being announced. So many software ideas went away before they even had a change (Subsystem for Android being the most recent one I can recall).
I have regularly described Microsoft as the most self-defeating company in history. From a product and engineering standpoint, their products are top class, but their leadership decisions remain baffling and damaging to their own brand.
> Or are you just tired of your average sluggish, resource-hogging Android emulator?
If it's this one and you're cool with Linux, I recommend https://github.com/waydroid/waydroid , which likewise runs Android on top of a "normal" Linux distro, but with the advantage that it can just use the actual Linux kernel that's already there. There's also https://gitlab.com/android_translation_layer/android_transla... that tries to bridge further up the stack; this is arguably cooler and probably lighter but currently has very limited app compatibility.
This seems to be the same fundamental story as WSL1 versus WSL2 elsewhere. Worse being better, the latter’s clunky VM-based approach won out over the more elegant syscall translation layer of the former.
Windows 11 had a flavor of this - Windows Subsystem for Android and it was neat. I think they hid it behind the Amazon app store but you could side load apk files.
I am not sure if I consider the VM approach necessary worse than a syscall translation, especially considering that both Android and Linux are moving targets. It is different from creating an emulator for a console, that you can assume that the hardware/software will never change (or at least for modern consoles, it will never change for a specific version of game).
Also VMs can be really fast thanks to virtualization instructions and para virtualization techniques.
> both Android and Linux are moving targets
Existing Linux syscalls rarely change and never in a non-backwards compatible way, extra options are added.
They don't, but a Linux userland sure does. WSL1 was plagued by a change glibc made around nsleep & realtime clock usage, causing random programs to just fail under WSL1.
At that point, either Linux distros have to consider Windows' "almost" Linux kernel as a target to support, or what Microsoft did, which was to use a VM and a "real" Linux kernel.
Microsoft created a doozy of a bug when OpenSSL changed gmt_unix_time to a random value. They were using that for startup sync of hosts.
Strategically, I don't think WSL is a real product that would be customer facing due to "WSL has been designed and built to use with inner loop development workflows. There are design features in WSL that make it great for this purpose but may make it challenging for production-related scenarios compared to other products."
https://learn.microsoft.com/en-us/windows/wsl/faq
And there's enough use of long lived distros (RHEL being the extreme case, but also Ubuntu and Debian) that most software supports older Linux versions. In fact, in the case of this particular discussion (Android compatibility), it's quite normal (unfortunately) to have ancient kernels. And also user apps rarely care about the kernel and just use the Android APIs that sit on top of it, so I'm skeptical that AoW would actually need to worry about rapidly changing its kernel emulation.
I, a once proud Gentoo GNU/Windows user myself for a bit back in the Win7/2008R2 era, too was disappointed when they strangled SUA to death and took the easy way out with VMs. Would have been way cooler to keep the POSIX subsystem and have a versatile kernel. Microsoft could have pivoted towards the FOSS ecosystem with a hybrid Win32/POSIX environment.
I have a lot of admiration for the WSL1-style approaches & hope they bear fruit. The major problem with WSL2 & Android VMs is that they're a pain in an already virtualised environment - there's then a need for nested virtualisation.
On a recent computer with a recent Windows installation what you think is bare-metal Windows is actually a (high-privilege) VM running under Hyper-V.
This is absolutely irrelevant to the above comment because there is no nested virtualization involved: the "high-privilege" VM will spawn other VMs as siblings of itself (in the root Hyper-V instance), not as nested VMs.
The parent partition is not considered a VM, nor does the implementation of VBS make the "parent partition" (with just VBS, it isn't) a VM.
https://learn.microsoft.com/en-us/virtualization/hyper-v-on-...
The parent partition has full access to hardware and child partitions (VMs). The hardware is not virtualized to the parent.
What source can you point to that backs up this claim? Also, is this for Windows Server only or for desktop versions also?
Even before the virtualization-based security feature was introduced this has been the Hyper-V architecture, on server and client SKUs. The management OS is referred to as the "parent partition" or "root partition," and it runs on top of the hypervisor: https://learn.microsoft.com/en-us/virtualization/hyper-v-on-...
It's various pieces are called Virtualization Based Security/Core Isolation/Hypervisor-Protected Code Integrity
> Virtualization-based security, or VBS, uses hardware virtualization and the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised.
> While VBS greatly improves platform security, VBS also changes the trust boundaries in a Windows PC. With VBS, the Windows hypervisor controls many aspects of the underlying hardware that provide the basis for the VBS secure environment. The hypervisor must assume the Windows kernel could become compromised by malicious code, and so must protect key system resources from being manipulated from code running in kernel mode in a manner that could compromise security assets.
https://learn.microsoft.com/en-us/windows-hardware/design/de...
https://learn.microsoft.com/en-us/windows-hardware/design/de...
Architecture Image: https://www.microsoft.com/en-us/security/blog/wp-content/upl...
To add more to the context, VBS is also why Windows 11 requires 8th Gen CPUs or newer, because only those have added working hardware VBS.
The link about VBS above says it requires
> Intel VT-X2 with Extended Page Tables (EPT)
As far as I know, this doesn't limit CPUs to 8th Gen and newer. Neither does VT-x and the other requirements.
Furthermore, there are supported ways of disabling VBS entirely so the gimped version of Windows 11 that doesn't use VBS you'd get for installing it on older hardware wouldn't be that different from an install you'd disable VBS on to get 15% better performance in video games.
Yes if you enable Hyper-V the main Windows installation is running under a hypervisor, but it's running with nearly complete access to the physical hardware.
Is nested virtualisation still a problem on Windows? Intel and AMD have supported it for so long I don't think I still own hardware that lacks it.
It's a pain when renting a VPS sometimes, but on Windows I don't think that's a common problem.
It's not a problem for Windows, it's a problem for AWS: only metal instances support nested virtualization. To this very day you can't use WSL2 on most EC2 instances.
It's also a problem for Microsoft's new ARM64-based Surface devices: Snapdragon X doesn't support nested virtualization, even though Windows does.
> It's also a problem for Microsoft's new ARM64-based Surface devices: Snapdragon X doesn't support nested virtualization, even though Windows does.
Snapdragon X does support nested virtualisation - it's Windows that doesn't support it on arm64 yet
Why would you?
If I have access to AWS, I will be spinning up Linux VMs for GNU/Linux workloads.
Hyper-V has supported nested virtualization since Server 2016/Win 10. It is also supported to run WSLv2 in a nested VM.
I was sent a test device with Astoria by Microsoft, and I an still flabbergasted they abandoned it. It worked really well, Android apps did feel like the most sluggish apps on the platform... but only because they ran like Android apps.
Just one more stepping stone on Microsoft's constant inability to make good decisions.
Fundamentally though, the biggest issue probably was Microsoft was still far too afraid to fight Google directly, their monopoly was at its height but user perception of that hadn't caught up yet.
Enough high-potential Microsoft products died on the vine that it’ll take a serious and lasting change in corporate processes before I ever go back. I loved the thought that went into the Surface Book, but it was killed off for some half-assed alternative. The Surface Neo was a really cool idea that rotted away after being announced. So many software ideas went away before they even had a change (Subsystem for Android being the most recent one I can recall).
I have regularly described Microsoft as the most self-defeating company in history. From a product and engineering standpoint, their products are top class, but their leadership decisions remain baffling and damaging to their own brand.
This feels like how someone explained IBM to me around 20 years ago.