I really don't want to start up a separate Linux VM just to open up a shell. (I already crossed out Cygwin / MSYS on the list because of performance issues...)

Also, I need to compile actual Windows binaries using the shell (MSVC, clang-cl), and I obviously can’t do that under a Linux VM.

MSVC's command line tools kick off just fine from shell scripts running under WSL2. Much to my surprise. I assume it doesn't run in the VM.

Busybox for Windows has a very accessible shell.

Yeah, I've used that before. But it was a bit too minimal for my tastes.

WSL is great but it’s basically a convenient VM. It’s no longer windows, as far as I’m concerned.

It’s a lightweight Hyper-V VM, just like Windows itself when you turn Hyper-V support on (boots hypervisor first, then the Windows VM in the root or parent partition)[0].

But if that’s an issue, WSL1 is still an option.[1] It’s a thin translation layer between Linux kernel calls and NT kernel calls, which was the original concept of subsystem from the early NT days which allowed OS/2 apps to run on top of ntdll.dll.

WSL2 didn’t replace WSL1.

[0] https://learn.microsoft.com/en-us/virtualization/hyper-v-on-...

[1] https://learn.microsoft.com/en-us/windows/wsl/compare-versio...

It’s not an issue, in fact as a Linux fan it’s magnificent! However it is not windows so if you want to use it for windows stuff / software development there’s going to be some edge cases, performance penalties and hiccups. So long as you stay inside the WSL2 VM and filesystem it’s fantastic.

Also WSL1 was a subsystem in the NT kernel but WSL2 is not like this - it runs a separate Linux kernel, with some convenient integrations. WSL1 never did support all the features - I recall I had to use windows .exe executables for some software packages that do have apt-installable packages.

> WSL2 didn’t replace WSL1.

It kind of did, IMO. You can still use WSL1, but my understanding is that it's a dead end; MS has given up on the translation layer approach. WSL1 will still get bugfixes but it seems pretty clear that WSL2 will get the lion's share of investment going forward.

It's literally a subsystem. It's integrated in many ways you would not use to describe a "VM". I don't understand the aversion nor the confusion.

Here’s an example: if I build a Python app with PyInsyaller (which can’t cross-compile), and if I want a Windows executable, I have to build on Windows, not WSL, which defeats the whole purpose of “bash on Windows” because now at best I have to use Cygwin or Powershell or something and deal with a completely different environment.

You can run windows programs from whatever Linux shell (in WSL) you want, because the Windows filesystem is mounted and Windows executables run in the Windows environment.

OTOH, if you are doing anything complicated, it gets weird because (e.g.) file paths have to be passed as windows paths to windows programs, not using the linux mount path that you would access the path from in linux. But, you can, in principle, use a Linux shell in WSL to run Windows PyInstaller to build for Windows.

I thought since WSL2 it’s just a Hyper-V VM with some nice upfront configuration (like mounting all windows disks)?

I'm pretty sure Windows itself, as in your desktop, runs virtualized under many circumstances; and nobody seems to complain about Hyper-V then.

And to be clear, WSL2 is very much integrated into windows via the filesystem and networking. I like to think of the networking more akin to docker than anything else.

It can also cross-run programs and UIs. I can type in `code .` in my Ubuntu image, and VSCode will open in Windows at that directory. I can also run UI programs in Ubuntu and their windows pop up in the Windows desktop environment.

While the «code .» integration is great, it’s running as client-server. You can do similar development over ssh to another vm or physical machine, too.