Could a 64-bit-executable version of the OEM installer be available

[aklassen-appneta]

Describe the bug
The current oem npac installer is a 32-bit executable. Some of our customers object to any 32-bit-running things on their Windows machines.

To Reproduce
With a policy in-place not to run 32-bit executables, try to launch the oem installer. It will not launch, or at least not launch seamlessly, because it is not a 64-bit executable.

Expected behavior
A user with a policy against running non-64-bit executables, but who needs a 64-bit component hidden in a 32-bit executable install set wants the package to install its 64-bit-executable contents.

Diagnostic information

• we had to update our NSIS-based installer to be a 64-bit executable to satisfy a customer with such a policy
• it required nothing more than adding the line
  Target amd64-unicode
  to our NSI script.

Additional context
I understand that the installer may also contain 32-bit binaries but I haven't access to any 32-bit machines anymore so as to prove it. So I understand that the OEM installer MUST (for the sake of backward compatibility) be available as a 32-bit executable. What I am asking is that an OEM installer as 64-bit NSI executable be provided -- or that you would point out where the sources are for such an installer so we can patch it ourselves. I have been looking for such sources and have been so far unable to locate them.

[fyodor]

Hi @aklassen-appneta. Thanks for the suggestion. The Npcap installer itself is 32-bit for maximum compatibility while it installs native drivers and DLL's for the target architectures (x86, x64, ARM64). Did your customer mention how they set these policies and why? I'm not aware of any Windows features to remove x86 compatibility, though you could probably work up some custom Applocker or Group Policy or Windows Defenders rules to achieve this. Understanding the mechanism they used and their reasoning for doing so would help in finding an appropriate resolution or workaround.

[aklassen-appneta]

No, they did not. It might simply have been a human-administered policy within the IT department. But it was presented to us in the past as a hard-stop by an important customer, so I'm looking for options.

[guyharris]

Could a Windows Installer package be provided? Or is there stuff that the Npcap installer needs to do that can't be handled by Windows Installer?

[fyodor]

@guyharris - that would be a good solution. We are considering moving to (or at least offering) an MSI package version (Issue #103).

[aklassen-appneta]

offering a 64-bit oem EXE installer AS WELL AS the current one would be easier than moving toward an MSI, but I can see why you would want to go there. My own preference would be the existing NSIS based installer with the one tweak, though. We use an NSIS based one for our own product and I have yet to see a compelling technical case for leaving that behind. I'll examine #103 to see if one is provided there.

There IS a case mentioned there about having to wrap an EXE in a shell-MSI but my understanding is that SCCM-using customers who asked about MSIs were okay because their SCCM system had an option of running EXEs-with-params as SCCM steps -- no MSI involved. I can understand that if you didn't have that functionality you'd want an MSI. The end result is ... it seems the reasons for doing an MSI are political (my SCCM has to thin-wrap EXEs to use them -- but there are other SCCM options) and not technical but the political argument is easily described in technical-limitation terms, and indeed if there are acquisition-rules that prevent using a more flexible SCCM, political v. technical becomes a distinction without a difference.