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. On 26-Nov-17 05:37, Kenneth Ölwing 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'... > > 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
signature.asc
Description: OpenPGP digital signature
