Performance was one problem, but imho the biggest was that MMAP semantics were inherited from the NT side and made a lot of applications crash (mmap's created could only be as large as the file's current size as in Windows, while Linux/BSD semantics allows for a mmap larger than the file that's usable without constant remapping as the file grows).

They didn't prioritize it until fixing at a late stage, barely before WSL 2 came out. Sometimes i do wonder if they made a premature decision to move to WSL2 since there was quite a lot of basic applications/runtimes that were crashing due to this fix lacking (Naturally a lot of other new Linux API's like io_uring probably would have made it an api chasing treadmill that they just wanted to circumvent).

> (mmap's created could only be as large as the file's current size as in Windows, while Linux/BSD semantics allows for a mmap larger than the file that's usable without constant remapping as the file grows).

I thought you could do it using ntdll functions, no?

https://www.jeremyong.com/winapi/io/2024/11/03/windows-memor...

Good to know, still the obscureness of this function or semantics led WSL1 to be incompatible for a long time (Also skimming this article touches upon some 0-sized mappings being an issue?).

Regardless this led WSL1 to have fatal incompatibilities for a long time, iirc basic stuff like the rpm system or something similarly fundamental for some distros/languages relied on it. And once WSL2 existed people just seems to have gone over.

Hm. I used Git on WSL1 for many years, with medium sized repos hosted on a Windows drive, and it worked great. When I moved to WSL2 Git became a whole lot slower - it now takes about 5-8 secs to execute 'git status' where before it was instant.

Are your git repos in ntfs? WSL1 Linux drives are slow and in WSL2 Ntfs.

Yes, exactly, this is well known. So the parent post seems incorrect.

Win32 APIs like CreateProcess suck because they have to spend so much time setting up the stuff that allows Win32's application model to mimic that of 16-bit Windows, which was coopreratively multitasked. The NT kernel is much faster at creating processes when it doesn't need to worry about that stuff.

As for NTFS: it's not NTFS specifically, it's the way the I/O system is designed in the NT kernel. Imagine any call from outside that layer transitioning through a stack of filter drivers before actually reaching the implementation. Very powerful stuff, but also very bad for performance.

> Imagine any call from outside that layer transitioning through a stack of filter drivers before actually reaching the implementation.

Linux BPF programmers say, "hold my beer, watch this!"

They can code 12 BPF filters for the price of 3 Windows filters.

Windows actually created a new process type for this: Pico processes[1]. This allows WSL1 to perform quite a bit better than Cygwin on something like Windows XP.

1. https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-pro...