State of WSL1

[billziss-gh]

Your blog posts here and here shed some light on your new direction with WSL2. However there are some questions about the state of WSL1 that I am hoping to get addressed.

• Is there new development being done on WSL1 or is it now in maintenance mode?
• Do you intend to sunset WSL1 in the future?

I personally find WSL1 a fantastic effort that was pushing the boundaries of OS research. In comparison WSL2 feels like a copout. In your blog posts you suggest that file system performance was an issue and I have seen the same in some GitHub comments. Your blog posts do not specify if the performance improvements in WSL2 are related to what you call VolFs or DrvFs. I expect that WSL2 VolFs performance is better, but I believe that you could have improved VolFs performance in WSL1 by running it as a file system on top of a raw disk partition or a VHD rather than emulate it via NTFS. I expect that WSL2 DrvFs performance is comparable to the WSL1 one, because in both cases you have to go through the Windows file system stack and NTFS.

A well-defined future for WSL is important if you wish for platform developers to engage your product seriously. Recently I became interested and started researching the internals of WSL1 for a dual purpose: (1) to add support for WSL1 to my project WinFsp, and (2) to create a development kit for WSL1 that would let third parties write drivers for WSL1. My ultimate goal was to (possibly and eventually) develop a FUSE driver for WSL1. Obviously your announcement takes the wind out of these sails.

---

I am also hoping that you open up PsRegisterPicoProvider to allow third parties to write their own "library" OS'es. Consider this my "formal" request :)

[therealkenc]

You want reddit.

[RokeJulianLockhart]

@therealkenc, why?

[billziss-gh]

@therealkenc what I want is an honest response from the WSL developers, so I can decide whether it is worth to continue investing on their platform.

The constant change of platform/API direction is IMO what contributed to MSFT's developer mindshare decline in the mid-00's. I was an MSFT employee at the time.

[therealkenc]

The honest response is:

Please use the following bug reporting template to help produce issues which are actionable and reproducible, including all command-line steps necessary to induce the failure condition. Please fill out all the fields! Issues with missing or incomplete issue templates will be closed.

The good sport response is discussion threads are left open for a while until they have run their course, in the off chance some actionable comes of it. n.b. I have never seen anyone at MSFT participate in a discussion thread on this github for the last two years (or maybe three, there were a couple of discussion-ish replies in the early days). Because, see, not a discussion forum.

[RokeJulianLockhart]

@therealkenc, GitHub Discussions are solely for discussions, and are a forum. That's why they're separate to issues. Have you read GitHub's documentation?

[billziss-gh]

@therealkenc understood and thanks for your understanding.

My hope is that even if nobody from MSFT decides to respond, the relevant people might still take notice and decide to eventually clarify the WSL1 status through some form of public announcement.

[thorsteneb]

Take a look at https://mybuild.techcommunity.microsoft.com/sessions/77003 from about 18:00, the discussion of file system differences with regards to open file descriptors.

I get where @benhillis comes from when he says "we can't change this, we'd risk breaking existing Windows applications". As per discussion by @therealkenc in #3451, and a whole host of related issues around how Linux and NT kernel handle file systems, some of these issues may not be fixable in WSL 1 without running into the app compatibility issues in Windows. The behavior is so fundamentally different that files inside WSL that live on a Windows file system cannot behave the way Linux expects them to, in every respect.

Edit: Should have watched more of that video - Plan 9 and ext4 is the way WSL2 handles access to Linux files from Windows, and if WSL 1 has to have a chance to fix some of these fundamental differences, it might also need an ext4 - just without the benefit of a Linux kernel to drive that.

Whether that kind of heavy lift is warranted for WSL 1 is a good question.

[viniciusvillas]

The session link is dead. Do you happen to know where I can find it in 2023? Thanks!

[yorickdowne]

The build website has an archive for 2021 and 2022 sessions.

YouTube still has the 2019 sessions. I think it was this one: https://youtu.be/lwhMThePdIo?feature=shared

[billziss-gh]

The central arguments of WSL2 vs WSL1 appear to be that:

1. Full system call compatibility is hard to achieve.
2. File system performance is subpar in WSL1.

Regarding 1. Yes, I agree: full system call compatibility is hard to achieve. This is exactly what makes WSL1 an interesting and non-trivial project. But Linux is a finite kernel and they would eventually catch up. This is assuming that the internal funding was there, which is perhaps the real reason behind these changes here.

Regarding 2. Which file system performance? That of their root file system ("VolFs") or that of accessing Windows drives ("DrvFs")? They have not been explicit on this.

I find it likely that DrvFs (i.e /mnt/x where x: is a Windows drive) performance is comparable in WSL2 and WSL1. This is because WSL2 still has to go through the Windows file system stack and NTFS for /mnt/x file systems. (I cannot see a way around this and would love to be shown otherwise.) Also all the problems they mention in their talk about the differences between the Windows and Linux file systems will still be there.

So the performance improvements must be primarily with the root file system (VolFs in WSL1). My contention is that they could have achieved those performance improvements by writing a WSL1 disk file system on top of a raw disk partition or VHD together with a POSIX file system cache. I understand that is a non-trivial undertaking, but again this is what made WSL1 an interesting project and worth attention IMO.

Perhaps Microsoft might consider this: Do not sunset WSL1. Open source it. I find it very likely that the community will continue to build it for you.

[leonelsr]

I believe I've read almost the entire thread (except for 20-something hidden messages in the middle). And for me, THIS is the definitive comment, along with that one and the others that bring initiatives such as CoLinux into the discussion.

WSL 2 feels like a joke when compared to the latest state of WSL 1 which is a (simply brilliant) actual subsystem or translation layer that brings Linux into Windows. WSL 2 differs too little from what all of us used to do before the advent of any WSL: run some headless VM on a hypervisor of choice (Hyper-V, VMWare, VirtualBox or whatever) and access it via SSH and/or some other interfaces (Xming/VcXsrv, NFS, Samba, some Host->Guest USB device sharing feature and a virtual network stack with or without NAT).

I really hope Microsoft doesn't sunset WSL 1. I ask, I urge them not to.

[Lukasz032]

This aged well.

[trungnt2910]

Not really, see #12922.
The most important component, the soul of WSL1, is still closed source.
The document you linked to includes a diagram that is very WSL2-oriented.

[therealkenc]

I find it very likely that the community will continue to build it for you.

In the mean time, the community of NT kernel developers could work on making winfsp or dokany or zfs or ext23fsd or winpcap better. It is unfortunate that after 684 Windows NT kernel devs became available to work for free, those projects (and many others) didn't get more help. [A few hundred devs banging on colinux would go a long way too if you got vm skillz.]

I get where benhillis comes from when he says "we can't change this, we'd risk breaking existing Windows applications"

Been meaning ask over in #1529 about that part of the video.

[billziss-gh]

It is unfortunate that after 684

Just voted for this!

Raees Iqbal wrote on UserVoice:

Windows Subsystem for Linux is a very awesome project. But I don't think Microsoft is going to allocate enough resources to this to meet the demands of the community. So, why not open-source it?

Can Raees Iqbal see into the future? :)

[therealkenc]

Just voted for this!

It's locked and can't be voted on AFAICT (count still 684). You probably voted on it in 2016. n.b. re-opening it wouldn't actually change the number of NT kernel developers (such as yourself! ❤️ 💯) contributing to OSS projects, so it is pretty understandable why it was locked.

[billziss-gh]

It's locked and can't be voted on AFAICT

I thought the behavior was somewhat weird. Once I clicked on the "Vote" button, it recognized the email address I supplied, but the vote count didn't change. I ascribed this to an aging/faulty brain and sensors attached to it, but turns out the signal was correct ("the vote count did not change") and the interpretation was wrong ("the vote count did change, you just missed it" :)

[oiaohm]

I would personally say kill WSL1 completely. WSL 2 they are build a Linux kernel.

http://www.colinux.org/
Colinux here totally demonstrates that you can run a Linux kernel on Windows without a hypervisor. Of course you need some windows drivers. This could possible be just 1 linux kernel for the hypervisor and non hypervisor usage case.

Full system call compatibility is hard to achieve.
The reality from the start this was impossible to legally achieve closed source even if you could catch up. The linux uses a lot of patented technologies that are only licensed to be used under GPLv2 behaviours of these technologies do show though to applications at times.

Multi groups have attempted Linux syscall emulation. Reality is you want Linux syscall compatibility that is in fact correct you have to really bite the bullet and use a Linux kernel.

[thorsteneb]

I would personally say kill WSL1 completely.

The earliest that could possibly happen is Jan 9th 2029. No sense fretting about it now.

Edit: I just realized I may haven taken your comment too literally. If by "kill off completely" you mean "remove the ability to run WSL 1 in some future version of Windows", not "stop supporting it entirely" then yeah, that could happen much earlier, subject to how well WSL 2 meets enterprise needs and what the uptake of each version is over the next 2-3 years.

The amount of resources WSL 1 will receive will be "based on user feedback" as per the presentations we have seen. Ability to run Virtualbox and VMWare Workstation has already been highlighted as important to enterprises. I can see a future where the Hyper-V hypervisor learns to "play nice" with other virtualization tech, and that in turn makes WSL 2 more compelling. Networking has been highlighted as another area that's being looked at.

I expect WSL 1 will receive diminishing resources, but not be "killed outright", as long as those big bugbear issues with WSL 2 can be handled, and enterprises adopt WSL 2.

And where we are in 2029, well, I wouldn't hazard a guess. Three years ago I didn't think a Linux kernel in Windows would be a thing, never mind any thoughts I might have had ten years ago.

[therealkenc]

I can see a future where the Hyper-V hypervisor learns to "play nice" with other virtualization tech

There's been improvements as of the April 2018 update. I managed to get a nested hyper-v and qemu guest to play nice side-by-side inside Win10 guest/host inside a Linux kvm host. I haven't tested VBox or VMWare, but if they don't work already I am sure they will post haste. I had been (mildly) concerned about the scenario but turns out that's oldthink.

[billziss-gh]

@therealkenc wrote:

I get where benhillis comes from when he says "we can't change this, we'd risk breaking existing Windows applications"

Been meaning ask over in #1529 about that part of the video.

I finally had the chance to review this issue.

This is of course an artifact of VolFs being based on NTFS. However I believe VolFs could perhaps have worked around this if instead of using HANDLE's to access files they were using FILE_OBJECT pointers directly. (Please note that I have not thought through this completely, but this is how I would likely approach the problem if I had to solve it in-kernel.)

The relevant code in FastFat appears to be this one: link. Oplocks make this code increasingly hard to read, but the crux is that if you have an open handle on a file under a directory and you try to rename it you will get STATUS_ACCESS_DENIED.

Notice that this is not true for memory mapped files without HANDLE's pointing to them:

Handle = CreateFileW(...);
Mapping = CreateFileMappingW(Handle, ...);
CloseHandle(Handle);
// ... use Mapping

A file that is memory-mapped like this can have its ancestor directories be renamed just fine.

Since the location of the VolFs backend storage was an NTFS directory that Windows applications were not supposed to touch, I do not get the "compatibility" argument.

EDIT: I should also add that the memory mapping is a user mode trick for having a FILE_OBJECT without an attached file HANDLE. In-kernel you can have a FILE_OBJECT without an attached memory mapping.

[therealkenc]

However I believe VolFs could perhaps have worked around this if instead of using HANDLE's to access files they were using FILE_OBJECT pointers directly.

Yes, they need(ed) an indirection (of one sort or another, implementation detail aside). All academic at this point.

A file that is memory-mapped like this can have its ancestor directories be renamed just fine.

Yep. At least flying at 40,000 feet, an approach would be to forget all the NT reads/writes, map everything, make the WSL1 read/writes memcpies. At least for local filesystems. Maybe. But I suspect there would have to be engineering on the NT side to make it work (or make it work right), and NT changes haven't been real forthcoming over the last three years. Or that is my mostly uninformed impression from the outside, anyway.

The big thing we've lost with WSL2 is a shared MM. [We've also lost a shared network, but that's maybe a feature not a bug.] In WSL2 everything has to be marshalled with dmabufs. But you weigh that against having to rewrite Linux, I guess.

[edit]

I do not get the "compatibility" argument.

Thank God you said it first, not me. The video implies this is axiomatic. Usually when one says something like (paraphrased) "fixing the rename directory problem would definitely break things" (including the adverb), you might want to finish that sentence with a: "...definitely break things like [insert obvious breakage example]".

Even if it did break things (okay), it is nothing a flag wouldn't fix -- making the MSYS2/Cygwin people happy. But I'd settle for the example, and concede "oh, you're right, that" if one were presented.

[alerighi]

I have problems with WSL2. In particular, that requires Hyper-V to be enabled, and that is not compatible with other virtualization software, such as VMWare. Even if it should be compatible now, I found many issues especially on Windows 11 and disabled it.

Also, reguarding the support of all systems call, it's not necessary. In my experience WSL1 runs fine any software that I did run. Glibc is very roboust in the sense that if it doesn't find a system call it will try another one. So even if the most new system call are not implemented, that doesn't imply you can't use the latest userspace software.

Reguarding filesystem performance it's true, but it's also true that on WSL2 working on the Windows filesystem is slower than WSL1 since it will pass trough a network connection. So it depends on what you are doing.

A feature that I like of WSL1 is that you can see all the network interfaces on your system (and thus start development server to listen without creating a bridge/NAT port forwarding), and also the fact that serial ports are brought in the WSL (useful feature for embedded developers like me).

[stuaxo]

Silly question, but has anyone forked this WSL1 ?

And indeed, though it's open source, can anyone build it ?

[crramirez]

Nobody has forked it because it is not Open-Source.

[stuaxo]

Cheers, just realised this is only for issues, not WSL itself - which is a little unusual to find on github.

[crramirez]

And there are more weird options. For example the Xaml repo has the source code of WinUI 2 but has the issue tracker for WinUI 3 too which is closed source.

[stuaxo]

The closed source model ends up being weird when bits of code are exposed. As mentioned elsewhere in this thread they should open source WSL1 if they are going to abandon it, though still - I'm not sure it would be picked up, but it would be better than nothing.

[hatoncat]

WSL1 is much more intricately tied to the Windows NT kernel, and so I suspect it would require open sourcing much of the NT kernel for anyone else to do something with it. Microsoft owns GitHub and so teams are certainly encouraged to use GitHub even for less open stuff - hence the issue tracker being homed here. But since this issue was started, it’s fairly clear Microsoft intends to dead-end WSL1 until someone else in Redmond needs it. Much like how PowerPC/RISC usage of the NT kernel was necromanced for the Xbox 360.

…

On Sep 13, 2022, at 3:11 PM, Stuart Axon ***@***.***> wrote: The closed source model ends up being weird when bits of code are exposed. As mentioned elsewhere in this thread they should open source WSL1 if they are going to abandon it, though still - I'm not sure it would be picked up, but it would be better than nothing. — Reply to this email directly, view it on GitHub <#4022 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASAJYG3IWP4GTKQTBZ72J3V6D3YDANCNFSM4RGAMDAQ>. You are receiving this because you commented.

[stuaxo]

I wonder if their support for Android is based on WSL1 or WSL2.

You could imagine them wanting the tighter integration WSL1 brings.

[hatoncat]

WS for Android is based on WSL2.

…

On Tue, Sep 13, 2022, 5:46 PM Stuart Axon ***@***.***> wrote: I wonder if their support for Android is based on WSL1 or WSL2. You could imagine them wanting the tighter integration WSL1 brings. — Reply to this email directly, view it on GitHub <#4022 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASAJYHW6FSBGA7F7L53DC3V6EN6HANCNFSM4RGAMDAQ> . You are receiving this because you commented.Message ID: ***@***.***>

[fxzxmicah]

I like WSL1 and hope it continues to be updated.

[DesktopECHO]

WSL 2 Post BUILD FAQ

Q: What will happen to WSL 1? Will it be abandoned?

A: We currently have no plans to deprecate WSL 1.

I am finding it hard to square this up with knowing WSL1 has been broken in Windows Server 2022 ( Issue #7480 ) since RTM. These BSOD's were resolved a year ago for Windows 11 insiders (22H2) but Windows Server 2022 was left twisting in the wind. WSL2 was added into Windows Server 2022 at the last minute, but it's not possible to fix a bug in WSL1?

It's not like we're asking for feature enhancements - Please let this be just an oversight and not a sign of WSL1 code going from "maintenance mode" to "outright neglect".

[crramirez]

Sadly I agree with you. We are getting bad reviews in Pengwin and Fedora due to distros are getting more and more incompatible with WSL1. And worse regularly the fail is on package management.

We will ultimately decide to have stable legacy versions only for WSL1 or redirect everyone to Pengwin Enterprise 8 that still expects a 4.x kernel.

[trungnt2910]

I am also hoping that you open up PsRegisterPicoProvider to allow third parties to write their own "library" OS'es. Consider this my "formal" request :)

I'm adding my voice for this. Picoprocesses are one of the nicest additions to the NT kernel of all time. While I know Microsoft might have given up on building the "perfect" Windows ecosystem by killing off Windows 10 Mobile, UWP Microsoft Edge, and WSL1 all together early 2020 and focus their resources on other more profitable goals, I think they should at least give developers a chance to build something similar.

Maybe this API can be abused by malware, but the similar applies to any kernel mode drivers, so why don't you just apply the same driver signature requirements to picoprocess providers?

[trungnt2910]

For WSL1 enthusiasts and NT kernel driver devs:

A NT kernel driver can modify PspPicoProviderRoutines and register custom routines, at least on a clean install of Windows 23H2.
Only test signing is needed to deploy the driver, and no debug boot, WinDbg, or other dark magic is required.

This means that with enough knowledge of the NT kernel, we might be able to hook into the callbacks and fix some bugs that Microsoft has been refusing to do for years. A coLinux-style port of the real Linux kernel as a Windows driver might also be possible using this technique.

See this proof-of-concept if you are interested.

[trungnt2910]

I don't know if the technical route of the core part of cygwin is similar to WSL1. If so, it should be more appropriate for the cygwin core team to develop this.

I would expect the two to be quite different, since:

• Cygwin runs on userland Win32, WSL1 runs on the kernel. They should have quite different functions available and quite different capabilities.
• Cygwin only aims to be POSIX-compliant, while WSL1 aims to be compatible with Linux, which is way more than just POSIX (e.g. epoll, memfd_create).

[fxzxmicah]

Yes, you should be right. Just mentioning these contents makes me think of Cygwin, and I can't think of any other team that happens to do something similar to WSL1 and can handle these complex development works.

[johnwcowan]

@trungnt2910:

Cygwin does in fact "reach down" into the kernel when necessary, for example to support hard links. In addition, as a Red Hat product it does have a great deal more Linux compatibility than mere Posix support would require, though certainly nothing like 100%.

[trungnt2910]

"reach down" into the kernel when necessary.

From what I can find about Cygwin, the lowest it "reaches down" is calling syscall wrappers in ntdll.dll; none of its components seem to directly access the kernel.

Hard links are natively supported on Windows NTFS drives using the mklink tool.

[trungnt2910]

trungnt2910/lxmonika@956932c

As of this commit, the driver implements a MaRegisterPicoProvider function, with the same interface as PsRegisterPicoProvider:

__declspec(dllexport)
NTSTATUS NTAPI
    MaRegisterPicoProvider(
        _In_ PPS_PICO_PROVIDER_ROUTINES ProviderRoutines,
        _Inout_ PPS_PICO_ROUTINES PicoRoutines
    );

Developers can link to lxmonika.lib and call this function instead of the ntoskrnl version to have up to 16 providers accepted and coexist peacefully with lxss.

For the next few weeks, I intend to create a test Pico provider and hopefully document and export more hidden functionality along the way.

Thanks for your interest the past few days; rarely has one of my repos attracted that much traffic. Let's together make Windows NT great again.

[crramirez]

Cygwin and WSL 1 are despite their similarities different beasts with different goals. Having POSIX compatible utils being regular win32 executables has their uses. For example, recently I needed to use `du -h` in a new DevDrive. It didn't work in WSL2, ok they need to add it to their 9p service. Let's try with WSL1, and surprisingly it didn't work either. WSL 1/2 don't see the drive. My third try Cygwin, it worked. Maybe maintaining Cygwin and WSL1 could be too much work for the same team. El vie, 1 dic 2023, 4:01, Trung Nguyen ***@***.***> escribió:

…

I don't know if the technical route of the core part of cygwin is similar to WSL1. If so, it should be more appropriate for the cygwin core team to develop this. I would expect the two to be quite different, since: - Cygwin runs on userland Win32, WSL1 runs on the kernel. They should have quite different functions available and quite different capabilities. - Cygwin only aims to be POSIX-compliant, while WSL1 aims to be compatible with Linux, which is way more than just POSIX (e.g. epoll, memfd_create). — Reply to this email directly, view it on GitHub <#4022 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACACEQ57U675A7ELONH5EF3YHFB65AVCNFSM4RGAMDA2U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TONZSGQ2DOMI> . You are receiving this because you commented.Message ID: ***@***.***>

[trungnt2910]

WSL 1/2 don't see the drive.

Sounds like a WSL1 bug to me, not a unique feature due to the nature of Cygwin.

[trungnt2910]

So, this is how WSL1 is treated these days.

Open one for WSL1, get a wsl1 tag (which is an internal euphemism for wontfix), then getting mass-closed for having "not had any activity".

[flydt]

to my prefer, wsl1 are much better than wsl2, hope microsoft continue on wsl1, or opensource wsl1 to public

[trungnt2910]

Would be kinda hard for them to open source WSL1 to the public for a few reasons.

1. WSL1 is filled with undocumented and unsupported functions, many of which require private headers to import (ntosp.h 👀) and some have experienced ABI breaks (lxcore.sys from RS1, RS2, and RS4 are not ABI compatible).
2. If I remember correctly, lxcore.sys actually still contains some supporting functionality for WSL2. So it actually is still actively developed, but only the crappy parts.

Your best bet would be writing a new Pico provider from scratch.

[trungnt2910]

Maybe with the WSL CLI getting open-sourced at 697572d, we might have hopes for an open-source lxcore.sys: #12922.

[trungnt2910]

A hard no from Microsoft:

No plans to do this at this time, this source is still part of the Windows OS codebase and is likely to stay that way.

Quite a generic and poor excuse IMHO.

[benapetr]

Hello,

Maybe I overlooked it but I don't see the main reason for WSL1 to remain existing mentioned here - WSL1 is literally the only WSL that works if your Windows run as a VM in hypervisor that doesn't allow nested virtualization.

WSL2 is impossible to use in such environment. Until there is some other WSL that doesn't require HW virtualization I think WSL1 must remain operational.

[0wwafa]

wsl1 is/was one of the best products for windows! wsl2 is just "another vm" and I don't see a real reason for wsl2 to exist since there is QEMU,VirtualBox and even microsoft VMs.
I use WSL on a daily basis.

[trothr]

There are several really good things about WSL1 that WSL2 misses,
most significant (to me) being that Linux code running in WSL1 shares the same TCP stack
with the host Windows system. The only serious alternative to that is CYGWIN.

I've got nothing against CYGWIN, but I'd hate to see it become the only environment
providing this "shared stack" characteristic. I see that WSL2 is incredibly popular, and it makes sense.
I just hope that WSL1 will continue to see support ... for a long time.

Of course, if someone knows how to get "shared stack" behaviour from WSL2, do share!