[Nut-upsuser] NUT on Windows revival

[Jim Klimov]

"Good news, everyone!"

With CI builds of the branch now regularly passing on both the
multiplatform FOSS NUT CI farm (including linux+mingw cross-builds), and
CircleCI with MacOS, and newly on AppVeyor with Windows+MSYS2 (including
integration tests with live upsd and some dummy-ups instances), after
ironing a few wrinkles I intend to PR and merge it into the main NUT
codebase soon, lest the effort bit-rot again.

There are nearly no remaining "functional" changes to lines of existing
"POSIX" NUT codebase, with platform specifics fenced by ifdef. (There is
quite a bit of noise with macro'ed data types that resolve same as they did
for POSIX builds).

So far it is not prime-time ready to package: some functionality remains
ifdef-ed away, though it might have been in 2.6.5 based releases too, and I
did not even investigate MSI generation. Also there were good ideas how to
architect and move it forward posted over the years... But at least it
seems already functional in many aspects and I still hope someone takes
that torch to the finish line. Many tickets for such details posted at
https://github.com/orgs/networkupstools/projects/2/views/1

FWIW, AppVeyor builds also publish a tarball of the Win x64 install area to
grab and test. Making sure it actually runs and talks correctly to the
hardware is important after all ;)

Jim

On Wed, Jul 13, 2022, 20:06 Jim Klimov <jimklimov+nut at gmail.com> wrote:

> Back from vacations, and before I dive into real-life work, I went over
> some ideas and notes from the NUT for Windows effort.
>
> Now they should be tracked at
> https://github.com/orgs/networkupstools/projects/2/views/1 and community
> help is welcome :)
>
> I probably forgot or missed some caveats - so feel free to post issues for
> this project if you think of some more...
>
> Jim
>
> On Thu, Jun 23, 2022, 23:52 Jim Klimov <jimklimov+nut at gmail.com> wrote:
>
>> Hello all,
>>
>>   After a hectic month in private life, as a byproduct I've got a viable
>> merger of last released NUT 2.6.5 based Windows-ready codebase (thanks to
>> the giants active a dozen years ago, on whose shoulders I stood today) and
>> modern 2.8.x/master, fixing the merge conflicts and build warnings. Some
>> details were tracked in discussion of
>> https://github.com/networkupstools/nut/issues/5
>>
>>   There are caveats, e.g. in a few files code was just hidden by `#ifndef
>> WIN32` so making it "appear" would be a future trick, and some "silly"
>> fallbacks for missing methods were hacked to make it build but probably are
>> not thread-safe etc... but at least binaries do appear and some do run
>> without crashing on Windows - e.g. usbhid-ups and nut-scanner did see my
>> test UPS. Fixes originally made for libusb-0.1 were applied to libusb1.c
>> too, but not tried yet.
>>
>>   Builds are possible, mostly scripted and documented, see:
>>
>> * `docs/config-prereq.txt` and `ci_build.sh` for MSYS2 (includes MinGW)
>> natively on Windows,
>> * `scripts/Windows/README` and a build script nearby for using mingw
>> cross-building packages on Ubuntu Linux.
>>
>> Both of these produce lots of standalone usable binaries installable as a
>> typical NUT directory tree, which (with copies of DLLs for third-party
>> projects) "just work".
>>
>> The adventure starts with:
>>
>> :; git clone -b Windows-v2.8.0-1 https://github.com/networkupstools/nut nut-win
>>
>> I really hope that the community members more interested and better
>> versed in the platform can pick it up from here, to discover and fix the
>> missing and flawed bits, make sense of the installer, etc. and eventually
>> make this codebase part of common NUT, multi-platform as it is.
>>
>> Sone points of interest OTOH:
>> * c++ and a few drivers are currently effectively "neutered"
>> * fcntl() code to avoid FD leaks to forked children, is it doable on
>> Windows?
>> * loading dlls from one dir, without copies near every exe (see common.c)
>> * automatically tracking major version number X (from client/Makefile.am)
>> for LTDL discovery of libupsclient-X.dll without hardcoding it
>> * localtime_r, gmtime_r use ugly fallbacks where unavoidable
>> * usb close_dev() crashes
>> * not all dependencies were tried, probably more build warnings are
>> lurking to clean up
>> * installer not investigated
>> * code mostly looks at "WIN32" macro as a big switch; there should be
>> more specific configure-script tests for different versions, toolkits,
>> build envs, IDEs... that are possible. Supported or not, WIN XP may still
>> be a big thing...
>> * clean up what `make install` does (e.g. no systemd/SMF on win)
>> * automate copying third-party dlls for `make install DESTDIR=...`
>> (recursive ldd?)
>> * make sure that Linux/Mac/Solaris/BSD/... builds from this branch are
>> not broken by that big code merge.
>>
>> On my side, curiosity is satisfied, itch scratched and bogus achievement
>> achieved, so I plan to rest and then do other things. Really looking
>> forward to you the reader to make the next iterations.
>>
>> When this codebase gets "good enough" to at least not fail to build
>> against more and more third-party projects, I'll look at covering this in
>> NUT CI so it does not regress with future evolution. This milestone is
>> actually already viable now, just I'm leaving for vacation :-)
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220822/4452f9ae/attachment.htm>