-----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:[email protected] 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----- _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
