From jimklimov+nut at gmail.com Thu Nov 3 09:48:46 2022 From: jimklimov+nut at gmail.com (Jim Klimov) Date: Thu, 3 Nov 2022 10:48:46 +0100 Subject: [Nut-upsdev] NUT on Windows revival In-Reply-To: References: Message-ID: Heads-up: A community member had good progress in https://github.com/networkupstools/nut/issues/1690#issuecomment-1301824123 to properly see an USB UPS. This effort is becoming more viable over time... :) Jim On Sat, Sep 3, 2022, 17:25 Jim Klimov wrote: > Windoze in da NUT house! > > Codebase of the NUT for Windows branch was merged to main codebase, not in > the least to avoid bit-rot and need for resynchronisation with merge > conflicts that regularly arose as the two branches "just co-existed". More > community work is needed to complete some drivers' functionality and MSI > package delivery, but for many use-cases it may already "just work" using > tarballs from AppVeyor CI. > > Happy back-to-school weekend, > Jim > > On Mon, Aug 22, 2022, 01:55 Jim Klimov wrote: > >> "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 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 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: