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/20220623/ec4379f7/attachment.htm>
Am I correct in assuming this is all Win32 code still? Ted On 6/23/2022 2:52 PM, Jim Klimov via Nut-upsdev 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 :-) > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20220623/7d1015da/attachment.htm>
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/20220713/5309f246/attachment.htm>