Naming module (Windows specific)
Kenneth Ölwing
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
Timothe Litt
Although Microsoft has the current mindshare, Windows is a generic term. Others have used it. So if you really need a new top level namespace, I would suggest MSWIN (or MSWINDOWS, or MSWINNT, or WINNT...).
I also view the direct access to OS APIs as a last resort - Perl
is about portability. So I'd much rather see
SSO::something::MSWIN - where something can be abstracted to work
with Unix, MS Windows, VMS, ... (e.g. login, logout, access,
deaccess, adduser, revoke, ...)
Note that Windows authentication is based on Kerberos, which
started on OSF/1 (Unix). And with some effort, still
interoperates. See Krb5, Authen::Krb5, Authen::Krb4, etc for
Perl interfaces.
Certainly there are applications for direct API access - system configuration, process debugging and monitoring come to mind. I don't object to making this easier.
But I do think that it's best to encourage application
portability by providing portable abstractions of functions with
OS-specific backends. Even if you leave writing all but one of
the backends to a future time or someone else.
The width of pointers and integers in the OS API is by far the least important consideration in application architecture. It can usually be buried under DWIM...
To use your example, I don't see much benefit in direct calls to
MessageBox - Tk gives you an interface that lets your application
run on Unix too. And while I haven't run into a cause where I
need to tweak beyond what Tk allows - better to extend Tk than to
hardwire an application to one OS for the sake of a bit or two.
(The same rationale applies to other APIs, of course.) Or there's
X11::Protocol even lower level, but still will talk to screens on
Windows, Unix, VMS & others.
Finally, I wouldn't assume that what you call "Windows" today
(covers both 64 & 32) will still be generic when
Win128,256,384 or 512 shows up. (May seem silly now, but they
will.)
So while raw API access can be handy in limited circumstances, I
don't think it should be pushed.
Kenneth Ölwing
Thanks both for your feedback.
On the topic of top-level namespace: It's not a biggie, although Win32::
may look a bit misleading at times, I accept that it is the defacto
'standard' and can certainly fit in underneath. And yes, 'Windows' is
maybe too generic anyways.
[Timothe] Whether I should shoot for a distro that is an abstraction of
SSO in general is for me at this point shooting way over the top. I have
little experience with Krb and others and so have no idea what other
abstractions would be useful in coming up with a generic framework that
would allow nice pluggables. So I would at this point try to stick with
the Win32 backend and if someone ever is capable of coming up with the
definitive SSO framework I hope it would be reusable as-is, or at least
provide lots of code to enable things to fit in.
I can understand your words that Perl is about portability. But so is
Java, to a much greater extent, and the great thing about Perl in
comparison is that Perl does allow you to much easier drop down to
direct and non-portable OS access if you need to. And as you also
mention, sometimes you really do; there are API's/mechanisms that simply
does not exist or even make sense elsewhere. Being able to access them
easily (without having to drop down to C) is a big win.
The example of MessageBox is just an example, obviously silly in most
ways, it's just a convenient API to try things out with when messing
with Win32::API and similar. Then again, if all I ever need is a message
box (in an already Win32 specific module), why involve Tk at all?
[Reini] After digging around in Win32::IntAuth I didn't feel it suited
the type of use I needed it for, lacked abstractions for certain things,
and mapping my ideas on top of it I would effectively end up with a
almost complete rewrite. And remember, it does two things: it both sets
up the the actual interface to Secur32.dll and then uses it. I would
prefer to split this into two parts: the raw DLL interface in one distro
(so the interface can be reused if needed and as a bonus also be used
for any other conceivable DLL in a manner that arises the abstraction
beyond Win32::API), and the actual wrapping of the underlying concept of
a SecurityContext is in a separate distro. So it's a two-step process
and at this point I'm considering the first one. But true: if I have the
first part of wrapping raw DLL's I might try to produce a rewrite of
W::I utilizing that...hmm...
Your comments about XS however doesn't make total sense to me. Maybe I'm
unclear, but I think there's a great point in being able to avoid C code
if possible. Then we don't need a compiler at all. If you are suggesting
that for every possible DLL function you always would need to write a
lowlevel C part, then that would just make things harder or even
impossible for those without C knowledge. In contrast, declaring a
function prototype in text you get almost directly from MSDN and pop it
into Win32::API (and with some extra tracking allow handling out OUT
params, automatically importing function names etc etc) seems simpler.
Yes, this is runtime rather than compiletime, but generally speaking,
the Win API's I'm seeing are quite stable. I'm sure there are instances
where Win32::API might not be enough and/or dynamic, runtime linking is
inappropriate and then we can drop down another level, but so far that
mechanism works good enough for my needs in my opinion.
ken1