[PATCH] Visual C++ 2008 Related Patches

["Rob Nicholls" <robert () everythingeverything co uk>]

Good catch! The x64 file is for "Visual C++ Libraries required to run 64-bit
applications developed with Visual C++" so we should only need the x86
version.

I can write a much simpler patch (attached) that just runs the x86 version.
I can't see many people not having WI3.0 installed, if they don't then I'm
sure this mailing list will be able to point them in the right direction.

I tried copying the two DLLs that I saw listed in depends.exe:

MSVCR90.DLL
MSVCP90.DLL

But when I ran it on XP (without the runtime components installed) I got:

"The system cannot execute the specified program."

After installing the 2008 runtimes using Microsoft's setup file, Nmap worked
as expected (even after deleting the DLLs from the folder). Therefore, I
don't think we can get away with dropping the files into the Nmap folder,
presumably down to the "side-by-side" stuff to help protect Windows from
"DLL hell". Unless anyone can correct me/find a way to do it.

For reference, OpenSSL appears to take roughly 3 minutes to compile on my
laptop (2.2GHz Core 2 Duo). I think it'd be slow and potentially fiddly to
compile at the same time as it compiles Nmap: you need to install Perl, and
depending on which batch file you run you may need other files too (e.g.
do_masm appears to use ml.exe, which I have in the VS.NET 2003 bin folder,
but doesn't appear to come with VC++ 2008 Express Edition; do_nasm requires
nasmw.exe that is easier to get hold of). It looks like do_ms works okay
with VC++ 2008 Express Edition.

According to INSTALL.W32:

"If you want to compile in the assembly language routines with Visual C++
then you will need an assembler. This is worth doing because it will result
in faster code: for example it will typically result in a 2 times speedup in
the RSA routines."

I think it would be best if we continue to compile OpenSSL ourselves
(perhaps switching to one of the ASMs at some point). I can't see us
updating OpenSSL too often, but I can see us recompiling Nmap quite
frequently, and it would dramatically increase the time taken.

I also think we should use /MD when compiling Nmap if we want to avoid
potential problems linking to OpenSSL. Not that I've spotted any problems so
far. I've attached a patch with the updated *.vcproj files that use /MD (as
an aside, is there any specific reason why liblua doesn't use /GS?). If we
use /MD then the resulting files will be slightly smaller (I can get
nmap.exe down to just 1.01MB), which might help slightly offset the 1.73MB
vcredist_x86.exe file.

It still makes the zip considerably larger* (the final attached patch copies
the x86 version specifically instead of using the wildcard), but I'm not
sure there's a way around it, except perhaps a link to the x86 installer at
Microsoft's site.

* I reckon about 3.64MB vs Nmap 4.65's 2.06MB zip.


Rob

Attachment: nmap-installer-2008-x86.diff
Description:

Attachment: nmap-mswin32-makefile-vcredist_x86.diff
Description:

Attachment: nmap-md-vcproj.diff
Description:

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org