3 ms·

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

by kokada 1y ago

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.

ChocolateGod 1y ago
> both Android and Linux are moving targets Existing Linux syscalls rarely change and never in a non-backwards compatible way, extra options are added.
- yjftsjthsd-h 1y ago
  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.
- dwattttt 1y ago
  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.
  - Hilift 1y ago
    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 https://learn.microsoft.com/en-us/windows/wsl/faq

by kokada 1y ago

ChocolateGod 1y ago

> both Android and Linux are moving targets Existing Linux syscalls rarely change and never in a non-backwards compatible way, extra options are added.

yjftsjthsd-h 1y ago
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.
dwattttt 1y ago
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.
- Hilift 1y ago
  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 https://learn.microsoft.com/en-us/windows/wsl/faq