develooper Front page | perl.module-authors | Postings from November 2017

Naming module (Windows specific)

Thread Next
November 26, 2017 10:37
Naming module (Windows specific)
Message ID:

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 

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.



Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About