Improve and document the way Npcap installer (particluarly silent OEM installer) handles existing installs

[fyodor]

This is most relevant to Nmap OEM and its silent installer since the free/demo Npcap always runs interactively where it can ask the user what they want to do for a given install. Though our decisions here may touch upon or modify the interactive installer experience a bit too.

First let 's look at the current behavior. When the current Nmap OEM installer runs in silent mode (without other options), it always installs UNLESS a newer version of Npcap OEM is already installed. This means it re-installs if the same version of Npcap OEM is already installed, and it will also "downgrade" itself automatically from a newer version of non-OEM Npcap. If you specify /downgrade=yes, then it will also install over newer versions of the OEM version of Npcap.

While this works for many users, there are a few concerns:

• This doesn't provide a way for products to easily "ensure that Npcap is installed and that it's at least this version" or "ensure that exactly this version of Npcap OEM is installed" by simply running the installer. That doesn't work right now because the installer currently will uninstall and reinstall itself even if the exact same version of Npcap is already installed with the same options. That takes a long time compared to just noticing that the same Npcap is already installed and then exiting.
• The default of "downgrading" from non-OEM to an earlier OEM version while not downgrading if both versions are OEM is questionable. The practical differences between Npcap and Npcap OEM are almost entirely in the installer and how they report themselves. Other than that, an installed copy of Npcap OEM functions roughly identically to an installed copy of free/demo Npcap. So it makes little sense to treat them so differently.

What we probably want to do instead is:

• Change the default silent install logic so it only installs if one of the following is true:
  • Npcap (any edition--free or OEM) is not installed
  • An older version of any Npcap edition is installed
  • The same version of Npcap is installed but with selected options which vary in a material way (like admin mode vs. no admin-mode or raw wifi sniffinger versus not).
• Keep the /downgrade=yes option available which would downgrade newer existing versions of Npcap or Npcap OEM to the one that is being installed. While we work extremely hard on compatibility and think that leaving the existing newer version would usually be better, we can understand why some companies might want to ensure that exactly the version they tested with is installed. Note that this would still not install if exactly the same version is already installed with the same material options.
• Add a new /force=yes option which tells Npcap to ALWAYS uninstall any previous version and install itself no matter what. This might be valuable if you have a broken install for some reason. Microsoft feature releases have in the past caused that sort of breakage, and of course it could happen from filesystem corruption or botched attempts to fix something else, etc.
• Make "=yes" the default for options so people can just specify /downgrade or /force if desired. Or we could make it fail. I just wouldn't want one of these options to seem to work and then for it to not work when needed. If someone specifies /force or /downgrade by themselves, I think it's safe to say they want it set to yes.
• Document this new behavior in the Npcap install guide. Right now we don't even have /downgrade documented there.

The key advantages of these changes would be:

• Remove the arguably pointless or even detrimental default of downgrading new (free/demo version) Npcap to older copies of OEM.
• Allow companies to more easily ensure they get the version of Npcap they want by running the silent installer each time their software starts up. With the current installer that takes too long since it would uninstall and reinstall the same version of itself each time. With these changes, execution will generally only take a fraction of a second to determine that the same version of Npcap with the same material installation options is already installed and then it will quit.

[GlenHandke]

I want to up-vote this about 1000 times.

[dmiller-nmap]

Implemented, pending testing. New decision flow, terminal states bold:

1. If no existing Npcap, install.
2. If /force=yes, install.
3. Compare version with existing: 3.1. If existing Npcap is newer AND /downgrade=no (default), prompt. 3.2. If existing Npcap is the same AND install options are identical, prompt. 3.3. If existing Npcap is older, install

The prompt is a message box asking whether to install or quit, and the default in silent mode is always quit.

"Install options" which are compared are those that alter the state of the final install, not those that change the method of installation:

• /loopback_support
• /admin_only
• /dot11_support
• /winpcap_mode
• /vlan_support (unsupported option, no effect currently)

[dmiller-nmap]

Also implemented pending testing: /option_name is the same as /option_name=yes, even if the default value is usually /option_name=no.

TODO: Consider install directory (/D) to be an install-modifying option?

[dmiller-nmap]

Need to decide on meaning of /force option. There are 2 possibilities:

1. /force always results in uninstall of existing and install of the packaged version. This is currently implemented, but results in overlap with /downgrade and no option to preserve existing newer install.
2. /force does not bypass version checking, only overrides the "modified install" check. This gives the most flexibility.

My initial thought is to implement option 2, since it allows the most possibilities:

1. /force=yes /downgrade=no = If our version is same or newer, always install regardless of options.
2. /force=yes /downgrade=yes = Always install regardless of version or options.
3. /force=no /downgrade=yes = Always install regardless of version, but only if options differ.

Another possibility would be to create a modifiable installation.

[fyodor]

This all sounds great! I like your suggestion #1 with /force meaning always install. Even if it's the same version with the same options (maybe they are worried their install was corrupt) or even if a newer version is already on the system (maybe they always want to use the version they tested with). If that's not flexible enough, maybe we could change the name or meaning of one of the other options (or add an extra option)?

[fyodor]

@dmiller-nmap: Regarding this flowchart you posted before:

1. If no existing Npcap, install.
2. If /force=yes, install.
3. Compare version with existing:
3.1. If existing Npcap is newer AND /downgrade=no (default), prompt.
3.2. If existing Npcap is the same AND install options are identical, prompt.
3.3. If existing Npcap is older, install

Is there an option combination to say "only install if there is no existing Npcap or if the existing Npcap is older or if the existing Npcap has different material install options"? So this would mean only do the downgrade part if the options differ. Keep the newer version if the options are the same.

I'm not certain we need this, just wondering if it's possible with the current system? Because /downgrade=yes means always downgrade to this version even if a newer is already installed with the same material options? I do foresee customers wanting that way too.

[dmiller-nmap]

Ok, I think we want to enable these use cases:

1. "We need this minimum version and do not care about install parameters." (no existing option, not sure if this is needed)
2. "We need this minimum version and these exact install parameters." (current default behavior)
3. "We need this exact version and these exact install parameters." (current /force behavior)

Over all of this, we can layer the new "don't do unnecessary installation" behavior, which only adds 1 additional use case: "We need to uninstall and reinstall no matter what version or existing install parameters." That is the current "/force" behavior, so if we make "/downgrade" short-circuit based on install options, then that covers everything except use case 1, which I'm not sure matters anyway.

[fyodor]

I think no. 3 may have two cases: 3a) We need this exact version and these exact install parameters, but don't re-install if that is already met 3b) We need this exact version and these exact install parameters, BUT RE-INSTALL ANYWAY even if we have them.

My understanding is that current /force behavior satisfies 3b, but what should users do for 3a? Maybe this is what you were addressing in your last paragraph but I'm not sure I fully understand.

[dmiller-nmap]

yes, that is what I meant.

[dmiller-nmap]

Ok, based on our chat today, this is the proposed new behavior:

1. If the /force option is used, the existing Npcap installation will be replaced.
2. If the existing Npcap installation is older than the installer's version, it will be replaced (same behavior as existing installer).
3. If the existing Npcap installation is newer than the installer's version, it may be replaced (downgraded) if
   • the /require_version option is present, OR
   • the /require_features option is present AND the command-line installation options differ from the existing install. Options that are not present on the command line may vary without triggering a replacement install.
4. If the existing Npcap installation is the same version as the installer's version, it will only be replaced if the command-line installation options differ from the existing install, exactly as though /require-features had been specified.

[dmiller-nmap]

These options have been added in Npcap 1.55, and the docs are updated on the website and in Npcap SDK 1.11.