I want to up-vote this about 1000 times.

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)

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?

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.

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)?

@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.

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.

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.

yes, that is what I meant.

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.

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