Proposal: Adding Windows compatibility for hyperscan

[steven-t-murphy]

Hello,

Our team has been working on a project that required Hyperscan to be compatible with Windows. We modified the setup.py and created a script to enable successful builds on Windows, and we are now using Hyperscan on both Windows and Linux platforms.

We would like to contribute these changes back to the community. However, we understand that our approach may differ from the Hyperscan team's methodologies or preferred implementation practices. With that in mind, we wanted to ask the following:

Is Windows compatibility a desired feature for the Hyperscan repository?
Would you be interested in our contribution to enable this functionality?
Are there any specific guidelines or concerns we should consider before submitting a pull request?

We are excited about the possibility of helping make Hyperscan more accessible to a broader audience and look forward to your feedback.

[darvid]

thank you for reaching out. I think Windows support would be great to add, my comments below:

Is Windows compatibility a desired feature for the Hyperscan repository?

absolutely, though I'm wondering if you're leveraging the older versions of this library that were using Intel's Hyperscan, vs the latest that uses Vectorscan? I don't really see an issue either way (especially if Vectorscan doesn't work for some reason on win32, I haven't looked into it), just want to make sure there are no licensing issues.

Would you be interested in our contribution to enable this functionality?

yes please. 🙏

Are there any specific guidelines or concerns we should consider before submitting a pull request?

some considerations OTOH:

• it would be ideal (but not absolutely necessary if it's too complex right now or you don't have resources) to have working CI/CD via GH Actions, so it can be cross-compiled etc. the current release process is largely automated and leverages manylinux wheels and cibuildwheel. looks like win32 builds are supported, I'm not sure how much/if any configuration is required to get it working. possible build time considerations that I had to handle for linux/darwin that I can think of:
  • chimera support - need to build PCRE out-of-band, and ragel, rather than using system packages.
  • static linked libs possible? guessing this isn't that much of a problem on win32 but I could be way off.
  • multi-arch?
  • the runner will likely need substantial amounts of configuration. for linux I'm using third party runners I believe, due to GH's publicly available runners being much slower, especially for actions that require building binaries. unsure if there are similar alternatives for win32 runners, or if GH's runners are perfectly fine. would need investigation
• do you anticipate actively contributing bugfixes/features/updates or having ownership of the win32 support? because if so, I would be happy to make you or someone on your team maintainer.
• the only contribution guidelines that would be a nice-to-have is following conventional commits, as that drives the CHANGELOG generation and semver incrementing/release process. but not really married to anything, it was mostly to save me time during the release process, but releases don't tend to be super frequent. whatever works best for you.

thanks!

[steven-t-murphy]

Glad to hear that Windows support is a welcomed addition, and thank you for the detailed feedback!

We’re using the latest version of the library with Vectorscan, all of our initial (extensive) testing showed comparable performance on the win32 platform. Regarding CI/CD, we’d be happy to integrate with the existing GitHub Actions setup. We'll need to dig into the specifics of build speed and cross-compilation, especially with lessons learned from macOS and Linux, but we’re optimistic about finding a workable solution.

We’d also be willing to support bug fixes and future updates in some capacity after the initial implementation. As for following conventional commits for the changelog and release process, we can definitely accommodate that—it’s no problem at all.

Looking forward to collaborating further on this!