Reini Urban rur...@cpan.org
> On Nov 26, 2017, at 11:37 AM, Kenneth Ölwing <kenn...@olwing.se> wrote: > > > 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'… Win32 is still the preferred namespace for everything windows related, 32 or 64bit. Even on official 64bit 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. So why just don't you fix Win32::IntAuth for 64bit and add the missing stuff? > 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. That’s why you do the probing with an XS module at compile-time, the right dll is searched automatically by the compiler from the generic import library .lib. The dynamic nature of Win32::API makes it very fragile. > 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. I don’t like this idea of your at all. Such a wrapper is one line in XS, and much more stable. And since strawberry and activestate ships with the compiler, everybody can install it.
