Version 5 (modified by dclark, 16 years ago) (diff)


Notes on possible Windows support

  • Windows Management Instrumentation (WMI) should be used wherever possible; there is an excellent WMI Python Module available, which also comes with a WMI Cookbook.
  • Before Windows 2003 SP1, on 64-bit machines there are no API or WMI calls to get to many 32-bit windows functions (such as the 32-bit registry) from 64-bit programs, and vice versa. There also is no (official) x86_64 native python distributions for Windows pre-Python 2.5. So the choice would be:
    1. Only support Windows in Python 2.5+ (which wouldn't be that bad because part of the build process would probably be to create stand-alone bcfg2 executables using py2exe). For 64-bit support there would have to be some kind of convoluted py2exe build process that built some things with 32-bit python and some things with 64-bit python.
    2. Wrap external command-line programs such as winreg, which is part of outwit, and screen scrape. Each external command-line program would need to be compiled into 32 and 64 bit versions. This approach might lead to licensing annoyances and having binary blobs in source control.


With the exception of 32/64 bit issues, Windows Services support should be pretty trivial; it would differ from *nix services in that it would be done via WMI API calls and not a 3rd party python module or wrapping a binary.


The best way of handling the registry may be to map it into a file-based representation on the server end. The Cfg and TCheetah plugins could then be used to set registry values as needed.


For a first run there may be some way of utilizing cygwin to make use of the existing *nix POSIX module for manipulating files. There would probably need to be some changes to deal with the fact that open files can't be manipulated/moved/deleted at all in Windows (other than to do some registry magic that makes the changes on the next reboot).


Listing and removal of packages should be pretty easy via WMI. For installation in most cases the admin would need to figure out the correct silent install flags (there is a web site that catalogs a lot of this information), and include that in the bcfg2 server-side XML along with a URL (like with the RPM plugin); the bcfg2 client itself would need to take care of download, perhaps via the urlgrabber python module.

Another option would be to utilize one of the existing FLOSS tools for dealing with Windows packages, such as WPKG.

Prior FLOSS Art