[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:
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
clepple at gmail
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsdev