Hacker News Reader

Comment by pcapca | Hacker News Reader

My guess is that apps written in java/kotlin are easy to run in a x86 compatible android runtime.

The difficulty is for native code, the arm libraries embedded in many apps. Actually most Android app depends on native libs. For image processing for example. Nearly all games are using native arm binaries.

The sentence you quoted is probably related to native code only, which is the difficult part. It looks like they have some magic tricks to make them work on x86 architecture with having to recompile the libs.

Intel used the same tricks in their x86 android devices a few years ago, you could run arm native code on their x86 android versions transparently.

View on HN

Intel used to call this Houdini. It was also used in Android-x86. Last I looked at the Android-x86 sources, binfmt was used to configure certain types of binaries to be translated on-the-fly by Houdini before running the translated x86.

Houdini.. I hope it doesn't escape its locked sandbox

oh this makes more sense: JVM apps run in Windows with some simple JVM container. Intel Bridge Technology is only needed for the apps that have compiled native code.

Android apps don't ship with JVM bytecode, though; they are compiled to the DEX format[1], which is the format used by the Android Runtime (ART), which is generally why these Android-in-container projects ship the whole bionic-based userland and pipe I/O through a bridge service.

[1] https://source.android.com/devices/tech/dalvik/dex-format

> some simple JVM container

no, there's a new NT subsystem to support this: Windows Subsystem for Android, and as you could guess from the name, it is somewhat related to WSL.

the NT kernel was always designed to accommodate multiple subsystems running at once. Until WSL, there was only ever the Windows subsystem itself. soon there will be a third subsystem one can install.

this is neat, to me.

There was a posix subsystem as well in the early days, however it lacked functionality and was used as a “check that box” for procurement rather then functionality

Also OS/2 (1.x).

Windows is "POSIX compliant" still, whatever that is worth. Are you sure that was a subsystem?

https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem

Hmm, but WSL2 just runs a VM instead, right? Given that I'd have expected WSA to be a container on the WSL VM, running something similar to Anbox.

WSL2 runs in a VM with host OS integration, and I assume this is how the subsystem functionality of the NT kernel is used in WSL2.

WSL1 is the "Linux as a subsystem of Windows" thing I described.

Note that WSL2 is not a complete upgrade from WSL1, and WSL2 does not render WSL1 obsolete. They each have strengths that the other does not.

WSL is very different than NT subsystems (it's based on drawbridge). And NT did support a fourth (or fifth depending on how you want to count it) POSIX subsystem for quite a while, but that's different than WSL.

And interestingly enough, Android support was the original purpose of WSL. It was modified to run an Ubuntu user land on original release for some Microsoft product reason. It's nice to see it coming back in it's original form too.

There was a Linux subsystem for NT around early 2000s in Microsoft Research.

There is amazing depth inside parts of Microsoft. For example, a team built Xbox360-on-PC sometime around 2007-08. That was emulating the PowerPC and GPU on Intel PCs. This didn't ship for various reasons as a product, but it was in the draw when Xbox One came along and they wanted game compatibility between Xbox 360 and XBox One.

WSLv1 was built on Drawbridge that originally came from MSR. I heard a rumor that WSL was spun out from a project using Drawbridge to run Android. Obviously a lot of work went into WSL subsequently, but the pieces to get started were in place.

Reply on news.ycombinator.com