Nmap Windows Czar

While Windows is the second most popular platform for running Nmap, that version is just not up-to-par with it's UNIX cousin. There are also Windows-specific building and installation features which could be added. This project will appoint someone as Windows Czar for the summer. They will complete the tasks described in this document, and possibly other Windows-related tasks that crop up. This is one of the project options for the 2005 Google Summer of Code Program -- see GoogleGrants.html for others.

Create a Windows installer

Currently, Nmap is only offered for Windows users in source format, and a PKZip file of the binaries. This leaves Windows users to manually perform a number of tasks to install Nmap properly. While this is powerful and flexible, many users would prefer an executable installer to do this work for them. This installer should meet the following requirements:

• It should be a free, open source based system. An example would be NSIS (formerly known as Pimp Installer) from http://nsis.sourceforge.net/. But there may be better ones out there. Take a look at what other major open source applications are using, see how well they work, and decide what would best meet Nmap's needs.
• It needs to handle checking for Winpcap and installing it if required. You may be able to just execute the WinPcap 3.1 installer and it might handle the checking work for you.
• It should do the Nmap performance registry changes described in README-WIN32 (maybe query the user before doing them).
• User should be able to specify where Nmap is installed.
• Ideally the installer should be built using a hand-editable text file, rather than something that requires a GUI to change or recreate.
• When new versions of Nmap are released, it needs to be easy for Fyodor to build an accompanying new installer. He should only need to do something simple, like run a makeInstaller script from the build directory.

Automated Build System

Create an automated build system for building distributable binaries and an executable installer for the Windows version of Nmap. Right now, for every new version of Nmap, Fyodor has to manually open Visual Studio, perform the compilation tasks described in http://nmap.org/data/README-WIN32 , then open up a Cygwin shell and manually create a zip archive containing all of the appropriate files. And of course no self-installer exists at all yet. This should be automated so that Fyodor only has to run one command (preferably from the command-line) to perform these steps. Requiring Cygwin is OK. Compilation should still be done with Visual C++, unless you can demonstrat the g++ (or whatever) creates Nmap binaries that are just as good or better on Windows. Compilation from within Visual C++ using the "build" command should still work fine. Changes to compilation rules (such as adding a souce file or library) should only need to be made in one place (e.g. from the Visual Studio GUI or in a text/make file.) Not both. The results should be a convenient packaged nmap-VERSION-win32.zip and nmap-VERSION-setup.exe, ready for distribution.

Code changes

In addition to the build system and installer, there are a number of ways that the Nmap Windows code could be improved to better compete with the UNIX version. Here are some ideas:

• Make localhost raw scanning work on Windows, if possible. At a very minimum, insure that users get an appropriate error message if they do this.
• Reliability tests -- try some large-scale network scans and watch for crashes or other bugs. Track them down and fix 'em. Try running it under an automated bug finder, such as Insure++, Purify, and/or Valgrind then fixing any real bugs discovered.
• Performance testing -- large-scale scanning may also help in performance benchmarking. Try changing compilation flags and source code changes to speed it up. Maybe run it under a profiler.
• Performance: Windows TCP connect() scan may be limiting itself to too few sockets, because it looks like max_sd() always returns zero for Windows. Investigate. Maybe should be limited it to 9 due to the new SP2 limitations.
• Fix Windows-related bugs reported by Nmap users during the period.
• Fix problem that causes Nmap to quit on Windows platforms when one of the targets is a broadcast or network address. Nmap should act like it does on UNIX, which generally treats a broadcast address no differently than any other. If Windows absolutely refuses to let you send packets to such an address, the host should be skipped rather than Nmap crashing. But you probably just need to set an appropriate socket flag (like SO_BROADCAST on UNIX). For an example, try scanning 192.168.0.0 on a 192.168/16 net.
• Separate nbase into its own library on Windows and UNIX.
• Clean up winclude.h and mswin32/winclude.h. It probably shouldn't be doing ugly stuff like #defining read(). We'll have to talk about what to do here.