Rez on WSL for windows

[Blazej Floch]

Windows is a huge headache for us ... still.

Did anyone try to run rez on WSL?

Sounds like a perfect candidate as from my limited understanding one would not suffer from the command prompt shortcomings.
Still it can perfectly launch windows binaries.

Any thoughts or experiences anyone might want to share?

[Alex Widener]

I personally would not want to try this out. WSL is a highly mutable, highly uncontrollable, evolving system, and Microsoft can update it as it sees fit at any point without warning - relying on something as important as Rez to run on WSL gives me the heebie-jeebies. Sure, a large IT infrastructure may be able to defer updates for you, but I'm sure we've all fallen victim to Windows' forced updates at one point or another. In my view it's not worth it.

If you're just not liking cmd.exe (as you shouldn't), my advice would be to use a combination of cygwin/babun/cmder instead of relying on WSL.

[Christian]

I've briefly tried rez on Debian9 on WSL on a Windows 10-1803 prerelease (has WSL improvements, should be out this month). I basically tried the steps from the quickstart docs (including building the "helloworld" binaries with cmake/gcc/g++) and played around with it a bit. I was surprised how flawless and fast (performance-wise) everything worked.

I think rez in combination with WSL could get used for two purposes (which could get mixed with each other):

- creating packages with native ELF64 binaries to run them on Windows systems (they could even be the same binaries that you run on native Linux systems through rez). rez could be running either on Win32 or on WSL Linux, depending on your needs/environment. (So you could i.e. utilize an existing rez installation on Win32 to run Linux binaries on WSL)*

- starting Windows executables out of a WSL rez environment*

*(It is possible to start Windows executables from WSL Linux processes, Linux executables from Win32 processes and pass env vars [1] between both)

I think WSL is a powerful Windows Kernel feature if you understand its purpose and limitations. Basically the Windows kernel provides a subset of the Linux Kernel's ABIs, allowing you to present the Windows kernel any ELF64 Linux root filesystem ("distro") and it will natively execute any ELF64 binaries in it. So the big advantage over Cygwin is that you don't need to compile your executables for Win32. You can use those that i.e. are served by a Linux distro's package manager. The major tradeoff is that the Windows Kernel only provides some of the Linux interfaces and no one knows how complete/well-written they are, introducing new bugs in executables. With cygwin and MinGW you're using native Win32 binaries, that depend only on some additional interfaces provided by cygwin or MinGW. Basic usermode commandline applications on WSL have been working well for me so far - everything else not at all. GUI stuff only works through a separate xserver running on Win32.

While the concept of WSL might sound like "must be buggy", I've personally had more pain with missing or heavily outdated cygwin packages than with (simple) Linux executables having issues on WSL. So I wouldn't see it as "either cygwin or WSL". Both can be the right tool to solve specific "Unix problems on Windows" and could even get mixed with each other.

[1] https://docs.microsoft.com/en-us/windows/wsl/interop