[Nut-upsdev] UPSC based Windows Client

FredericBohe at Eaton.com FredericBohe at Eaton.com
Thu Oct 17 07:39:10 UTC 2013

Hello Charles and Eric,

The windows_port branch on my repo is mostly a rebase on latest master. I still have some work on this before pushing and of course not enough time for it. Anyway the branch on the official repo should be functional.
But I guess the main issue if you want to reuse the windows code is that it has been written to be compiled in a MinGW environment, not with MS building tools. So you will probably have to modify some NUT code anyway.




From: Nut-upsdev [mailto:nut-upsdev-bounces+fredericbohe=eaton.com at lists.alioth.debian.org] On Behalf Of Charles Lepple
Sent: jeudi 17 octobre 2013 02:01
To: eric kreuwels
Cc: nut-upsdev list; Frederic BOHE
Subject: Re: [Nut-upsdev] UPSC based Windows Client

[Please remember to copy the list.]

On Oct 15, 2013, at 8:45 AM, eric kreuwels wrote:

Hi Charles

Thanks for your answer. Good questions/suggestions. I copied both the WinUPSC and the installer project on my GDRIVE and shared it with you:

Archiving WinUPSC in the NUT GitHub would be my preference. Delivery as part of te Windows distribution is basically a separate decision for you guys.

Steps I have in mind:

  *   Check how WinUPSC will is perceived by the other developers! Then decide to setup a project in NUT GitHub
  *   Maybe a good idea to have a code review:

     *   Especially how I modified the UPSC code for polling. For example how standardized is the parameter list? I made assumptions here.
I haven't diffed your code against either NUT or WinNUT, but after a quick check, I'm not sure I understand your question here. If you are referring to the UPS variables, there is no guarantee that a specific variable will be available (except "ups.status"; think of a contact-closure UPS which can only report OL/OB/LB).

As an aside, in upsc.c, you use sprintf() with strlen(). There is a snprintfcat() utility in common/common.c

     *   I tried not to violate any licence and only re-use freeware, but don't fully comprehend these licences. Can these licences collide?
They can, potentially. The one thing I spot-checked was the icon page, and I didn't see any license information there.

     *   Are the credentials in the about box and the manual are sufficient :-)
I'm not sure where the About box is defined. The manual looks okay, although I wonder if the app code falls under the blanket "all rights reserved" clause: http://www.codeproject.com/info/TermsOfUse.aspx

It probably comes down to whether this code is boilerplate for all win32 applications with an icon. I'm not the right person to make that call.

  *   Fix blocking issues for a first launch. My testing setup is limited (I only have Eaton UPSes). Feedback from others is really needed.
One way to test your code is to use the dummy-ups driver with the sample data files provided. data/evolution500.seq simulates an MGE/Eaton Evolution 500 going on battery, then to low battery, then back online.

Of course, feel free to solicit testers with actual hardware. But with dummy-ups, you can basically simulate various combinations of variables, and there are many different examples in the list archives (search for "HCL"). Here's more information on dummy-ups: http://www.networkupstools.org/docs/man/dummy-ups.html

  *   Code cleanup; I like the idead to reference original NUT code (remove the duplicates in my project. I re-used the ported NUT files from WinNUT)
I CC'd Frederic Bohe who worked on the NUT windows_port branch. Perhaps he has some suggestions. The windows_port in his GitHub repo is different than the original one we converted from SVN, so I don't know the current status of that porting effort.

Looking forward to work with the development team

Eric Kreuwels

Charles Lepple
clepple at gmail

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20131017/ad426a55/attachment-0001.html>

More information about the Nut-upsdev mailing list