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?
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.
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).