Consider moving Npcap (and then perhaps Nmap) installers from NSIS to MSI

[fyodor]

This needs further research, but we are adding this issue to track our existing knowledge on this topic and to invite anyone else to comment if they have feedback about pros/cons, implementation ideas, potential obstacles, etc.

Nmap and Npcap currently use self-executable installers generated by NSIS (http://nsis.sourceforge.net/Main_Page). They our signed by our codesigning certificate. This has worked well for us for more than a decade (Nmap introduced our NSIS installer in January 2006). However, Microsoft Windows currently has a native software management system called Windows Installer, which processes MSI and/or MSP database files. MSI files are also often distributed as part of EXE bundles that first check whether the system's MSIEXEC.EXE exists and is new enough. If not, they unpack their own MSIEXEC and use that to install the MSI.

We are hoping to at least move Npcap OEM to an MSI.

It is worth noting that tools are available for converting NSIS EXE files into MSI ones, such as http://www.exemsi.com/. But it isn't clear whether that sort of MSI would be a big help for anyone or not.

[AngelFalse]

Nah. It doesn't seems necessary to me at least.
Is there a reason that we shall repackage using MSI? I cannot see anything change if moving from NSIS to MSI, neither pros, nor cons.

[fyodor]

For what it's worth, another Npcap OEM licensee recently requested this feature and gave these reasons:

Our reason we are moving from a setup exe to an MSI is largely one of the perception with customers: it’s what people expect so we are trying to “play nice” (it’s one less objection from people to overcome!). We’ve spent a bit of time investigating what we need to do and its not too much effort for us. Windows Installer handles a whole bunch of painful things like replacing files in use and gives you repair functionality etc so there are some tangible benefits

Having npcap as a merge module would enable us, and other OEMs, to include npcap in our MSIs more seamlessly. We can include and use the existing setup executable without too much trouble. However, this runs “outside” of Windows Installer so things like repair wouldn’t work with the files installed. When the installer runs, they would see the npcap setup window popup so it’s a slightly less slick experience. Microsoft provide the MSVC CRT modules as merge modules which you can include in your MSI – when you install your product, the runtime DLLs are installed if required without any popups etc, they are just part of the app.

[patanne]

I agree there should be a MSI. I am part of an organization that provides managed services to companies of all sizes. We are researching deploying npcap as the underpinning to a lot of scapy-based code we have written.

When you deploy software to an organization, any time you have more than 10 machines you should be looking at group policy(GP) to manage the affair. Trying to manage more than 25 machines is downright negligent without GP/WSUS/SCCM. Deploying new software or updates in this manner requires MSI files, except in some circumstances with SCCM.

When we are stuck with EXE's we need to create a wrapper MSI that does nothing more than embed the EXE then call the EXE with all it's command line parameters to automate installation. There are complications/restrictions with this process, mainly surrounding the notion of chained installations. If the installation is unavoidably interactive – we can't fully automated the process because the EXE lacks the command line args to avoid the need to ask the user something – we cannot use the product.

We use Advanced Installer. It makes things quite easy to build a EXE and MSI from the same project. It also allows you to easily use the same code to build merge modules.

[DamagedDingo]

Well, this answered my question but I was looking for MSI to silently install for a school\UNI. There are too many machines to do manually so I will need to find another solution.

[fyodor]

For reference: In issue nmap/nmap#2013 , @akontsevoy gives this list of potential advantages to migrating to WiX Toolset (MSI):

1. That's more transactional, or at least semi-transactional, and upgrades are normally handled without breaking existing installs even if they fail (provided you are careful with custom actions). Uninstallation of the old version runs after (not before) installing the new one and only removes outdated resources. Installed packages are cached by the system so that installs can be easily repaired/restored.
2. There are built-in facilities to handle service installation (not sure how drivers are handled in particular though), including prompting for reboot where necessary (such as if the service is deleted while there are service handles open).
3. You can still use NPFInstall.exe (or a DLL) to handle custom actions which are not offered out of the box.
4. The core of the installer runs with system privileges (as LocalSystem account), and can run custom actions from your EXE/DLL as such (provided you disable impersonation). LocalSystem account, if I recall, can impersonate anybody, probably up to and including TrustedInstaller. So in theory, maybe this can be used to work around the driver signature enforcement quirks such as observed in nmap/nmap#2012.

[fyodor]

I've moved this to the new Npcap issues tracker since Npcap is the top priority for the MSI migration. If we do that and it works well, we can consider doing Nmap

[fyodor]

For our tracking purposes I wanted to note that another licensee just requested this. And I wanted to let everyone know that it is still high on our priority list. We just have been working on a lot of other great stuff in the meantime. Our current main focus is WHQL certification (#237 ).

[guyharris]

In #768 an OEM user says that "The current oem npac[sic] installer is a 32-bit executable. Some of our customers object to any 32-bit-running things on their Windows machines." I asked whether an MSI installer would work.

Note that this means that if any helper executables are needed, as per item 3 "You can still use NPFInstall.exe (or a DLL) to handle custom actions which are not offered out of the box." in #103 (comment), there would presumably have to be both 32-bit and 64-bit versions for customers such as the one mentioned, with the appropriate one run for the platform - at least as long as Npcap supports 32-bit machines.

[fyodor]

Good point @guyharris. And Npcap will probably have to support 32-bit systems for many more years. Microsoft still offers free support 32-bit Windows 10 systems until next October, and then will offer paid support for years after that. There are also fairly recent vintage Windows on ARM systems which supported x86 emulation but didn't yet support x64. We could offer three separate installers (and supporting helper programs), but it's hard to justify the complexity for us and the users without some clear and convincing justification. It's really nice to have one compatible installer (or perhaps in the future MSI package) which can then detect and install the appropriate-architecture binaries for each system.