Hacker News Reader

Comment by finaard | Hacker News Reader

While I understand _why_ they did WSL2 it's pretty sad that they at the same time they just dropped any WSL1 development.

We're using a lot of WSL in CI - we're mostly Linux based, but for some stuff toolchains came up which didn't work nicely with wine (like MSVC). So for us we want a Linux system that seamlessly can execute Windows stuff in a Linux based build process. WSL1 can do that, WSL2 can be kicked into working somewhat, but needs quite a few ugly workaround as they're not sharing a process namespace or file descriptors. While the faster IO would be nice that's pretty much the only thing we'd care about - and wouldn't work here, as we need shared access to the files. And while we could access the WSL2 files from Windows side that's even slower than just using WSL1.

View on HN

Windows files are still available via /mnt/c on WSL2

As WSL1 runs on the same kernel I have stuff like named pipes available. I can fully mix processes from both worlds in one workflow. _Some_ of that works with WSL2 as well, but as it's processes on two different kernels requires hidden workarounds to make that work - and not everything is working (and may be even possible).

Why would you want to mix Windows and Linux processes into one workflow on the same host?

I’m sure you’ve encountered a very niche problem that requires it, but I cannot think of any scenario where that kind of behaviour would be desirable vs splitting those workflows up.

Are you not able to have separate Windows and Linux hosts (eg VMs or containers) that are instigated to run in parallel as part of the same pipeline, but don’t rely on the same processes running in the same host?

Or at the very worst, use a TCP/IP based RPC to share state between the different hosts?

We're using OBS for building stuff (and heavily abuse it for the Linux side already) - a few things (like reverse dependency builds) make that more useful that most of the other stuff out there on complex projects. So when the requirement for some Windows builds came along (which are tiny compared to all the other stuff we're doing) we just ended up using WSL to have Windows workers in OBS. Also has some other advantages with how our cmake builds work (short version, developers can do their own bit in visual studio, and then a bit more checks run on CI where we can reuse the usual stuff without caring about Windows)

What’s OBS? I’ve only seen it in reference to the video streaming (et al) tool. Guessing that’s not why you’re talking about here though?

The Opensuse Build System. It's pretty good at figuring out if something needs rebuilding, so in some cases violating it and making it do stuff it's not supposed to is a sensible choice.

For MSVC, have you explored using clang-cl as a drop-in replacement?

https://clang.llvm.org/docs/MSVCCompatibility.html

https://llvm.org/devmtg/2014-04/PDFs/Talks/clang-cl.pdf

XWin for the CRT/SDK:

https://github.com/Jake-Shadle/xwin

https://jake-shadle.github.io/xwin/

A while ago I got some Python C extension modules building using this approach, but didn't push it any further.

That'd mean we have a different compiler in CI than what the developers use on their workstations - which is not a good thing. And wouldn't be tolerated there anyway - people already had some doubts when we were wrapping IAR with wine and a bit of shell to look like a standard UNIX toolchain.

(Shout-out to IAR, though. I still think they're overpriced and you don't really need them - but if you're stuck with them their support is excellent. When an update broke license handling in our setup they didn't tell us to go away like any other vendor would've done for that kind of wildly unsupported use case, but actually made it work again in the next release. They also got us access to native Linux binaries way before they even were talking in public about working on that to play around with for our CI)

Reply on news.ycombinator.com