Windows Subsystem For Linux 4 (WSL4)

Windows Subsystem For Linux 4 is a project that aims to port the Linux kernel (inclusive drivers, like DRBD, device mapper or selected file systems) from the original Linux kernel sources to the Windows NT kernel. It should be possible to run Linux user space applications along with usual Windows programs. Furthermore, it should be possible for any Windows program to take advantage of compiled-in drivers. For example, Windows explorer would show files on a ext4 filesystem.

Current state (March 2026)

As of March 2026 the Linux kernel can be built as a native Windows driver with a separate (virtual) architecture. So

make ARCH=windows

does something useful. Some drivers are linked into it (device mapper, DRBD, some parts of the networking stack), but the rest is mostly allnoconfig. Also only 32-bit systems for now (64-bit needs to be patched: unsigned long -> ULONG_PTR, since sizeof(unsigned long) is 4 bytes while sizeof(void*) is 8 bytes (Linux expects them to be the same size)).

The kernel already loads as a native Windows driver and boots until where it would exec init. This means that primitives like spinlocks, threads, memory allocation, scheduling, … already work.

The next step would have been to get device mapper working which would allow people to run lvm natively on a Windows host.

While doing so I discovered that it is non-trivial to port the lvm tools (the userland part of lvm) to ReactOS/Windows (one would have to do port the Posix API stuff to Win32 API, which isn’t fun at all to do), so I decided that it is a good point in time to get running Linux userland programs working (with a proper system call interface and a working exec() system call, plus some helpers to get the console output from Linux).

History

This project originated in WinDRBD which is a port of the LINBIT DRBD driver from Linux to Windows.

In June 2025 the 1.2.0 release of WinDRBD was released. Unilike WinDRBD 1.1 and before this release is compiled with the GNU toolchain (gcc, …) instead of the Microsoft Visual C compiler. This allows for tieing the code more closely to the Linux kernel since no patches are required (the Linux kernel uses a lot of extensions to the C language not supported by MS VC).

Next steps

Currently I am working on making it possible to run userland programs with the Linux kernel.

The next step after that would be to make device mapper work so people can use logical volume management (lvm) on Windows. Also we are currently exploring a file system cross kernel interface which then would allow people to use Linux file systems on Windows natively.

Disclaimer: What it is NOT

This is not Windows Subsystem for Linux 2 (WSL2). Instead it is a Linux kernel running as a Winodws driver (without a virtual machine inbetween).

That means that software running on the Windows host (not just software in the virtual machine as with WSL2) can benefit from features of a driver built with this framework. For example, a database running on Windows can be made highly available with WinDRBD, the Linux DRBD driver for Windows.

It is also not a way to automatically compile all linux drivers for Windows such that Windows programs can use the driver via Windows API calls.

Instead the linux drivers communicate with the Windows Kernel via so called cross kernel interfaces. There are interfaces for example for block devices (in both directions) and networking (linux calls Windows only). Others like interrupt handlers (windows calls linux) for example are currently missing.

What happened to WSL3?

Nothing. It never existed. I count in power of two, so the next WSL after WSL4 would be WSL8 :)