Investigate and make use of Windows Installer code in NUT for Windows codebase

[jimklimov]

Did not touch this yet, no idea what we have or how to use it. This state is something to change :)

UPDATE: See also: https://wixtoolset.org/ (used in those recipes)

[jimklimov]

Now build-mingw-nut.sh has a couple of routines to do a recursive walk to fetch many (open-source third-party) DLLs from mingw build environment. In the end they are dumped to bin dir (for drivers and tools), with links added later into sbin dir per needs of system daemons, because run-time DLLs must be near EXE (if not in system paths).

This logic can be extracted to standalone script to use in package (or other bundling) preparation.

[jimklimov]

Check with comments in:

• Windows build is obsolete #1050
• Windows-Client Error ntdll.dll #534
• Windows port v2.6.5 6 #455
• Windows Installer does not support a "silent install" #1257
• Windows installation and usage manual is required #958
• Windows MSI package missing DLLs #329

Loosely related to

• Windows: Try installing libUSB manually. #1145
• NUT Windows v2.8.0 with LibUSB Eaton device descriptor matching errors #1690

[jimklimov]

One stumbling block with making sense of older recipes was the use of GUIDs in them. Per sources like:

• https://stackoverflow.com/questions/5832315/wix-autogenerate-guid
• https://stackoverflow.com/questions/1405100/change-my-component-guid-in-wix/1422121
• https://stackoverflow.com/questions/72260553/wix-setup-when-do-i-need-to-change-the-guid-of-a-component

...such component GUIDs effectively encode the full packaged path to installed file (whatever version), to the point that "*" or "\*" might be used for WIX to generate one unambiguously. They should not be updated for newer releases of the component files, if they land to the same location. There are also product GUIDs that should differ for each release (each build from separate source revisions?) and can also be generated by an asterisk. So one big headache less here.

There is also a recently revived effort for WixEdit GUI editor to help with the package recipe maintenance:

• https://github.com/WixEdit/WixEdit
• https://wixedit.github.io/

...and a number of other editors (mostly plugins for Windows-based IDEs) listed at https://robmensching.com/blog/posts/2007/11/20/wix-editors/ (old post, regularly updated)

Also took a quick look at other popular options, e.g.:

• Nullsoft Scriptable Install System (NSIS) - https://sourceforge.net/projects/nsis/ only seems to allow creating Setup.exe style distributions (MSI made by WIX is allegedly better integrated for corporate automated installations/updates across many systems, which may be fairly important for NUT in a Windows-centric data center).
• InnoSetup https://jrsoftware.org/isdl.php also seems to only allow EXE distros, and is not FOSS (Free and Source Available via https://github.com/jrsoftware/issrc, but with a special license. Also seems to only run on Windows, so harder to use for cross-builds with CI (AppVeyor with native Windows runners is an option though).