NUT for Windows

Normally so far, NUT should be fully supported in POSIX-compliant systems (Linux, BSD, MacOS, Solaris, AIX, HP-UX, ...) to the extent that those environments provide further libraries and facilities used by specific drivers (e.g. "Linux i2c" interface is not present on other systems).

There were side projects about NUT for Windows that sort of fizzled out by 2014 with a NUT 2.6.5-based fork. In 2022 (after 2.8.0 release) this effort was integrated back to the main codebase and is now an "almost first-class citizen", well supported in terms of buildability and regular NUT CI farm checks. It can be cross-built in Linux with mingw, as well as semi-natively on Windows with MSYS2 environment (including MinGW x64); these use-cases are documented and scripted in the NUT codebase.

For the most popular practical cases (with USB/SNMP drivers) it should already work similar to POSIX builds, for some others the platform equivalence code is known-missing (e.g. effectively empty methods in some serial-port drivers) and such issues are tracked in https://github.com/orgs/networkupstools/projects/2/views/1 board; issues about known-missing equivalence are also labeled with https://github.com/networkupstools/nut/issues?q=+label%3AWindows-not-on-par-with-POSIX+sort%3Aupdated-desc+

Another notable caveat is that the installer was not revived yet, so currently it is only possible to build NUT (or take a tarball from CI), and then fiddle with libusb configuration so the NUT driver and not stock "HID Battery" would handle the device => for more details see https://github.com/networkupstools/nut/issues/5, https://github.com/networkupstools/nut/issues/1050 and https://github.com/networkupstools/nut/issues/1690#issuecomment-1455206002 in particular. The latter discusses use of the third-party Zadig tool to specify which low-level USB drivers should handle certain VendorID:ProductID hits.

I am not aware yet of any issues (nor success stories) about actually running the full stack with shutdowns and all on Windows alone. According to codebase, there were several generations of integration attempts for upsmon etc. running as Windows services and privileged enough to cause the shutdown. I know this worked in ~2005-2010 when I used it on some servers only running the upsmon for Windows, and talking to a driver and upsd running on a Solaris machine.

Current code base builds should provide a nut.exe wrapper (recently modernized and documented in PR #2446) which can register NUT as a Windows service to handle starting/stopping of the daemons involved. It should work with little granularity at the moment: either as a netclient with upsmon alone, or everything with a driver, data server upsd and client upsmon and attempts to power off the UPS during shutdown (if so configured).

To use a NUT data server running on Windows from external clients (or Virtual Machines running on same Windows), you may have quite an adventure with the built-in and/or third-party firewall and anti-virus software. Good luck!

Finally it is worth noting that configuration-file based setup is equivalent on all platforms; CI builds (below) provide an etc directory with samples which you should adapt to your situation.

Current NUT for Windows archives from CI are available at https://ci.appveyor.com/project/nut-travis/nut/build/artifacts - note this is a rolling URL for a "latest" build that may include PR checks; for a somewhat-stable codebase (PR merges to "master" branch) one needs to find the newest AppVeyor build link from a green-ticked commit at https://github.com/networkupstools/nut/commits/master history.

As with other efforts, community help is welcome and desired with testing, feedback, documentation and other PRs, and in this case - also with completing the known-missing codebase, installer, systems integration for installation, privileges, shutdown...