The technical requirement of installing WSL before installing our software was already a non-starter, since most Windows users expect one installer or zip to do-it-all. WSL2 isn't (yet) like a C/C++/DirectX redistributable which can be plugged in as a dependency to a given program. Additionally our program is expected to work natively with Windows paradigms.
More critically, we work with high-performance filesystems. The performance impact of files going a round-trip through the Linux Plan9 driver, then through a Linux kernel context switch, into the kernel, and down into Hyper-V, and then up back through the Windows Plan9 driver was completely unacceptable. It was deemed worthwhile to rewrite targeting Windows natively. And even then it was only a partial rewrite: we ended up using MinGW because we had too much of a direct dependency on the pthread API.
Forcing Windows users to use WSL is generally a non-starter. That’s just not how things work. You can force someone to change their entire execution environment without further consequences.
If you only support WSL then you don’t support Windows, imho.
I see were you are coming from, but programs also depend on an SQL server, a python installation or a Java instance. You also don't complain about device drivers, support for filesystems, the network stack and hooks to Windows Explorer.
In the end it is just part of the OS and a bunch of extra userspace programs. I mean nobody complains about the Windows Subsystem for Win32.
But yeah, you can just use a non-MS GNU/Windows implementation instead, do you like that better?
Is it possible though? Is it possible to have isolated WSLs (per programm)?
> Is it possible though? Is it possible to have isolated WSLs (per programm)?
Maybe. But my experience is that there is very little “program code” and it’s mostly “library code”.
And if you did have a program that required WSL and you followed the UNIX model of bash chaining programs then you’re now mandating the “meta program” be run under WSL.
I treat WSL as a hacky workaround for dealing with bad citizens. It’s not a desirable target environment. It exists as a gap stop until someone does it right. YMMV.
wsl also has the issue that when windows decides to auto update and there is a wsl update while there is a wsl instance running, it will just kill it right there and then to carry on with the update.
This has bitten me once when I was doing a distro upgrade and windows just killed the WSL vm midway.
Even if I now MS Windows can be annoying (why I don't use it), I'm completely out-of-touch with the hoops MS Windows user have to jump to have a usable computer. This is kind-of also a disadvantage, because you can't anticipate bugs that you can't imagine.
The technical requirement of installing WSL before installing our software was already a non-starter, since most Windows users expect one installer or zip to do-it-all. WSL2 isn't (yet) like a C/C++/DirectX redistributable which can be plugged in as a dependency to a given program. Additionally our program is expected to work natively with Windows paradigms.
More critically, we work with high-performance filesystems. The performance impact of files going a round-trip through the Linux Plan9 driver, then through a Linux kernel context switch, into the kernel, and down into Hyper-V, and then up back through the Windows Plan9 driver was completely unacceptable. It was deemed worthwhile to rewrite targeting Windows natively. And even then it was only a partial rewrite: we ended up using MinGW because we had too much of a direct dependency on the pthread API.