mailing list archives
Re: [PATCH] Visual C++ 2008 Runtime Components
From: Fyodor <fyodor () insecure org>
Date: Sun, 15 Jun 2008 19:51:24 -0700
On Sun, Jun 15, 2008 at 04:40:20PM +0100, Rob Nicholls wrote:
The first patch updates Nmap's Windows setup file to silently install the
correct version of the Visual C++ 2008 runtime components, which are
required by Nmap.
Thanks Rob. This looks like a good option. Though I must admit to
being a bit concerned about the size and the need for another
installation dependency. Even after zip compression, these files add
about 4 megs. So the Windows package sizes would likely change as
nmap-4.65-setup.exe 13,702,065 -> 17,849,638 (+30%)
nmap-4.65-win32.zip 2,166,483 -> 6,314,056 (+191%)
Nearly tripling the size of the .zip (and making those users deal with
having to install the right vcredist) is a tough pill to swallow. It
isn't the end of the World, but would be nice to avoid if we can.
What if we set up the Nmap build system to compile OpenSSL at the same
time as it compiles the rest of the code? How hard would that be?
Would that solve all the known issues, and also remove the need for
these vcredist? How long does OpenSSL take to compile?
From reading Jah's email at
http://seclists.org/nmap-dev/2008/q2/0560.html , it sounds like the
problem occurs when mixing /MT-compiled libraries with /MD ones. But
it seems like we would still have that issue if we don't also change
Nmap to use /MD.
It is interesting that the 64-bit vcredist is needed. This is true
even when installing an Nmap which was compiled for 32-bit? Does the
32-bit vcredist refuse to install on 64-bit systems?
Another option might be to ship just the DLLs we need (as we're
apparently doing with Zenmap). Though that might come with its own
troubles (perhaps with respect to handling the 64-bit dlls).
Another option is to just include the x86 vcredist with the .zip file,
and give a URL for the 64-bit version when people need it. Can Nmap
easily detect a missing vcredist and prompt the user to download +
Anyone have ideas as to the best way to handle this problem?
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org