Home page logo

nmap-dev logo Nmap Development mailing list archives

RE: Please help..
From: "Rob Nicholls" <robert () everythingeverything co uk>
Date: Fri, 13 Jun 2008 12:27:55 +0100

-----Original Message-----
From: 'Fyodor' [mailto:fyodor () insecure org]
Sent: 13 June 2008 04:19
If we start including the MS runtime as described in your previous
email, do you think the rest of Nmap should be changed to also do /MD
rather than /MT?

Someone more knowledgeable than me should probably answer that question. But
here's my two cents...

I believe using /MT can potentially make the code a bit faster and leaner
(as it doesn't waste time and memory with runtime library calls), and it
avoids having to distribute additional runtime libraries; but if we start
distributing the runtime library to avoid any potential problems with
OpenSSL then that only really leaves the first argument. There's also the
"if it ain't broke, don't fix it" argument ;-)

I just grabbed the latest code from SVN and noticed that the OpenSSL files
haven't been updated, so the two resulting DLLs still require msvcr80.dll.
Compiling Nmap with VC++ 2008 Express Edition using /MD causes a dependency
of msvcr90.dll and msvcp90.dll so we've got a mix of runtimes, which could
potentially cause trouble (although it appears to work okay, but would
require us to distribute both the 2005 and 2008 runtimes). If we recompile
all of the OpenSSL files using VC++ 2008 then everything would use the same
runtime (and I can update Nmap's setup file to install just the 2008
runtimes) and I think it'd be perfectly fine to start using /MD.

It looks like nse_bitlib.vcproj has always been configured to compile
bit.dll using /MD, so I'm surprised we haven't come across this dependency
problem sooner. Perhaps - because NSE crashes gracefully - XP/2003 users
without msvcr80.dll hadn't noticed?

I've just looked at zenmap.exe from the Nmap 4.65 installer and it requires
msvcr71.dll, but we've already been including it in the zenmap folder (it's
also required by Python's w9xpopen.exe in that folder). We could continue to
include the DLL this way; otherwise I think we have to compile our own
version of Python using VC++ 2008 (probably not an easy task, based on the
number of warnings and failed projects I just saw when I gave it a quick
go), and I can't say for certain that py2exe will like that. I vote we keep
the existing DLL approach (at least for now), especially as Zenmap is very
self contained. If it ain't broke, don't fix it.


Sent through the nmap-dev mailing list
Archived at http://SecLists.Org

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]