Well, yes and no (since you ask about several different types of binaries).
Yes, assuming you are using an x64 Linux system, the binaries are identical between the two systems. You can actually take a drive directly out of a physical Linux machine and either:
- Create a tarball of the system which can then be imported into WSL
- Or just
chroot into the filesystem on that drive (and this has been done).
There is no "conversion" or change made to the binaries in either of these tasks.
Note that, when booting WSL2 this way, you are running most of the binaries from the original distribution. However, the actual kernel and
init are provided by WSL2, so that it can bootstrap the Windows integration (e.g. ability to run Windows
.exe's, networking integration, and more).
Notably, Systemd does not automatically start. There are workarounds for Systemd support under WSL2, but it needs to run post-bootstrap, so that WSL's
init can do it's thing first.
On the other hand, no, (most) binary drivers that expect direct access to physical hardware will typically not work unless there is a virtual equivalent provided by WSL. WSL2 is running in a virtualized environment. There are a few exceptions, though ...
USB Device Drivers
It is possible, though, to get direct hardware access to USB devices in Windows by sharing them through USB/IP (from Windows) and connecting to them in WSL/Linux. For these devices, binary drivers will work.
The most recent WSL2 kernel release has USB/IP support included, but even prior to that, it was possible to build your own kernel with that feature enabled.
Recent WSL2 releases (Windows 11 and Windows 10 21H2) provide the ability to use the Windows GPU driver for WSL2 GPU Compute tasks. This allows Linux binaries which take advantage of GPU compute architecture (e.g. TensorFlow) to leverage the Windows GPU.
I can't speak to crypto-mining (and I doubt Microsoft's going to be pushing that), but I'd expect that it's now possible to use this architecture with those binaries as well.