win32netapi module -version 1.0beta1 (on Windows NT4/5)

[Mark Hammond]

>  It really looks quite similar. I looked at your *win32net* module and
>found that some of the interfaces are not present in your module, but
>are part of *win32netapi* (my module).

Some of these are missing; however a few are oversights that will take all 2
minutes to fix.

Also note that some of the NetShare functions are labelled in the SDK as
obsolete, and the same functionality can be obtained from win32wnet.
win32wnet is designed to work on all Windows, win32net is designed to be NT
only.

>Please correct me if I am wrong about these differences. About the
>info. level param, I think that the info. level numbers in most of
>these APIs are really crazy in base APIs. (101, 102, 1024, 512 ...). So
>I return dictionaries with keys for maximum possible info level
>(constranied by the privileges of user executing the API), in most of
>the cases. It's upto the user to choose which key/values he is
>interested in. I think it is better to free the programmer from the
>burden of remembering which fielss are present in which info. level
>and refer constantly to MSDN to find this info.

Except that the maximum info level is:
a) Not always appropriate when creating entries.  Eg, using the lowest info
level when creating a user is far easier as only 2 or 3 entries are
required.  Using the high user-info structures means I need to fill in far
more.

b) Doesnt always contain all information.  SERVER_INFO and USER_INFO seem to
have different info levels with unque pieces of data - eg, there is some
data that can only be obtained by using a specific info level, and other
data that can only be obtained using a different info level.

However, I do take your point regarding freeing the user from always needing
to know this stuff.  The solution for me is probably to provide a default
value for these arguments.

My code uses a clever (even if I do say so myself :-) table driven scheme
for these info levels.  Adding new Net API data-structures is trivial in my
setup.  This made it simple to support _all_ info levels, which seemed to me
the best option from a flexibility POV.

Mark.