Will lxmonika be fully compatible with WSL1?

[kristibektashi]

Since WSL1 is based on the same codebase as Project Astoria, it should be possible to fully support both with lxmonika. A full open-source reimplementation of the WSL1 kernel driver (all versions from 1607-2004) using lxmonika, including all Linux kernel syscalls, would be great news for those who don't want to or can't run WSL2/Hyper-V, since Microsoft has pretty much abandoned WSL1. Also, WSL1 is better to run than WSL2 on some occations, for example storage access is native and network access is done directly through the host instead of using a Hyper-V NAT Adapter.

And once full feature parity with WSL1 is achieved, it could also be expanded futher by implementing extra syscall support, which would mean support for newer Linux distros once they eventually drop support for WSL1, and even potentially support for newer Android versions with Project Astoria on 32-bit Windows versions, assuming the source code for the Android 4.4.4 that is used in Project Astoria is still available (I believe it is available on the Microsoft Open Source Portal).

[trungnt2910]

This is difficult. I personally will not make lxmonika to be a drop-in replacement for WSL1, but rather develop my own userland ecosystem around the core. Some of it is already done through the monika.exe CLI.

lxmonika scope

The goal of lxmonika is to unlock and document the Pico processes feature on all Windows builds that support this. It is a framework allowing other drivers to become Pico providers like WSL/AoW's lxcore.sys, but does not provide any kind of emulation itself.

While there is some WSL syscall modification in lxmonika, it is mostly a sanity check to see whether the Pico callbacks are working correctly and is a fossil of the early commits where lxmonika was purely a proof-of-concept. lxmonika does not intend to modify or enhance WSL1's behavior further.

The latest versions of lxmonika effectively can replace lxss.sys (the loader stub for WSL) on supported Windows systems. This is not an attempt to re-build the WSL stack, but merely exploiting the fact that LXSS is in the whitelist of "core" drivers defined by winload.exe that can register Pico processes.

For older Windows versions, lxmonika can also identify as cng (a completely unrelated driver) to achieve the same functionality.

Why NOT to follow WSL1

WSL1 is not just about the driver (lxcore.sys). It's also about a bunch of other closed-source proprietary userland services. It would require a lot of time and effort to recreate this whole stack, especially the complex COM services and stuff.

The future after lxcore

Microsoft is letting lxcore.sys die, and lxmonika will not attempt to resurrect that zombie.

Instead, when lxmonika matures (including the core driver exporting Pico functionality, and the supporting unified monika.exe host that allows easy installation and uninstallation of lxmonika.sys), I intend to port the whole Linux kernel as a lxmonika provider. The strategy will be similar to how they ported User-mode Linux and Linux Kernel Library.

This effectively allows full syscall compatibility and easy long-term maintenance, keeping up to date with the latest Linux features. As for running Android, with a full Linux kernel working, existing projects like Anbox can be used.