New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What Visual Studio version should *libpcap* make the minimum required version? #1465

Open
guyharris opened this Issue Feb 7, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@guyharris
Copy link

guyharris commented Feb 7, 2019

Currently, I've been trying to allow it to work with VS 2013, although I can't guarantee that I've succeeded there.

The npcap README.md says, as of the time I'm filing this issue, that:

The DLLs need to be built using Visual Studio 2013. And the driver needs to be built using Visual Studio 2015 with Windows SDK 10 10586 & Windows Driver Kit 10 10586.

Does "the DLLs" include the libpcap DLL (npcap.dll or whatever it's called)? If not, what VS version is it built with?

(If it requires VS 2015, including the VS 2015 runtime, or a later version, I can use snprintf() directly, and can use it to make an "generate a malloc()ed formatted string that's large enough" routine and use that in some places, as long as I kick to the curb some older UN*X versions of snprintf() with non-C99 behavior, which I'm willing to do.)

@dmiller-nmap

This comment has been minimized.

Copy link

dmiller-nmap commented Feb 8, 2019

First, this reminds me I need to pare down the Npcap README, since most of that information is duplicated in the Npcap Guide or obsolete.

"The DLLs" refers to Packet.dll (the Packet API) and wpcap.dll (libpcap API). However, we recently (Npcap 0.99-r9) switched to using VS 2015 for everything and it seems to be working just fine. Is there something in particular you'd like us to check on in the Npcap build process that might not have been handled well in the upgrade?

@guyharris

This comment has been minimized.

Copy link
Author

guyharris commented Feb 8, 2019

I hope you're not using anything from the Win32/Prj directory in the libpcap source, because those are not being actively maintained by anybody - the official way to build libpcap on Windows is by using CMake with the top-level CMakeLists.txt file and the modules under cmake/Modules and using the appropriate generator for your build system, e.g. the "Visual Studio 14 2015" generator (note that the generator name might also have to include the CPU target with CMake versions prior to 3.1), and then build with that build system.

Not all libpcap maintainers who might be modifying CMakeLists.txt in the platform-independent parts (consider, for example, the addition of TLS support to rpcap, which was done for all platforms or, at least, all platforms where you can get OpenSSL libraries, which includes Windows) have Windows, so it's unlikely that the Win32/Prj files will ever be actively maintained, unless somebody volunteers to make all relevant changes that correspond to CMake changes.

@guyharris

This comment has been minimized.

Copy link
Author

guyharris commented Feb 8, 2019

And, sadly, if I try generating for VS 14 on macOS, I get:

$ cmake -G "Visual Studio 14 2015"
CMake Error: Could not create named generator Visual Studio 14 2015

Generators
  Unix Makefiles               = Generates standard UNIX makefiles.
  Ninja                        = Generates build.ninja files.
  Xcode                        = Generate Xcode project files.
  CodeBlocks - Ninja           = Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
  CodeLite - Ninja             = Generates CodeLite project files.
  CodeLite - Unix Makefiles    = Generates CodeLite project files.
  Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files.
  Sublime Text 2 - Unix Makefiles
                               = Generates Sublime Text 2 project files.
  Kate - Ninja                 = Generates Kate project files.
  Kate - Unix Makefiles        = Generates Kate project files.
  Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.
  KDevelop3                    = Generates KDevelop 3 project files.
  KDevelop3 - Unix Makefiles   = Generates KDevelop 3 project files.

and I suspect the same will happen on other UN*Xes (except that the other UN*Xes might not support Xcode projects).

Furthermore, because the generated .sln files will depend on the results of tests done by CMakeLists.txt and stuff it runs, generating project files on any machine other than the machine on which you'll be doing the build doesn't make sense anyway.

So we wouldn't be able to ship .sln files generated by CMake.

@dmiller-nmap

This comment has been minimized.

Copy link

dmiller-nmap commented Feb 11, 2019

Thanks for the info. I will have to look into this further, but I think my answer still stands, then: we will do everything we can to continue building wpcap.dll (libpcap) and all the rest of Npcap with a single version of Visual Studio, namely VS 2015. I would much rather not go backwards to 2013, so do not consider us a limiting factor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment