<div dir="auto">Well, there is a fair bit of naming legacy involved. I tried x86_64 builds, but macros are about WIN32. But probably more nuances are possible about various WINNT numbers, WIN64 if there is such a thing, API method names per newer platform?..</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 24, 2022, 07:47 Ted Mittelstaedt via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net">nut-upsdev@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div>
    <p>Am I correct in assuming this is all Win32 code still?</p>
    <p>Ted<br>
    </p>
    <div>On 6/23/2022 2:52 PM, Jim Klimov via
      Nut-upsdev wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="auto">Hello all,
        <div dir="auto"><br>
        </div>
        <div dir="auto">  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 <a href="https://github.com/networkupstools/nut/issues/5" target="_blank" rel="noreferrer">https://github.com/networkupstools/nut/issues/5</a></div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">  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.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">  Builds are possible, mostly scripted and
          documented, see:</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">* `docs/config-prereq.txt` and `ci_build.sh` for
          MSYS2 (includes MinGW) natively on Windows,</div>
        <div dir="auto">* `scripts/Windows/README` and a build script
          nearby for using mingw cross-building packages on Ubuntu
          Linux.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">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".</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">The adventure starts with:</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">
          <pre style="font-family:ui-monospace,sfmono-regular,"sf mono",menlo,consolas,"liberation mono",monospace;font-size:11.9px;margin-top:0px;margin-bottom:16px;padding:16px;line-height:1.45;border-radius:6px;color:rgb(36,41,47)"><code style="font-family:ui-monospace,sfmono-regular,"sf mono",menlo,consolas,"liberation mono",monospace;padding:0px;margin:0px;background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial;border-radius:6px;border:0px;display:inline;line-height:inherit">:; git clone -b Windows-v2.8.0-1 <a href="https://github.com/networkupstools/nut" target="_blank" rel="noreferrer">https://github.com/networkupstools/nut</a> nut-win
</code></pre>
          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.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Sone points of interest OTOH:</div>
        <div dir="auto">* c++ and a few drivers are currently
          effectively "neutered"</div>
        <div dir="auto">* fcntl() code to avoid FD leaks to forked
          children, is it doable on Windows?</div>
        <div dir="auto">* loading dlls from one dir, without copies near
          every exe (see common.c)</div>
        <div dir="auto">* automatically tracking major version number X
          (from client/Makefile.am) for LTDL discovery of
          libupsclient-X.dll without hardcoding it</div>
        <div dir="auto">* localtime_r, gmtime_r use ugly fallbacks where
          unavoidable</div>
        <div dir="auto">* usb close_dev() crashes</div>
        <div dir="auto">* not all dependencies were tried, probably more
          build warnings are lurking to clean up</div>
        <div dir="auto">* installer not investigated</div>
        <div dir="auto">* 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...</div>
        <div dir="auto">* clean up what `make install` does (e.g. no
          systemd/SMF on win)</div>
        <div dir="auto">* automate copying third-party dlls for `make
          install DESTDIR=...` (recursive ldd?)</div>
        <div dir="auto">* make sure that Linux/Mac/Solaris/BSD/...
          builds from this branch are not broken by that big code merge.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">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.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">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 :-)</div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
Nut-upsdev mailing list
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank" rel="noreferrer">Nut-upsdev@alioth-lists.debian.net</a>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" target="_blank" rel="noreferrer">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a>
</pre>
    </blockquote>
  </div>

_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank" rel="noreferrer">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>