I've recently been working on bringing various ecosystem components to Windows. Aside from CI still being a lot of work, the majority of libraries are all compiling and running on Windows now with PRs submitted containing these patches.
The only hurdle I came across on Windows is that zlib is not available on Windows by default. It's possible to download it separately through something like vcpkg, but users still need to manually tell the linker where to find these libraries. On top of that, they'll need to store zlib1.dll next to their .exe prior to running the compiled executable. Given the importance of zlib for protocol level compression among others, I think it's quite a tough problem not to fix in a more reliable way.
The main obstacle where I ran into this was swift-nio-extras, but I know many other libraries also link against zlib like swift-zip-archive and ZIPFoundation. It would be nice if we could have a solution that works reliably across more platforms including Windows.
I’ve done some exploratory work on zlib (RFC 1950) support in Swift with the swift-rfc-1950 repository. It currently provides basic zlib wrapping and Adler-32 handling around DEFLATE, though it’s not yet complete and will need improvements for production use. However, it does compile and build on macOS and linux, and CI shows it also builds on Windows.
If it would be helpful, I can invest effort to improve it (platform support, testing, API surface) so it could serve as a more robust basis for cross-platform zlib support in the Swift ecosystem.
Note that there is support in build-script, which builds the toolchain, for compiling zlib: that was added because it is a dependency of curl, which FoundationNetworking is built on for certain platforms. Unfortunately, Evan added those build config files more than three years ago, and then they were never used for anything in the public OSS builds, with most Swift platforms now building or including those curl/libxml2/zlib libraries in other ways, and the Powershell script build.ps1 for Windows has its own zlib config too.
If you want to include zlib in some more accessible form in the toolchain, perhaps in collab with @coenttb's work, you could just dust those existing build scripts off and start using them more, as I plan to for Android.
While we're talking about zlib, let's not forget and leave behind zstd if there is going to be any kind of special work around this.
zstd is way more cpu-effiecient. The efficiency difference usually-is/can-be noticeable in practice as well.
What about swift-nio-extras just vendoring zlib in its own source code? There's plenty of precedent (like llhttp, boringssl, FreeBSD's SHA1, Swift Profile Recorder vendoring the ELF symboliser ...) where NIO just vendors the code. This solved so many issues -- so I think should probably just do that here. When we originally made the call to just use the system's zlib, IIRC the call was that it's anyway available "everywhere" and wouldn't need a lot of manual updates because the code's very stable. Also I guess we knew the vendoring door would always be open.
Let's just do it? I'm pretty sure the NIO team would welcome a contribution or even just an issue requesting that. @lukasa WDYT?
Adds a c_nio_extras_... or similar prefix to all functions that create symbols (such that we don't clash with the system zlib or others that define functions with that name)
SPM doesn't really support dynamic linking today, and the zlib vendoring would just propagate more static linking perpetuating the code bloat that we see. I understand that this is the traditional route for server side programming with Swift, but this is definitely not a great model IMO (and definitely not what Windows tends to recommend for applications at least).
I belive that encouraging more shared libraries is the better thing to do here, most of which can be achieved by improving SPM to both build libraries and integrate with other systems. Of course, this is a longer term thing, and perhaps in the mean time, a package similar to swift-toolchain-sqlite with zlib is a good compromise.