[3.0.0 prep] Windows runtime dynamic loading - #416
Conversation
66e2e0b to
a46020e
Compare
a46020e to
cc42d32
Compare
cc42d32 to
a4c8ad4
Compare
|
@Wojtek242 let me know your thoughts on this one. |
Wojtek242
left a comment
There was a problem hiding this comment.
Apologies for the delay.
Looks good, but I am confused by the requires_library method. I understand why you would want to build pcap without build-time linking, but isn't a library required at runtime anyway making a requires_library call sprinkled throughout the call a bit redundant?
What I'm worried about is that as you seem to have implemented it adding a requires_library call requires a good understanding of where to place it making it vulnerable to future mistakes. Is it possible to either not have it or centralise it in one place so that it's called once and that's it.
|
I am trying to allow a binary built against the crate now starts on a machine with no Npcap installed, and
The easiest is to shrink the surface by routing Or, I can split the FFI declarations into two groups and give the handle-free group a leading Feel free to decide and I can adjust then. |
I like this option. It makes the assumptions clear to the next programmer. But if it starts getting too clunky/ugly feel free to push back and try the other option you suggested as well. |
|
I made some changes, let me know if this is fine or not. |
|
Thanks for the update. LGTM |
This PR removes the SDK dependency on Windows, which unlocks cross build and fixes several other issues (#408 will be rebased onto this PR once merged).
Tested with winpcap 4.1.3, npcap 1.00~1.89.
UN*X behavior remains unchanged, tested with libpcap 1.10.7 and 1.11.0.
Fixes #246, #396.