[Nut-upsdev] NUT on Windows

[Arnaud Quette]

just my 2 cents to the discussion since the windows port is still part
of the TODO list...

2010/1/18 Charles Lepple:
>
> On Jan 17, 2010, at 9:21 PM, Alexey Loukianov wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> 18.01.2010 05:03, Charles Lepple wrote:
>>>
>>> On Jan 17, 2010, at 8:31 PM, Alexey Loukianov wrote:
>>
>>> You might check to see if WinNUT uses any of the NUT core code, or if
>>> any of the build system could help port the rest of NUT.

right, WinNUT is a good place to start with.
though it only deals with the NUT client side (upsmon), it has the
installer and probably the service notion.

part of the windows port I have in mind, all the drivers + upsd +
upsmon should be service.
the configuration probably has to go into the registry.
a native approach, using MS Visual C and its workspace and projects,
would be the best, though a cygwin step can be good too.

the only point that is to be digged is the driver - upsd state
socket... I don't know what would be the right

>> WinNUT is monitor client only so it don't talk to USPes directly. Will try
>> to
>> search google for cygwin port of libusb and NUT to Windows. Looks like
>> windows
>> support it is not the frequently requested thing :-D.
>>
>>
>>> The thing is, many of the devices that NUT supports are USB HID Class.
>>> The easiest way to access HID Class devices in Windows is not to try
>>> and talk HID protocol directly the way that we do with libusb, but to
>>> use the Windows HID APIs.

probably not the easiest, but the more native / appropriate.
that said, some are having the exact same libusb approach on windows.

I can check to have more info, but using libusb 0.1 works on all
systems (using libsusb' own driver).
the only thing really needed seems to install properly the driver
(must be signed on x86_64 systems)

>> I hadn't had any experience with utilizing USB devices under Windows but
>> it
>> seems to me that in case there are any working windows ports of libusb,
>> its API
>> should be almost the same as it is for any other operating system.
>
> It's not so much an API issue, but usability. libusb-win32 requires a
> driver. The forthcoming port of libusb-1.0 seems to be focused on WinUSB, so
> that eliminates older Windows installations.

right, but the problem now seems that WinUSB is not always available,
and that it doesn't provide support for systems older that XP.

that being said, is it really a problem?!

>> There's no
>> point in porting common library to another platform and changing API's
>> drastically along the way. It then would be easier to create a totally new
>> library with a different API that integrates best into target operating
>> system.
>
> Funny you should mention that... This comes up a lot on the libhid mailing
> lists, but nobody has contributed a Windows HID API backend yet.
> http://libhid.alioth.debian.org/ for more details.

right, and libhid has not received much care for years. Though I
recently realized that libhid is more used than I thought.

I would really like to see that windows port going on, so if somebody
has skills and motivation, I can gladly assist this work.

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/