Reviving Astoria – Windows's Lost Android | Hacker News Reader

Reviving Astoria – Windows's Lost Android

trungnt2910.com

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

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.

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.

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

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

What source can you point to that backs up this claim? Also, is this for Windows Server only or for desktop versions also?

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

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.

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

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.

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.

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.

Hyper-V has supported nested virtualization since Server 2016/Win 10. It is also supported to run WSLv2 in a nested VM.

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.

Why would you?

If I have access to AWS, I will be spinning up Linux VMs for GNU/Linux workloads.

AWS has a service providing license-included Visual Studio development VMs for enterprises. These run on EC2 but the users don't have access to AWS services in that sense. These VMs can't run WSL2 because of the lack of nested virtualization. This ends up being fairly painful for Windows-based development; WSL is used for lots of things, integrated with our Windows environment, and WSL1 is much slower.

I guess it is a business decision then, I never been in such situation, it was always rather easy to have a few EC2 GNU/Linux VMs around.

It's not really conducive to use a separate machine for these development use cases; WSL is integrated to the Windows side more tightly than a separate VM is. For instance, you can launch Windows EXEs directly from the Linux side as if they were native, so you can have a single script that runs tools from both sides natively, on the same computer, without remoting or SSH or anything like that. This all works with WSL1 too (which doesn't use virtualization), it's just a lot slower.

> 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

Thank you for this correction. That gives me some hope, then, that maybe we'll get it fixed. I didn't realize this limitation before I bought the device and had to find out when I got the Hyper-V error message :/

iirc they took quite a while to enable it on AMD after Intel, so maybe the wait will be quite significant...

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.

Reply on news.ycombinator.com