Thank you for your answers and for taking care of this. While building as a DLL might be useful, it's easy to plug the static lib into an existing project and build the DLL yourself, so I wouldn't consider it important. Regards, Timo -----Ursprüngliche Nachricht----- Von: Hyperscan [mailto:hyperscan-bounces@lists.01.org] Im Auftrag von Barr, Matthew Gesendet: Montag, 11. April 2016 09:08 An: Hyperscan regular expression matching library <hyperscan(a)lists.01.org&gt; Betreff: Re: [Hyperscan] Hyperscan build on VS / x86 From: Hyperscan [mailto:hyperscan-bounces@lists.01.org] On Behalf Of Timo Kreuzer Thanks for these - we haven't had a lot of interest from Windows users until recently, so fixing the 32-bit library had fallen off our radar. I'm in the process of working through these diffs, and should have some commits to push through to the develop branch soon. Some of the patches we can just apply, but for some I'll have to change a few things to work with all of our target platforms. Other issues have come up in testing on Windows, though, which I'm still working on. 64bit offsets are part of the API, as Hyperscan has to be able to support stream sizes that wouldn't fit in 32 bits. Also we must avoid using size_t for anything that might end up in a pattern database structure, as it may change size between 32-bit and 64-bit platforms. I did investigate our use of the u64a type, and as you pointed out, it does appear that forcing the alignment on Windows is unnecessary as structs are already 8-byte aligned. This isn't the case on other platforms, however. Changing our use of the type throughout the codebase is quite invasive, so in the short term we will probably just change the typedef for Windows builds. One question for you: at the moment we only build static libraries (.lib) on Windows, would it be useful if we added the ability to build Hyperscan as a DLL? This is another thing we haven't had demand for, so have delayed doing the work. Regards, Matt.