Hi,
I'm wracking my brain to get the most convenient and correct naming for
a module (or actually, a couple of them). They are Windows specific, and
furthermore, while Win32:: is an established toplevel namespace, I'd
ideally want 'Windows::' at the top in order to begin to break free of
the notion of being just for 32-bit, as 64-bit nowadays is the norm.
Still, my module (and many others) will work for either, so it'd make
sense to just be general and say 'Windows'...
Anyway, my impetus was a need for a module to handle transferrals of
'security contexts' between hosts - basically a way to do single sign on
in a Windows environment. I found Win32::IntAuth which is doing that,
but 1) it doesn't work on 64-bit, and 2) it's missing needed stuff like
passing token buffers back and forth during authentication. In short, I
think it can be done better. In any case, the naming for this particular
module is not really my focus now.
While developing a prototype for the above, I need to use the DLL API's
for the security subsystem, e.g. SSPI stuff. This API is fairly hairy
and requires dealing with dynamic buffers, pointers to same, OUT
parameters, and other messiness generally easier to do in C. But I want
to avoid C code - it can be done in Perl with the help of the raw
Win32::API (which, despite it's name, works in 64 bit too).
While mapping the needs I had in how to get the right Win32::API
constructs, I realized that it would help if I could have a generic
helper mapping against Win32::API, which would also handle some things
that Win32::API doesn't directly parse, and also perform the
registration of function callpoints, exports/imports of function names
etc. Also, there's a zillion possible DLL's in Windows (and every DLL
with another zillion of various functions that can be called) that
eventually would be nice to have premade wrappers for. And Windows
provided DLL's are not all - there's a large world out there with custom
DLL's.
I figure it would be wasteful for a number of modules that each did the
setup using Win32::API and the necessary glue to call the various
functions in API DLL's, while we could have a single module that
(eventually, as-needed) could define Perl wrappers to handle these calls
for reuse. Modules would be freed from the minutiae of generally
interfacing with Win32::API and could concentrate on the intricacies of
getting the params right. Actually, for most/many functions, it would be
nice to have more Perlish interfaces, e.g. many DLL functions are quite
multipurpose and allows many params to be NULL or can otherwise be
defaulted depending on other calls (e.g. passing in a buffer and the
size of the buffer is required in C, but in Perl the size of the buffer
is known and so the wrapper only needs the buffer). Other examples are
the proliferation of xxxA and xxxW calls, i.e. calls that accept single
byte chars vs multibyte chars. Since Perl knows how to encode/decode the
xxxA entrypoints aren't really needed.
So, at present I'm thinking of the module 'Windows::API::Wrap', which
would contain things like 'Windows::API::Wrap::Constants::MB' (the
MB_OK, MB_CANCEL constant values etc used when calling the MessageBox
function), and 'Windows::API::Wrap::DLL::User32', a Perlish API to
User32 that in turn uses 'Windows::API::Wrap::DLL::RAW::User32' which
has the more exact C counterpart which can also be used by others if
they need that exact control. (The DLL is still called 'User32' in 64
bit for back compat reasons). In time, it would be 'simple' to add
further DLL's and functions wrappers.
The other alternative I've come up with would be 'Win32::API::Wrap'.
While using an established namespace, I'm not sure if it's good form to
encroach upon the Win32::API namespace.
If anyone has any opionions on the matter I would love to hear.
TIA,
ken1
