Contra opinion: the VM option reduced the service interface between Windows and Linux to a single kernel implementation and a few drivers, rather than every possible userspace program ever written. It's an amazing and obvious trade off. My inner architecture astronaut appreciates all the ideas in this post, but I've been trying to kill that guy for over a decade now. The bottom line is WSLv1 design SUCKED precisely because it tried to cross-breed 2 extremely complex semantically incompatible systems.
Example: Linux local filesystem performance mostly derives from the dentry cache. That cache keeps a parsed representation of whatever the filesystem knows appears on disk. The dentry cache is crucial to pretty much any filesystem system call that does not already involve an open file, and IIRC many that also do. Problem is, that same cache in WSL must be subverted because Linux is not the only thing that can mutate the NTFS filesystem - any Windows program could as well. This one fundamentally unfixable problem alone is probably 80% the reason WSL1 IO perf sucked - because the design absolutely required it.
Solutions are rip out a core piece of kernel functionality, and in the process basically taking over ownership and maintenance for ALL code anywhere in the kernel assuming the existence of said cache, engineer something that is somehow better, and support this in perpetuity, including any semantic mismatches that turn up much later that were never designed for
The idea of merged ps output where Windows binaries would show up in the Linux /proc. How would you even begin to implement that without confusing EVERY process management tool ever written that interfaced with /proc? What about /proc/.../environ? On UNIX that has no character set. On Windows it is Unicode.
A trillion problems like this made WSL1 a beautiful nightmare. Glad it was tried and from watching the tickets, that team bled heroically trying to make it all work, but ultimately, I'm also glad it's gone, because the replacement is infinitely easier to engineer, maintain, and use, and that team earns its quarterly bonus much more easily. Everyone wins, except the astronauts, but as experience teaches us they never do.
I agree with the sentiment but, some scenarios have become orders of magnitude more complicated on WSL2 like connecting to a daemon on Windows or vice versa. I understand clear cut security boundaries and separate network interfaces, but it's extremely hard to get them running smoothly now. Everything was on localhost on WSL1.
Memory usage has also gone bonkers with the VM approach, causing unnecessary overhead for casual users who don't need performance.
> some scenarios have become orders of magnitude more complicated on WSL2 like connecting to a daemon on Windows or vice versa
This is about my only issue with WSL2, but it's a big one. Perhaps worse than this being a problem is that Microsoft don't seem to be providing any solutions - there are various GitHub issues about it, with non-Microsoft ransoms being the ones providing workarounds (but these depend on your environment - I haven't found any way to get this working myself!).
WSL1 was very ambitious. AFAIK, the main reason for shelving it's approach was filesystem performance. While it was indeed slower than native/VM, I personally never found it troublesome outside of artificial benchmarking. For the vast majority of use cases, WSL1 worked well, with Docker being the only real thing missing, IMO.
Running an npm install for an app of moderate complexity on WSL1 was such a painful experience that it turned me off of using the service for work dev entirely. Now with WSL2 it's much better, and I use it daily to the point where I have done away with my dual boot. (I still keep around a Linux notebook for edge cases.)
Obviously this is only re: fs perf, I can't speak to your other issues which do seem quite challenging. But I can definitely understand why they would have seen fs perf as a priority.
FYI to any WSL2 users, in it's migrated configuration the WSL VM can request as much RAM as it needs, but has no means to free this back. There's an option to use .wslconfig to specify a limit.
My problem was that the ram was never released back when I didn't use it anymore and it started to kill windows itself. Had to hard limit it from the link you provided.
It's even cheaper to only use what you need with msys2!
bash inside mintty gives me all I need, with minimal overhead.
Eventually, I'd like to see bash inside Windows Terminal made easily available - complete that with busybox, and you cover 90% of the Linux usecases without having to download anything (a bit like how starting Terminal.app offers most of what you need on MacOS)
Add an option to install packages using msys2/pacman for the power users, and I believe most people would not waste time (or disk space, or ram) playing with WSL1 or WSL2 just to run the one thing they may need.
The "init" process is just a stub used by WSL, it is not a "real" init system. And Cygwin also allows the creation of multiple users within the Cygwin environment, doesn't it? It's just a matter of populating /etc/passwd. If you want to use WSL1 with a single user then you could just set the default user to root.
It's clear that they are not enthusiastic about delivering new features to WSL1. Consider how WSL2 now exclusively features CUDA support, Wayland support, loop mounts, Docker, etc.
Docker can't be hosted on WSL1. You can use the Docker client on WSL1 to communicate with a Docker host running on WSL2 or Hyper-V, though (which is how Docker Desktop works)
I think WSL1 is there for transitional purposes and will be thrown away eventually. It was already incomplete, it didn't support forwarding any ICMP packets other than ping, so traceroute didn't work for example. I don't expect it to stay as an option for long.
At work we develop on Windows virtual machines, and WSL1 won't run on a VM. Fortunately WSL2 does, so at least I can enjoy Linux tooling I sorely missed.
Interesting, I would expect the opposite problem since WSL1 doesn't use virtualisation in any way. Do you have more details about the error you experienced?
Unfortunately I tried WSL1, didn't work, and left it at that for months. When WSL2 was out, it just worked and I had forgotten by then what kind of error WSL1 gave me.
I can only recall it was a dialog box, not a crash, and that it had to do about virtualization.
That doesn't seem impossible to implement. Can't you connect to some port on your gateway to access the host? Even if you currently can't, it still seems pretty easy to implement in the grand scale of things, than trying to make WSL1 work.
I'd imagine it is in some todo list somewhere in Microsoft
I've had surprisingly good results running that sort of thing under WSL2. Pure CPU workloads actually work pretty well, and in my experience valgrind has mostly been CPU intensive?
The individual process inside the vm might not consume much, but the vm itself might reserve some GBs of memory. Try looking at how much memory `vmmem` process used in task manager.
"So, I was copying a 8GB file to my Debian home folder using Windows Explorer, via $wsl network. The copy process made my CPU's fan runs like a jetplane, and it stop copying when at 95%, then I opened up Task Manager and saw this.
even after it finish copying, Vmmem process still hold 13GB RAM and not release any. Why? I have to shutdown WSL after copy a big file?
Answer:
Very normal but annoying issue. ... The only solutions are:
a) a kernel change by MS to limit the amount WSL2 can cache b) disable to caching ( nocache ) c) Put a limit on the WSL hyper-v VM
Not sure what or how MS will try to solve this issue... WSL1 did not have this issue, because it shared the main system memory, because it was just a layer around the NT kernel."
I can't find that process in my system, nor a significant difference in physical RAM usage before and after starting Ubuntu in WSL2. Digging a little it seems like memory is dynamically allocated and reclaimed when freed. I'm not defending WSL2, just trying to understand how is it supposed to consume 8GB of my 16Gb of RAM.
I don't have that process while running WSL2 in my machine. I have vm-agent and vm-agent-daemon, but I'm using a virtual desktop, so this might or not be related to WSL2. Both of these processes consume less than 10 Mb combined. In my other comment [0] I referenced a link from Microsoft that says RAM is dynamically allocated and reclaimed when freed.
This hasn't been my experience, but sure, even if memory consumption is higher, for most applications where Windows users are going to use WSL, additional memory is incredibly cheap compared to the dev overhead of trying to boot into a Linux environment and switching back and forth.
Let's see this from the opposite point of view: WSL1 is to WSL2 what WINE is to a VM running Windows. Two completely different approaches.
The thing that would have allowed the WSL1 to do was to really integrate between Windows and Linux: imagine writing running a Linux command, piping its output in a Windows command to pipe it again in a Linux command. Imagine sending a signal to a Linux process from a Windows process. Or imagine accessing physical hardware from the Linux subsystem. With the WSL2 is impossible to even use a serial port!
WSL1 had performance problems. That thing about the filesystem performance could have been the occasion to optimize NTFS and even to add to the NT kernel the support for other filesystem, natively. Or why not add to the NT kernel other Linux functionality, to make them available both in the Linux and Windows subsystems.
Of course not everything would have been possible to map on the NT kernel. That is fine. But for most application really the WSL1 was usable.
Maybe the real problem with the WSL was only having called it "Widnows subsystem for Linux". They should really have made WSP: Windows Subsystem for POSIX. Drop the binary compatibility with Linux requirement and just make it an environment in which you can compile code that uses the POSIX API and interface with Windows. Not having binary compatibility with Linux is not a big deal, thing about it but is what macOS does and nobody seems to care, and users would have created a package manager just like there is brew in macOS to easily install software.
imagine writing running a Linux command, piping its output in a Windows command to pipe it again in a Linux command.
But that's not most of us want to do with WSL. We just want to run the team's React app with its rube goldberg npm monstrosity that falls over when you try to run it on windows.
That use case covers 90% of us. No need to ask for anything more.
This is how our industry goes to crap. Repeatedly pruning things that 90% of the current userbase doesn't use over time give you a thoroughly useless product. I mean, do it 7 times, and you've already lost 50% of your audience. If you target 80% cutoff, you're down to 20% of the users now.
I personally do want it from WSL. Hell, 90% of my use of WSL is like this - I run Emacs on my work machine under WSL, where it feels at home. I use it to drive Windows-side cmake and Visual Studio compiler, piping output back to Emacs. Because I can, it works, and it's a much nicer working experience than any app could give me.
Not having binary compatibility with Linux is not a big deal
But it is, because there is actually lots of proprietary software available on Linux as binary-only --- many of it very specialised and expensive --- and Microsoft wants to be able to run that too.
It was a hack to get around a US regulation about government procurement requiring POSIX support. So I think tried is a very strong word, it was never intended to be remotely useful.
> That thing about the filesystem performance could have been the occasion to optimize NTFS and even to add to the NT kernel the support for other filesystem, natively.
I doubt that would be feasible given how important backwards compatibility is for Microsoft's business. WSL1 seemed like a huge effort on its own, so changing one of the most critical OS features would be a little ambitious.
> imagine writing running a Linux command, piping its output in a Windows command to pipe it again in a Linux command.
Actually for that special case WSL2 works. I'm currently experimenting with `sshd -i` on WSL2; not sure why it doesn't work on Ubuntu 20.04 but does on OpenSUSE 15.2…
The argument about Windows not having a single, central dentry cache doesn't hold water. For one thing, there's no reason to think that a two-level cache would significantly decrease performance. More importantly, the fact that on Windows most VFS work occurs in the filesystem driver itself only proves that Windows could have implemented an EXT4 driver with better dentry and other semantics and permitted WSL1 environments to keep most of its files on an EXT4 volume, which is what happens with WSL2, anyhow.
WSL1 could have been better in every way. It would have required them to track a moving target, but they already accomplished semantic parity with seemingly minimal resources. Improving performance was certainly possible, and keeping up would have required significantly less work on its own. At the end of the day, I think the reason WSL1 was canned is obvious: the decision to ship WSL1 was probably accidental. Why accidental? Because anyone with the slightest business acumen would realize that a WSL1 environment with feature and performance parity to open source Linux would mean there'd be little reason to target Windows' native environment at all for new software development. And while Microsoft has done relatively well for itself with Azure and other ventures, its revenue still principally derives from Windows and Office, and the last thing Microsoft needs is to accelerate movement away from those products.
WSL2 means that Microsoft can keep its Linux environment a second-class citizen without being blamed for it, while still providing all the convenience necessary for doing Linux server application development locally. Integration with the native Windows environment will be handicapped bydesign and excused as an insurmountable consequence of a VM architecture. For example, with WSL1 and some obvious and straight-forward improvements it would have been trivial to run a Linux-built Electron app with identical performance, responsiveness, and behavior (not to mention look & feel, given the web-like UI). With WSL2 Microsoft will likely only ever provide GUI integration over RDP, which will never have the same responsiveness (not because it's theoretically impossible, but because nobody would ever demand it, and in any event it would require tremendously more effort than the comparable WSL1 approach).
> the bottleneck is that NTFS is a crappy filesystem.
Care to explain why do you think NTFS is crap?
From my experience it's usually bad assumptions about files under windows and every application or library tries to stick to posix interface when dealing with files (open, read/write, close) which tends to block for longer periods on windows than on linux counterparts which results in significant perfomance loss .
Linux first software will always outperform windows implementation and Windows first software will outperform Linux implementations unless you provide separate code paths to properly handle underlying OS architecture and assumptions.
On Windows closing the file handle is extremely costly operation due AV checks and file content indexing [1]
An interesting observation I did was that even Hello World is about 100x faster on Linux than on Windows.
In my Linux VM I had to use the time command to even have an idea of how long it took, as it seemed to return immediately. I think 5-15ms but it already a while ago.
On the Windows machine where the Linux VM ran it took several hundred ms.
so what's the 'Windows way' then? keeping a file open forever and let it lock out other programs from using that file? I'm starting to get an idea why Windows is getting on my nerves so much with file locks....
Using either memory mapped files of overlapped io (IOCP).
It's tricky to use when you want to write the content since you must preallocate the file before you start with the writing. Appending to file just doesn't work under NT kernel since WriteFile blocks even if you use overlapped io.
Devs just need different mentality when it comes to Windows programming compared to Linux. Due the fact that everything under NT kernel is operated asynchronously you'll have to adapt your code to such concept. Meanwhile under Linux you had no other alternative for nearly 30 years (io_uring and friends) so if you wanted to be portable with minimum OS specific code then you had to implement things in synchronous way or write two separate code paths for each OS.
NTFS on Windows was indeed always significantly slower when doing a lot of file operations. It was noticeable even long before WSL existed: NTFS and the whole infrastructure connected to it has by design bigger maintenance cost for every opening of the file, for example. That's undeniable. One can say that NTFS could have maybe been implemented faster on some other system (with less hooks etc), but NTFS on Windows is provably slower for the file operations people do every day on Linux, that's a simple fact. Like working with big source repositories containing a lot of files (git, node.js). The people who decided to make WSL2 faster for Linux programs achieved the speedup by going full VM. I would also prefer that they worked on NTFS on Windows long enough until the file operations become faster for everybody, but it didn't happen.
That's one of the lost opportunities that the original article laments about.
Edit: a reply to dataflow’s "try your operations on another file system" answer: I don't have to, I remember: there was a time when people used FAT formatted media much more than today -- and NTFS was slower than FAT too, under the same Windows, on the same hardware, without installing anything from third parties. It can be that on Windows 10 FAT got to be comparably slow, but in earlier times, on slower machines, FAT was visibly faster compared to NTFS. But NTFS was more robust to failures, and I preferred using NTFS for anything that is not temporary. I admit that the whole Windows infrastructure around what we consider purely "a filesystem" is also a serious part of the problem, by design. And as I wrote, it's a lost opportunity that the bottlenecks weren't identified and the changes made to the benefit of everything on some future Windows.
Note: I've explicitly said: "NTFS on Windows" and "NTFS and the whole infrastructure connected to it". Also: "NTFS was slower than FAT" was true for years. I have no experience with BTRFS, but that doesn't prove anything without knowing more details (the overhead introduced to make it work). So... it's both NTFS and the Windows "subsystems."
I remember this issue when creating few million of files inside one folder and it was extremelly slow because of 8dot3 name creation. It has to go through each filename to generate short name O(n) when this legacy feature is enabled.
After disabling 8dot3 there were no performance issues anymore.
> I have no experience with BTRFS, but that doesn't prove anything without knowing more details (the overhead introduced to make it work)
I tried to point out following:
Ext4, Btrfs, Zfs, any other UNIX filesystem will be slow under Windows. NTFS or any Windows first filesystem will be slow on Linux. There is just too much of the differences in OS architecture between the NT and Linux.
> The argument about Windows not having a single, central dentry cache doesn't hold water
This was more about cache coherency, and it's not an argument, it's a trait shared by every other Linux-over-X implementation (UML, coLinux). It is fundamental to solving a problem users want - seamless integration, i.e. no opaque ext4 blob. Why doubt the reasons given by Microsoft, when they match observations not just for WSL but every other system in the same class?
Good points; in addition, I can only imagine the headache of trying to support the latest eBPF, io_uring, WireGuard, and other advanced kernel features in WSL1. I imagine a lot of newer features would return ENOSUPP from the kernel, so WSL1 basically becomes a weird fork of an old Linux kernel. (Weird because it lacks a large community, and old because the ENOSUPP's downgrade what's available.)
In WSL2 everything should work (depending on the CONFIG options and how much Microsoft has changed).
Linux and Unix in general seems to love huge writeback caching, which is great for speed but horrible for consistency and reliability to power failure and such; on the other hand, Windows flushes the caches more often, providing greater reliability but without as much speed.
That's been my experience, in any case; doing lots of small file operations barely causes any disk activity in Linux, but far more in Windows. Moreover, abruptly cutting power in the middle of that would likely result in far more writes lost on Linux than on Windows.
Linux/Unix just trust that if you want something persisted with certainty you'll do an fsync, if you do it will absolutely guarantee you're not losing that. It will absolutely make sure that your filesystem doesn't get corrupted by a power loss but if you didn't fsync your write you had no place believing it was persisted.
Doing that IMHO matches real world use much better.
If I do a compile and get a power outage I don't care
if some object files get lost. If I do an INSERT in a DB I do care a lot but the DB knows that and will fsync before
telling me it succeeded. So making sync explicit
gives you both great performance and flexibility.
Doing that IMHO matches real world use much better. If I do a compile and get a power outage I don't care if some object files get lost.
The real world use is someone working on a document, using Save periodically, and expecting whatever was last saved to survive the next outage, not some arbitrarily old version.
What are the trillion other problems? Honest question, some I heard this a lot, but in reality I only ever saw people complain about the speed of the filesystem. So that would just mean 1 (hard) thing to fix.
The network stack integration was less than transparent too. Random places all over the system where e.g. a magical ioctl() just didn't work properly. Who really wants to spend their life reimplementing every last baroque detail of that stuff?
The actual advantage of working on something like WSL1 is that it would ensure that the NT kernel is as capable as the Linux kernel (Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels).
For instance, the complaints about I/O performance are because the NT kernel has a worse implementation, so they should have improved it for both Win32 and Linux apps instead of giving up.
(your reasoning about the dentry cache makes no sense though since such a cache would be implemented by the NT kernel and certainly not by WSL1, so there's no difference between Linux and Windows programs)
> (Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels)
That is a coffee-spewing statement. Linux generally has a reputation of approaching new features by coming late to the party, seeing the mistakes everyone else made in the feature, and then implementing it somehow even more poorly than everybody else.
An example of a particularly bad Linux subsystem is ptrace, which interacts poorly with threads, relies on signals (itself a bit of a mess of a feature), and is notorious for all the races you have to do to actually properly set up a debugger. The Windows debugger API is much simpler, and even includes some features I'd love to have in Linux instead (hello, CreateRemoteThread!). I was going to write to the parent comment that implementing ptrace to let you run gdb (or, worse, rr!) in WSL1 would have been something that every NT kernel programmer would have "NOPE"d at because the impedance mismatch is just that high.
I mean, it's entirely possible to implement ptrace if you spend enough time doing it, it will just be complicated and the performance will likely be not that great. (But yes, it's a pretty bad API.)
As I understand it, it's not really possible to "improve" Win32 I/O performance -- both the fundamental I/O APIs and the NTFS on-disk storage format make high performance infeasible.
Not without either abandoning all extant FS drivers, or abandoning NTFS compatibility, anyway.
Edit: Here are the WSL 1.x's team members original comments on this subject. It sounds like a deeply intractable problem.
The second link explains why a dentry cache just isn't feasible.
The short version is that the NT IO APIs seem to have been very, very ill-considered. It's just not possible to make it fast. Even win32 operations are extremely slow, so win32 applications go out of their way to avoid doing any file I/O. Linux applications were not written with those constraints in mind.
> Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels
Another interpretation is that Linux has been trying to re-implement Unix for 30 years, when the point of Unix in 1970 was a simple portable operating system that can be coded in like half a year.
I find IO on windows is fine, the problem with WSL1 was that the standard windows model doesn't line up well with Linux (fairly fundamental things like in Linux you can delete open files, which you can't do in Windows).
You couldn't switch Windows to a more linux-like model, it would break all existing windows programs.
I think we all are sometimes guilty of reading too much into things. WSL was announced to support developers. Not Administrators. The Windows/Azure division has a strategy for administration. And that is Powershell (also on Linux). They admin strategy is implement Powershell commandlets for Windows and Linux and execute them via Powershell (and things like DSC).
WSL however was always announced as a tool for developers to develop stuff. As long as you can run Linux tools and services and finish your dev tasks with it, they are considering it as goal achieved.
This is a really interesting article, and WSL 1 was a testament to Dave Cutler's vision for the NT architecture re: support for multiple operating environments (read 'Showstopper!' for more background).
Also, as someone hacking with a custom OS kernel in their spare time, I found this quote illuminating when it comes to understanding the lower level:
> A user-space process is a collection of binary instructions that the processor executes uninterruptedly (leaving interrupts aside). The operating system’s kernel is unaware of what the process is doing until the process issues a system call: at that point, the kernel regains control to perform an operation on behalf of the user, which can be something like reading a file or pausing for a few seconds.
[Edit: My first point is actually incorrect - see child comment about 'pico processes']
WSL 1 actually doesn't use the NT subsystem architecture like SFU/Interix did (and this article implies). Instead WSL 1 was implemented with a relatively new feature called "pico processes". See: https://docs.microsoft.com/en-us/archive/blogs/wsl/pico-proc...
That leaves out the fact that the kernel scheduler does in fact issue timed interrupts to all kernel and userspace code running on a given core, except for "critical sections" (where one or more locks are held).
That being said, the scheduler is so reliable and so seamless that one need hardly ever worry about it unless a particular block of code must not be interrupted, usually for parts of parallel/multithreaded code that have shared memory or other resources, or sections within the kernel or scheduler itself.
The OS/2 subsystem only ever emulated OS/2 1.x, it never emulated OS/2 2.x or later. That severely limited its usefulness. Also, it only supported text mode apps out of the box, and the GUI was only available from Microsoft as an add-on sold separately (which very few people bought)
There was never a huge amount of OS/2 software anyway. And a lot of what software was available for OS/2, also had native Windows versions, so why bother emulating the OS/2 version when you can just switch to the native app?
A lot of people ran OS/2 1.x because it was the basis of Microsoft's networking solution, Microsoft LAN Manager – which as well as being sold by Microsoft, was also sold in OEM versions from IBM, HP, 3Com, among others. But rather than trying to run OS/2-based LAN Manager under NT, people used NT's native implementation of the LAN Manager protocols (SMB File & Print)
I think the POSIX subsystem could have been a lot more successful if Microsoft had invested in it more. But I think Microsoft was worried about investing in it too much, because if UNIX software can run on Windows, a lot of developers might just write UNIX software only, not write to the native Win32 API, and then there would be less switching costs to move that software off Windows and on to UNIX or Linux.
What is different about WSL, is that by now POSIX has clearly won the battle for developer mindshare, and Microsoft has decided their best interests are to cooperate with it fully rather than continue in their prior hesitancy about it. But they've had 20+ years to watch it win in the market, and that's informed their change of heart.
I only cared about Linux, because of the way Microsoft managed their POSIX support.
From my point of view, Linux would never taken off if POSIX had been taken more seriously.
I do disagree with the developer mindshare though, for me they are looking into the market for cloud, where yes UNIX was won, but there are plenty of scenarios out there where UNIX support is meaningless, desktop applications, mobile platforms, IoT, mainframes.
Then they saw an opportunity to bring back into Windows those developers that are buying Apple laptops for shiny UNIX experience, not connect at all with Apple's culture and now looking to move elsewhere.
Personally I am yet to care about using WSL, in any of its variants, all my programming tools are anyway mostly OS agnostic, and the ones that aren't are focused on Windows deployment scenarios anyway.
> "From my point of view, Linux would never taken off if POSIX had been taken more seriously."
Taking POSIX seriously would have made no sense at the time. Back then, Microsoft seemed in a position to supplant the '70s era UNIX architecture with a more up-to-date '90s era son-of-VMS architecture for servers. Nobody was expecting Linux to come out of the blue, brutally fratricide all the other UNIXes, and take over the server market.
Starting my development journey on Windows many years ago, discovering Linux and eventually daily driving MacOS for years - WSL1 has enabled me to once again make Windows 10 my daily driver for both work and play for the last year.
I spent several months using WSL2 but because the implementation attempts to hide virtualization behind a curtain, it was unclear where the magic successfully blended the guest with the host and where it didn't. I ended up having a lot of trouble with networking, and leaned heavily on my understanding of virtualization to debug those issues:
- Connections to Windows VPNs wouldn't work well inside the WSL guest
- Running browser automation tools like Playwright wouldn't allow you access to the browser in Windows
- The WSL2 guest can't connect to services (tcp, ports, whatever) running on the Windows host
- Trying to do something like `ssh -D 1337` from inside the WSL guest is confusing
- If you run `ssh -L 8080:localhost:8080 remote.com` using powershell, the WSL guest does not have access to port `8080`.
While incredible in that it has dynamic VM memory allocation and such, it still felt like running Linux in VirtualBox, SSHing into it and having a lot of automation to handle port forwarding - a workflow I have used in the past and isn't very revolutionary.
WSL1, while a simpler implementation that is more feature constrained, I felt that it matched my behavioural expectations (an API mapping that isn't feature complete) making it more useful. I continue to daily drive it.
Windows Terminal also made Windows competitive with other OSes that have quality terminal emulators, such as `iTerm2` or `gnome-terminal` (`hyper` is too memory heavy, though `cmder` is not too bad).
It's my understanding that MS wants to focus on Hyper-V to make VMs more like containers, but for my simple use-case/world view, I would rather the "reverse Wine" world of WSL1 to the "enhanced VM" world of Hyper V.
I will continue to use WSL1 daily and hope MS chooses to focus on this style of integration over the WSL2 style. I'd love to see features like blending `/etc/hosts`, supporting `tmpfs` and containerization (without virtualization).
If MS deprecates WSL1, I will probably move back to MacOS or Linux.
>The WSL2 guest can't connect to services (tcp, ports, whatever) running on the Windows host
I assume you're talking about how you need to use the hosts ip rather than localhost? Because you definitely can access host ports. I'm even connecting WSL2 to an X server running on windows.
This is actually a good point I glossed over and is completely correct.
You can access the host via its IP but you can fall into application level "not localhost" security checks (Chrome for example).
You also have to know that the guest has a different IP to the host and while I can lean on my experience with virtualisation to understand and maybe find a way around the issue, it's an example of the incongruence of WSL2. What you see is definitely not what you get.
It's not a fair bar to set for most engineers, especially those who have recently entered the industry or are trying Linux (bash via WSL) for the first time.
I too was really sad to see WSL 1 be replaced by what seems to be just a built-in VM. One of the great things about WSL 1 is that I can run Linux tools on my laptop without the memory overhead of a VM. My laptop only has 8GB of ram which is not enough for Windows and a Linux VM to comfortably share, but plenty to run the Linux tooling I want under WSL 1.
On my desktop with 16GB of ram I can just run Virtualbox. WSL 2 solves nothing for me. Like the author I am very skeptical that WSL 1 will be maintained going forward but I hope it is.
While still being a VM, WSL2 works much better than a Virtualbox VM: boots in 1 second (!) on my machine, as attested by uptime and dmesg, has dynamic memory reclamation, out of the box file sharing through \\wsl$, VSCode integration.
So 1 second by default is impressive, but not really special for those who can already run a VM.
Dynamic memory reclamation is turned on by default for any modern Linux distributions running in Hyper-V. Last I checked the performance of \\wsl$ is terrible (certainly not on par with NFS).
I can see it might be slightly more ergonomic for casual users though, but certainly not to the point WSL 1 has already been at.
This article is entirely wrong about why it's called the Windows Subsystem for Linux and not the Linux Subsystem for Windows (not surprising, since his argument makes no sense). The real reason is that Microsoft can't name something leading with a trademark owned by someone else. Here it is straight from the horse's mouth, senior PM of WSL Rich Turner:
https://twitter.com/richturn_ms/status/1245481405947076610
I'd never actually read it with the apostrophe as pointing out in that tweet so the name makes a lot more sense now. Perhaps Windows Subsystem for (running) Linux would be clearer hah
Also, according to his profile, Rich is former Product Manager for WSL and currently "Sr. PM for the Windows Command Line, Windows Terminal"
The interpretation in the article was still interesting nonetheless
WSL 1 (haven't tried 2 if they have some sort of magic for this, guess not) can actually run windows applications.
So you can run "ipconfig.exe | cowsay" for instance.
I'm not in front of a windows machine now but you could do stuff like list windows processes with a windows command, filter it with linux command and take the result to kill a process. All in a short line.
And honestly, more integrated than that I'm not sure I want. I like isolation and knowing that my linux command won't touch windows processes etc.
But an utility that can list and kill both Linux and windows processes can be done in a short shell-script.
Not sure I agree with this write up. Microsoft can and is already plumbing various host bits into the guest virtual machine (e.g. GPU). There's nothing preventing them from exposing processes, per the author's wishes, but it really comes down to -- do folks really need/want that? If so, file an issue in the WSL repository and get the ball rolling!
As someone who has done work on a sort of "Darwin subsystem for Linux", seeing the death of WSL1 has been really sad. Linux is one of the few OSes where this kind of approach really makes sense, since it's open source and has a small, very well-defined, stable ABI that you can implement and everything should "just work". Of course this process can be tedious and complicated, but I mean it is so much easier than what Wine or Darling is doing on a closed-source OS at a very different layer in the stack. It's of course obvious why WSL2 exists but its existence brings a great sadness, like Oracle buying Sun or Google killing off Hangouts and replacing it with whatever they're using these days.
If you want a Linux-like environment on Windows that can see and be seen from the Windows side, there is Cygwin. It's not as deeply integrated as WSL1, nor has binary compatibility (you'll have to get binaries compiled for it or compile them yourself) but last time I checked (Windows 7, IIRC) it did the job.
I used Cygwin for a long time and the main issue was fairly poor performance. WSL-1 is a significant step up in that sense, and WSL-2 blows them both out of the water. There are trade-offs, they all still seem to have their place.
Cygwin was always a lot more cumbersome. Building programs for it is a pain and doesn't always work. It's better than nothing, but WSL1 (and SFU/Interix before it) is a lot better.
I tried migrating to wsl (1) but there was just too many little things not working so went back to cygwin. WSL had issues with watching files, mounting some network drives and windows interop that I've never had with cygwin.
This is great news. It offers a lot of what the author wants (except the speed of WSL2).
I would expect it to be less-complete than WSL1 (it looks like Linux, until you look it from up close) but faster, because it doesn't try as hard to be a Linux.
I've used MinGW's MSYS which gives you a posix development environment. Was the simplest way to get support for autotools on windows. Useful if you need to cross compile a library on windows.
WSL2 is faster and works better in almost every way. As a developer I absolutely love it and it has changed my workflow completely.
I haven't run into any limitations that kept me from doing what I wanted to do with it, and some minor adjustments like using wsl2host helps bridge any gaps.
What did we sacrifice along the way? Well, apparently we can't change our Windows network config or see Windows processes through Linux tools that weren't designed for it anyway.
And we want that sort of thing because, it's, uhh, "cool"? Those priorities don't make sense to me, but maybe I don't fully understand what people want to do with it.
I'm extremely ignorant about OS design, but based on this it sounds like WSL1 could be fairly described as basically Linux for the Windows kernel, whereas WSL2 is more like a really fancy VM. Is that the gist of it?
More or less. Though I'd rephrase your description of WSL1 as "Linux for the NT kernel".
In that sense "Win32" (the API used by Windows programs) could also be described as "Win32 for the NT kernel". They are both subsystems that translate their APIs into NT kernel calls.
Windows NT used to have a number of these subsystems but all except Win32 were deprecated and eventually removed.
I see, that makes sense! This is a really interesting design and seeing it this way gives me more respect for the Windows operating system generally. Is this subsystem concept something that has a parallel on the *nix/BSD side of the fence? Or is it unique to the NT architecture?
The closest example outside Windows I can think of is the idea of "zones" in Solaris/Illumos/SmartOS. You can have a "LX branded zone" where the OS will respond to linux syscalls.
I don't know if the native solaris syscall interface is itself a zone, while Win32 is a subsystem on Windows.
This is a cool example, and now that you mention it docker as well seems to provide similar functionality. I guess what's striking about WSL1 then (and maybe what the author was saying) is that it's a mix between a docker container and like wine.
WSL1 is like the "kernel personalities" in other operating systems like the BSDs. WSL2 is more like Linux for Windows, because it is the actual Linux kernel in a VM, hypervised by Windows.
I remember NT was to have an OS/2 subsystem, probably because it started out as OS/2 3.0, with a New Technology (NT) kernel. I know there was a POSIX system, but I never saw or interacted with it and, legend says, it was only used to check a box in government contracts.
The original POSIX subsystem was not very useful -- a minimal set of system calls, plus a Microsoft re-branded MKS Toolkit to provide shells and utilities.
Microsoft ended up buying Interix, who offered a much more pleasant UNIX-on-Windows setup. That was supported for many years as "SFU" and later "SUA"
SUA was still a pretty weird UNIX though. PE-COFF binaries, and a linker that wasn't 100% GNU compatible, and a lot of other little oddities. Porting software to SUA was never very much fun.
I assume that was the motive for WSL -- same idea as SUA, but less weird for software ports.
> SUA was still a pretty weird UNIX though. PE-COFF binaries
PE-COFF comes from UNIX originally – COFF was the executable format introduced by AT&T in Unix System V, up to and including SVR3 – in SVR4, it was replaced with ELF. PE-COFF is simply Microsoft's variant of COFF. There are other variants, such as IBM's XCOFF (used on AIX). Given that COFF originated on UNIX and has a long history of use there, should we really call a UNIX(-like) "weird" for using it?
The UNIX standard doesn't mandate any particular executable file format. macOS uses Mach-O. z/OS uses GOFF. Both are certified UNIX. (Interix/SFU/SUA never was, but there was nothing stopping Microsoft pursuing UNIX certification for it if that had been a priority for them.)
SVR4 was released in 1990, before win32 or NT even existed. By the time Interix came along, the whole world was ELF — there was even an Intel standard that unified all x86 UNIX ABIs, iBCS.
AIX is the only Unix to retain COFF.
It’s deeply weird, unsupported by standard tools, and shipped with a not quite 100% compatible shim for the gnu linker.
I remember using Interix back in the late 90s to port our home-grown source control system that we used on various UNIX flavours over to NT. The source control system was basically a bunch of shell scripts which wrapped either SCCS or RCS depending on which was available on the system in question. Porting them to Interix on NT worked pretty well, though there were some wrinkles with file permissions.
Gentoo-prefix on SUA was my daily driver for years. I had all the “could you imagine” stuff mentioned in the article - dealing with the random build errors now an then did get old though. I always wondered why more people didn’t use it especially seeing how popular WSL is now. Maybe SUA was just ahead of its time?
On XP and 7 (and 8, perhaps) I used Cygwin to have a Unix-like environment. Does it still work on Windows 10? I remember I could call Windows programs from it and manipulate Windows files.
SFU/SUA lived in kernel space -- they implemented a new set of system calls alongside win32. Binaries for SFU/SUA could not be executed on a system without SFU/SUA configured, because the kernel subsystem would be absent. (I also don't believe you could call win32 from SUA, but my memory is foggy.)
Cygwin and MSYS are attempts to map UNIX semantics onto windows system calls, to varying degrees of success.
True, but it has some of the features the author mentions he would like from WSL1 (such as the bi-directional visibility), and, being open-source, if they really want it, they can always add it.
Cygwin is definitely still around, but most people are using msys2/mingw and its bash prompt nowadays, especially with Git for Windows making it nearly ubiquitous.
There were so many of these - the original POSIX subsystem, MKS, Interix, a bunch I'm surely forgetting, Cygwin, etc.
None of them quite lived up to the design promise of a frictionless 'personality' OS layer on top of the existing OS. If anything, I'm curious how Microsoft, organizationally and
technically, decided to give this yet another go with WSL1 - perhaps 'fail fast' and switching to virtualization was something they'd considered as a plausible escape hatch from the start.
One of the things I really liked about WSL1 was the integration with Windows. This caused some bugs but made other task a lot simpler. For example editing a file that existed in the Windows file system with a Windows application and then actually processing it with a linux binary worked really well most of the time.
With WSL2 you are expected to only interact with files in the linux filesystem with linux. I'm sure this made a bunch of easier for the dev team but it kinda ruins WSL for me.
I still haven't figured out how to call a binary that exist in the linux vm from Windows or how to interact with the windows network from linux.
re files - you can mount an nfs export in WSL and Windows 10 comes with a opt-in NFS server - or perhaps try samba.
re network - if you mean localhost, that's probably impossible due to WSL2 being a vm unless the folks at MS invent some deep black magic. you should be able to use the LAN interface IP address, though.
I don’t have a dog in this fight, nor any experience with Windows since 7, nor much familiarity with the various low level differences that might make WSL 1 the giant ball of asterisks and footnotes and incompatibilities that I can intuitively imagine based on the conceptual explanation. That said, as a Mac user—a system with a great deal more common heritage with Linux—knowing that such a compatibility approach for (say) Docker hasn’t even been attempted, despite the huge amount of developer goodwill it could generate, because the OSes are so significantly different... I’m impressed that WSL 1 was even tried.
Also as such an outsider, I have to wonder if a similar approach in the opposite direction (bring core Windows APIs more in line with *nix, build traditional Windows environment compatibility layers on top for existing software, eventually become a Linux) might have been a more expensive but more successful and future proof approach. Even so, that sounds (even in the abstract) a lot to ask. Even from one of the largest software vendors in existence.
I’m sure there’s a ton of details I’m missing or getting confused, but it’s interesting brain food for me as someone fully in the Apple ecosystem but perpetually casually watching the MS ecosystem and its improvements as a backup plan.
Yeah this really resonated with me. I thought WSL1 was a great idea and they gave up on all the great integration aspects just to gain some minor things like docker compatibility :(
After all, people who wanted to do that could always run Linux in a VM.
> And the reason I can imagine this is because macOS gives you this model (albeit cheating because macOS is essentially Unix).
What is the cheat there? That MacOS X is a single operating system, where both, command line tools the blog author knows and GUI tools, life in the same world, with da process model and same devices on a single kernel, unlike WSL? How is that cheating? Is my Linux desktop cheating as well?
Well, cheating in that it’s a totally different system, which makes it not a good apples to apples comparison. MacOS is UNIX. Unix and Linux are similar in many ways and plenty of Linux utilities have been ported over or packaged for macOS, the same as any other BSD, but as you say, it’s one kernel and one system with different interface options. It’s not as if you’re having to deal with different file systems or share the same hardware across kernels.
A better comparison would be Docker for Mac, which has had several approaches over the years. Originally, Docker Desktop for Mac used VirtualBox in the background to spin up a VM that was then used for containers. It then moved to using HyperKit, which is the more “native” soliton but has downsides, largely around I/O and CPU usage, many of the same problems facing WSL1 and some of the edge cases with WSL2.
Docker for Mac however is no Apple Product. Thus nothing Apple can be blamed or praised for (at the most as enabler)
And it doesn't fit the requirements they stated: The docker container can't see the host's processes nor can the host see the container's processes. So the suggested "cheat" isn't there either.
cheating as in they have much less work to do to implement unix-like linux on the hood because it was already there, and Microsoft actually has to build a port.
Where is MacOS implementing Linux? At it's core it is a Unix system (not sure whether they have any recent certification, but doesn't matter) tltonlarge parts following POSIX with a fancy GUI.
Which was not always the case, up until Mac OS 9 there was no Unix. They delivered with Mac OS X. That’s not cheating, it’s pointing out that Microsoft failed in this regard.
MacOS X is not a new version of MacOS 9 - it's renamed OPENSTEP with a MacOS X theme and some parts replaced. It's also very different from most Unixes in that it has a Mach microkernel with a BSD coat of paint. It almost has more in common with NT than it has with Linux.
Before that, MacOS had (AFAIK - never seen it myself) the MPW environment that had a Unix-like shell.
I don't think it's accurate to call it a "BSD coat of paint."
Practically an entire BSD kernel is run as a single "server" in Mach. In Apple's open source release, a majority of the XNU kernel code lies in the "bsd" subdirectory -- Apple's heavily patched 4.3BSD / 4.4BSD / FreeBSD hybrid.
Originally the idea was that having most of a BSD kernel running inside Mach would make it easy for researchers to run tools on their research kernel.
One suspects NeXT had a simpler motive: They just wanted to avoid paying money to AT&T. I'm not sure they had any particular interest in Mach itself. (Although obviously Mach's strange multi-architecture binary format paid off for them big time, some years later!)
> Can you imagine how cool it would be to manipulate Windows services from the WSL session?
It is a cool integration trick and might even be useful for some people like the author and their role with Azure. But it isn't remotely interesting for most WSL users who just want a local Linux to run containers in, or Linux tools, or just do server related stuff.
The goals of WSL2 compared to VirtualBox or HyperV are:
* Lower memory use
* Tighter integration with networking. i.e. it looks like it is running on localhost.
* Start/stops on demand, and much faster.
* (easier) file system integration. i.e. you can easily get to your Linux files from inside Windows.
So there actually are some points to WSL2.
For me personally I couldn't get Docker (actually its networking) to work properly via WSL2 so I'm still on a VM. But at least it works. VSCode's remote working feature is fantastic too in this situation.
That's exactly what I ended up concluding as well when I tried switching to WSL 2 because it added too much friction to the DX, whereas Docker Compose and the Docker VSCode extension kept things simple and scoped.
I didn't even keep WSL 2 as Docker engine because it doesn't forward filechange events from shared folders (which breaks livereload / watch mode), ended up going back to Hyper-V and it does exactly what I need.
I tried to use Windows Docker with the WSL2 back-end and the impression I got was that it was for people wanting to run scripts on windows which then run docker things. What I just wanted was scripts running on Linux which then did docker things. The whole mix of two operating systems was just complexity and problem I didn't want.
I just run vanilla docker inside a Linux VM and everything works as expected now.
Looking forward to the next LTS version of windows 10 that can support WSL2. As of right now WSL2 only works on Windows 10 versions 1903 or newer so it's a no go on LTSB/LTSC.
Thank you for your work on this project. Although like the author I have some reservations about moving to a virtualization-based approach, nonetheless I am grateful attention is being paid to these kind of technologies at all. WSL has totally changed my development workflow for the better.
I'm so glad you're enjoying it! And yes we totally hear the community's reservations about moving to a virtualization based approach and we take this into account as we plan the next overall steps for WSL :)
Quote:"...or, god forbid, suffer through the ancient CMD.EXE console". What's wrong with cmd.exe? It's a good tool
Quote: "and the fact that WSL continues to be separate from the native Windows environment shows. Even though I was quite hopeful, I cannot use WSL as my daily driver because I need to interact with “native” Windows tooling."
You do know CygWin exists, yes? Quite good and get this, exists from the moment Win95 came to existence.
This is the first time in a long time I've heard anyone refer to cmd as a "good tool". It's a legacy from DOS. Not in the literal sense of course but in the sense of the builtins, syntax and the horrendous BAT.
Mind you DOS had a lot of fans even in the late 90's/00's so of course it had its advocates. But they are much rarer nowadays.
Conway's law means were going to end up with quasi-microkernels.
- See google doing networking and other stuff in userspace to work around lazy phone manufacturers for Android. (And also for servers for entirely different reasons.)
- Imagine vendor lock-in^2 where my app only runs with Linux and Windows via WSL!
- NT and XNU are already that way, probably in-part due to Conway's law
- Various "serverless" cloud gambits will chop things up in different ways
- Maybe the Fuschias of the world will want a WSL too
When working on Windows I often use the verion of bash which comes with git. It's obviously not at all the same as WSL, but it gives you a lot of the feel of using a Unix machine while working in windows. The command-line tools work properly, for example.
I see others are offering similar comments, so I'll stop there. Try bash; it's ok in many cases.
It's cool, but warning that it treats variables differently. For example if you run an EXE command-line tool which looks for Windows environment variables, it won't use the Bash environment variables. Probably not a huge deal, just a gotcha we've hit at my company which caused a lot of wasted debugging time.
WSL1 was nice and idealistic, but WSL2 is a better fit for how people actually want to use WSL (IMHO): Linux as essentially a Windows app. You could get this before with VirtualBox or some other VM, but now it's more tightly integrated, with built-in filesystem sharing, and Linux distros distributed through the Windows Store.
Can somebody explain why he doesn't get the best of all worlds just running Wine on bare-metal Linux? Sure, he's obliged to run those programs, but that's table stakes. Other than those, it's Linux from here to the bank, and those processes show up in ps output with right numbers even.
That is a manifestly false statement. E.g., the whole MSYS system is cross-compiled, and tested on Wine.
Of course, programs would still need QA on real windos, and OS bugs they tickled would not be reproduced. But running them in a VM, with the file system exposed via Samba, would tickle the OS-interaction bugs. Those runs wouldn't show up on ps.
True, mgmt might look at him funny. But in my experience they do anyway.
> Can you imagine how cool it would be to manipulate Windows services from the WSL session?
This was a little confusing, in some ways, because it came right after "being able to list out processes to kill". A Windows Service is a lot like a `systemd` service.
In the scenario he envisions where you could see windows processes within WSL[0], it'd be possible to write a script that could invoke the windows-equivalent command to stop/start services and print `systemd`[1]/Windows services side-by-side, but you couldn't make Windows services "work" with `systemd` tools. Somewhat obvious, probably, but it caused me to raise an eyebrow for a second so I thought I'd mention it.
[0] Was it this way in WSL1? I don't remember, it's been too long.
[1] Last time I used WSL2, I ran openSuSE Leap; not sure what the default ships with.
In WSL1, you can't see windows processes in 'ps' or '/proc/[pid]' as if they were linux processes, but you could just execute the Windows tasklist.exe/taskkill.exe binary instead and parse the stdout. Actually, you could do the same with WSL2 also.
Correct me if I'm wrong, but this article makes it sound like WSL might be taking notes from WINE. It's Not an Emulator, because that would be slow and error-prone. Instead, it finds a way to abstract the appropriate functionality within the existing system.
Talk about irony. But I share the author's desire to see WSL share resources transparently between the W and the L. USB serial devices are a good example: it took forever for WSL1 to sort of support them, and it's still spotty with WSL2.
This is an area where WSL could be very appealing: many embedded workflows rely on one or two legacy Windows applications, but most of the core tooling works fine in Linux. But if you can't easily pass your USB debugger between OSes, you can't easily split your workflow across OSes.
> Can you imagine how cool it would be if you could type ps or top within a WSL session and see Linux and Windows processes side-by-side, able to mutate their state with kill
No, that could not reasonably have been. The underlying NT kernel seeing all processes, whether Win32 or WSL, is one thing, but the psutils in the Linux world being able to see non-Linux processes doesn't make any amount of sense.
kill works by sending signals. This makes no sense to processes that are not in the Linux domain.
I tend to agree with the article. What does WLS2 provides that a regular VM (VirtualBox for example) doesn't? Or a Docker container that I run with "C:" mounted as a volume?
Better performance, easier to use if you're just using command line stuff, first-party support. Docker's own docs state that it's better to run containers on the WSL2 backend than the old way (a hyper-v vm just for Docker).
Flip the question the other way: what does VirtualBox offer me that I'm not getting from WSL2? I just need Linux command line tools for software development. This feels like the best way to get them on Windows.
It's easy to imagine use-cases when a full blown VM are better; not my current use-cases though.
Ease of use and ease of setup - both of which are important. If I want to setup an Ubuntu VirtualBox, I have to download the VirtualBox software, find the Ubuntu ISO, and run through the setup process. Then I've got to work through any quirks with the setup to get it working seamlessly within the larger windows environment.
With WSL? I hit the install button on the windows app store. That simplicity is important and vastly increases the immediate utility of something like WSL, especially if you just want to try it out.
WSL launches near-instantly, consumes few resources, runs programs very fast, has seamless access to my Windows drive, etc. It's nice and light where a VM is bulky.
It does everything I want as a Linux terminal on Windows. I'm completely indifferent to the stuff mentioned in this blog post, as I'm not a Windows sysadmin.
Totally agree with this post. I use WSL1 quite a bit, and it brings many of the things I love about working on the mac to Windows. I do hope MS does continue to support it as promised.
Unfortunately it lacks Explorer integration although the command line client works well. SFTP integration in Explorer is one of the few big weak points remaining for Linux interoperability.
why would you need that if you have the command line functionality already? Windows has shipped with sftp for a while now. about the only think missing is a stand alone ssh client on the windows side but for that there is putty.
Ah my apologies, I thought you were looking for a native windows client version of tmux to go along with the native client ssh. I see you are looking for a server side implementation though.
OpenSSH both client and server has been a Windows feature for sometime in Windows 10 and the client has been auto-enabled in Dev Mode for slightly less but nearly as much time. (It's the OpenSSH Client provided as a Windows 10 feature that also provides sftp now.)
Exactly, especially when one of the few things Windows does a lot better than linux (at least historically) is the seamless integration of multiple video cards for having many screens which allow for more graphical interactions
It would be nice to be able to mount a remote linux data share as a drive without using SMB due to all the EternalBlue Ransomware issues. Having that convenience in windows file explorer like nautilus would be helpful for people who aren't necessarily power users.
Example: Linux local filesystem performance mostly derives from the dentry cache. That cache keeps a parsed representation of whatever the filesystem knows appears on disk. The dentry cache is crucial to pretty much any filesystem system call that does not already involve an open file, and IIRC many that also do. Problem is, that same cache in WSL must be subverted because Linux is not the only thing that can mutate the NTFS filesystem - any Windows program could as well. This one fundamentally unfixable problem alone is probably 80% the reason WSL1 IO perf sucked - because the design absolutely required it.
Solutions are rip out a core piece of kernel functionality, and in the process basically taking over ownership and maintenance for ALL code anywhere in the kernel assuming the existence of said cache, engineer something that is somehow better, and support this in perpetuity, including any semantic mismatches that turn up much later that were never designed for
The idea of merged ps output where Windows binaries would show up in the Linux /proc. How would you even begin to implement that without confusing EVERY process management tool ever written that interfaced with /proc? What about /proc/.../environ? On UNIX that has no character set. On Windows it is Unicode.
A trillion problems like this made WSL1 a beautiful nightmare. Glad it was tried and from watching the tickets, that team bled heroically trying to make it all work, but ultimately, I'm also glad it's gone, because the replacement is infinitely easier to engineer, maintain, and use, and that team earns its quarterly bonus much more easily. Everyone wins, except the astronauts, but as experience teaches us they never do.