[Nut-upsdev] NUT on Windows
Alexey Loukianov
mooroon2 at mail.ru
Mon Jan 18 10:19:53 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
18.01.2010 12:19, Arnaud Quette wrote:
Well, we're going a bit to far from the initial discussion, but in case...
>
> 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
>
IMO, there are two possible ways to port NUT to Windows. First one is to try to
mimic standard POSIX environment and to port/provide all the libraries NUT
requires in a some native windows form. Cygwin is one of the possible solutions,
MSYS + some changes to NUT is another. Second way is to rewrite NUT to use
native windows APIs, development tools, e.t.c.
I think that the term "port" is applicable only to the first way. Second way
would not be a "port" technically, but instead will be a separate windows-based
application that was written using NUT sources as a documentation reference. And
the codebase for this windows application will also be separate from mainline
NUT codebase resulting in practically double efforts required to maintain. I
don't think it is the best way to head on.
On the other side, windows is totally different in the way the userland
applications talk to the system/devices and in the way the system starts up and
shuts down. So it is unavoidable to have slightly different codebase at least
for UPS drivers and upsmon. All the differences of such kind may be separated
from the code to a middle application-defined interface that abstracts the
operating system specific details for device access/shutdows/e.t.c in a gentle way.
Another windows specific thing is the registry, so configuration-fetching code
should also be separated and abstracted. This abstractions could also be useful
for POSIX NUT port as it would give a green light to such features as LDAP
integration or MySQL/PostegreSQL configuration storage backends.
To summarize: I think that the first step towards the native NUT port to the
Windows would be to implement some architectural changes to the current POSIX
NUT port that would allow to implement system-specific things as a separate
chunks of code. It would allow to have the same NUT core for every OS it runs on
saving a lot of resources on code maintenance.
> 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?!
>
The company I've been working for two years ago was still using about 100
workstations running W2k, 5-6 workstations running NT4, and two windows-based
servers running W2k Server. Main issue that prevented that company from
upgrading were licensing costs: there were no point in spending a lot of money
on XP and Server 2003 while older generation software the company already own
provides all the functionality required by employees to do their job. I bet that
there are a lot of companies all over the world that are still using W2k and
even NT4.
- --
Best regards,
Alexey Loukianov mailto:mooroon2 at mail.ru
System Engineer, Mob.:+7(926)218-1320
*nix Specialist
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJLVDXIAAoJEPB9BOdTkBULxpcH/13vwPd7W49iSFP41xUvOK1w
6ekmV19o+Q4W5O2FRZ+kMmlQ2dHZ6eWdks4iI61VG1tSDPHEAj/6k6htDovM1vXh
uW7II7KfeWUaABiUJOw3fpXKs/IdVNuoos2QykKftbfx21rUWQZZaQpRmimPcPl2
ZIGvWKaIM5E5x2I7/HV1IgmWV1dHLxQbsre1cKxO2vx9rH7HhvQQeUBNe4h2qTPB
1wifuF+sXf8H+p/hXm4xiL7YHmarJV3+iXtNCOzY8ZSgwHzQRJeWkit/9NvfufFD
SuyLdyBJH5mpRnJ1YNpydk+YvZ1kz0flybTMs7TrDOjf+cbZoRSsvNLtKm6SEgA=
=qhck
-----END PGP SIGNATURE-----
More information about the Nut-upsdev
mailing list