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.
Regards, Fred ________________________________ ________________________________ From: Nut-upsdev [mailto:nut-upsdev-bounces+fredericbohe=eaton....@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: https://docs.google.com/file/d/0B0mSjYYj84-6ZGM4MWZfMnFxbUU/edit?usp=sharing 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@gmail
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
