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.

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

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

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

[sirati]

I am very happy when WSL 2 comes and tried it with a so much enthusiasm, however I found it is not good as it is described or as good as what i expected in the end.

When I watched the original presentation, the only feeling i got was: We have to try to sell that we pulled the plug and have to replace it with something that is not even innovative. Honestly WSL1 got me excited, WSL2 just brought me back to capitalist reality.

[Akkuma]

WSL2 is quite strange. It is basically a headless vm with bridged/host only networking running on top of Hyper-V. It seems like it would have been better to support virtualbox and make that leverage Hyper-V or make Hyper-V much better for devs with a seamless/unity mode if they were really going to abandon WSL1. The amount of workarounds and attempts to get things working in WSL2 is just silly compared to me installing any distro in vbox and it works without much fuss.

If anything I think WSL2 has been a disaster from my experience and for MS as it has made me think about building a fully fledged Linux machine in the future to avoid the performance penalty of a VM, the superior window management of i3 for dev work, arguably the inability of MS to release a non-fragile alternative to a normal VM or even container, and their lack of resolving issues that have been around for many months.

[WSLUser]

First: There is not NIC Bridge Mode in WSL2. Secondly, have you seen the Phoronix benchmarks? Even with the old LTS kernel being used now, it can actually perform better or be on par with Real Linux. In fact, it can even perform better than Windows in some cases. You are thinking of WSL2 like a traditional VM. It is not. It's a microVM using namespace containment for each distro. That is how they all use the same kernel. The only perf that still needs working on the most is the interop with /mnt/c. Plan 9 performance needs to go up as well (I can delete a file from File Explorer using 9P and it will take much longer than simply rm -rf in WSL1 or 2.) I think once SMB support in Linux reaches a certain level, we could switch to that. Or perhaps some other network mechanism that delivers both speed and security (no I don't think CIFS or Samba are the answer here either).

Finally, all those workarounds you complain about it are a no-op in WSL1. Be grateful you can even use those workarounds. Before WSL2, you would be trying to find even crazier workarounds to finagle with NT magic to get WSL1 to do even more than it does. They have literally announced GUI and GPU compute are coming for WSL2. They just released mounting ext4 drives and possibly others into WSL2. This is huge as USB support as primarily a thing of WSL1, within a limited capacity. Yeah we need systemd still and for the propriety init to turn into a daemon instead but the workarounds for those aren't terribly hard. Many workarounds aren't that hard. People already spent time blogging and creating scripts to make those workarounds get applied quickly. Have faith in the WSL community and don't complain about spending a few minutes to get something running that wouldn't otherwise. It's not a big deal. Once it's set up, just be sure to make a backup of the distro afterwards. Now you never need worry about doing it again.

[Akkuma]

I compared WSL2 to essentially using that networking mode in a VM, not that it literally uses that mode. Secondly, benchmarks only matter if your system works and works well. Should I show you the numerous networking doesn't work issues, all the attempts to fix it, and the length of time it has essentially gone unaddressed or the hundreds of other issues listed or my own list that I started to keep to get stuff running OOB compared to a normal distro's OOB experience.

Based on https://blog.logrocket.com/working-with-node-js-on-hyper-v-and-wsl2/#:~:text=Comparing%20Hyper%2DV%20to%20WSL2&text=The%20user%20interface%20allows%20you,access%20to%20the%20virtual%20machine. A Hyper-V vm offers supposedly offers ~5% less performance. So the argument isn't ever just WSL2 vs WSL1. It is WSL2 vs WSL1 vs type 1 virtualization vs type 2.

all those workarounds you complain about it are a no-op in WSL1. Be grateful you can even use those workarounds.

I don't need workarounds in a proper VM as it works with barely any fiddling. Basically your premise is WSL2 is better than WSL1. You assume I think WSL2 is worse than WSL1. On a technical level, yes it is worse to me as they basically threw up their hands and abandoned ship to use a VM. On a practical one, I could careless how it is implemented if WSL2 is better than WSL1. The issue is that WSL2 is arguably worse today than simply using a VM and not having to deal with workarounds. I can remote code on my VM almost as easily as WSL2. If I really need folder access outside of the VM I can set that up too and I already get GUI support. I'm sure WSL2 when it matures will be better, but based on the quality of the WSL2 release today I'm expecting that to take at minimum 6 months if not several years.

[WSLUser]

I agree that if you're looking for all the stuff that you can expect from a traditional VM, we're got a few years to go. But there's still much you can do on your own now so you don't need to wait. That is the point of the workarounds. It's understood that WSL2 has plenty of room for growth. They are trying to tackle the biggest feature requests that have already been patiently awaited for several years already. Having some issues that can be worked around is much more acceptable than waiting several more years for the top requests for WSL to go ignored. Problem is the WSL code or the WSL2 microvm code isn't OSS (although apparently we might soon see Hyper-V running natively on Linux so it's quite close from that perspective). The other problem is the amount of devs assigned to WSL in general. They are a small team. Just like the Windows Terminal/Console team is small. If you stop to think about it, every single CLI team is small. In some cases, being open-source helps push things faster (Powershell for instance), in other cases like WSL, we are stuck being beholden to waiting for a few devs to get to it. What should happen is MS should step up the amount of devs to support the CLI. Both developers, who are developing for Windows, and system administrators who manage Windows require a good CLI experience. We have that now but it can be better. So send your feedback to a channel that can actually make impact. This isn't the best forum for exercising change within MS.

[takizo]

I compared WSL2 to essentially using that networking mode in a VM, not that it literally uses that mode. Secondly, benchmarks only matter if your system works and works well. Should I show you the numerous networking doesn't work issues, all the attempts to fix it, and the length of time it has essentially gone unaddressed or the hundreds of other issues listed or my own list that I started to keep to get stuff running OOB compared to a normal distro's OOB experience.

Based on https://blog.logrocket.com/working-with-node-js-on-hyper-v-and-wsl2/#:~:text=Comparing%20Hyper%2DV%20to%20WSL2&text=The%20user%20interface%20allows%20you,access%20to%20the%20virtual%20machine. A Hyper-V vm offers supposedly offers ~5% less performance. So the argument isn't ever just WSL2 vs WSL1. It is WSL2 vs WSL1 vs type 1 virtualization vs type 2.

all those workarounds you complain about it are a no-op in WSL1. Be grateful you can even use those workarounds.

I don't need workarounds in a proper VM as it works with barely any fiddling. Basically your premise is WSL2 is better than WSL1. You assume I think WSL2 is worse than WSL1. On a technical level, yes it is worse to me as they basically threw up their hands and abandoned ship to use a VM. On a practical one, I could careless how it is implemented if WSL2 is better than WSL1. The issue is that WSL2 is arguably worse today than simply using a VM and not having to deal with workarounds. I can remote code on my VM almost as easily as WSL2. If I really need folder access outside of the VM I can set that up too and I already get GUI support. I'm sure WSL2 when it matures will be better, but based on the quality of the WSL2 release today I'm expecting that to take at minimum 6 months if not several years.

@Akkuma spoken my pain as well. The network performance on WSL2 really a trade off compare to WSL1. Never thought virtual switch causing such a big different. There were long discussion on #4901 but no update from MS yet.

[hparadiz]

@Akkuma Basically nailed it. WSL2 feels like one big workaround.

I respect that this isn't exactly where the decision is being made but also Microsoft employees need to respect that as a customer this is a different time. Putting aside the fact that I'd had been using Windows since Windows 3.1 and never had my feedback actually be heard in that entire time why would I go and "give feedback" when I could just go and install Linux and not have to deal with the Windows ecosystem at all? In the past few years when I do a fresh Windows install I've always had to run Debloat tools, then have to jump over hoops to install my dev setup.

It's no longer a 100% guarantee that I will even be using Windows. These days it's a very negligible benefit. Office and Photoshop are the only things that don't work if you want the latest and greatest. My entire tool chain these days works out of the box on Linux. And so do my games.

With WSL1 I might have actually used Windows as a Linux server without sacrificing any performance. But now that's not possible so there's nothing Windows brings to the table. It's quite the opposite really. I am in this weird position where using Windows is actually a lot more work / maintenance / down time than using Linux. But Windows actually costs money.

The reason I was excited for WSL1 was because I thought you might add Linux style system calls to the Windows kernel. But that's clearly not happening. But maybe it should.

[Salmondx]

WSL1 was such a great concept that worked almost flawlessly for my needs (full stack web development) and worked well with existing ecosystem. The only drawback was a terrible IO performance and lags/crashes associated with intensive IO work. But at least it worked unlike WSL2.

With WSL2 as other people said we have lots of unresolvable issues or hacks + a hyper-v vm that nobody asked for. Now I can’t work with vagrant and virtualbox, have lots of problems with wsl2 itself and etc.

If WSL1 is not actively supported I guess it’s just simpler to switch to Linux.

[ghost]

WSL1 is a pain for those who develop it because they have to account for the ever increasing amounts of syscalls that Linux supports to be mapped to Windows syscalls. Correct me if I am wrong @craigloewen-msft

[adipose]

The networking issue is a black eye with no explanation. Bridge mode is the easiest thing in the world to support, given that IT'S PART OF HYPERV. Not doing it is some deliberate choice on their part, but it's unclear why.

File system performance is a tradeoff either way. I switched to improve performance, and was disappointed at the windows filesystem regression. But at least I can see the tradeoff.

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