|laziness, impatience, and hubris|
speak up Win32::API usersby bulk88 (Priest)
|on May 14, 2012 at 18:29 UTC||Need Help??|
bulk88 has asked for the
wisdom of the Perl Monks concerning the following question:
I'm making some improvement to the Win32::API library. A previous discussion which wasn't very fruitful was here http://www.nntp.perl.org/group/perl.libwin32/2012/05/msg631.html Other outside of bug fixes, what do you want to see?
Create a API obj for plain function pointers that dont come from a DLL's export table as mentioned the other thread? I thought of 2 ways of implementing it. Current behavior is
I was thinking of, for non-DLL function pointers,
With method 1, if dll name is undef, next parameter is a numeric pointer, the function can still have a "friendly" name on the inside of the Win32::API obj, which one day might be useful or queryable, some people might be breaking open the Win32::API object and undocumented reading of the "procname"/function name hash slice already. I think changing the DLL name parameter to dual use dll file name string or numeric func pointer is bound to cause problems, for example, someone wants to load "1.dll" and submits "1" (MS Win32 API adds .dll automatically if it fails to find the dll). The func pointer will be IsBadReadPtr to catch and die on obviously wrong pointers rather than crash. Perl doesn't do SEH and GCC/Mingw project refuses to implement it in 19 years and counting, so IsBadReadPtr is the closest tool.
I'm thinking that something needs to be done with Wide string/unicode. Its 2012. Current behavior is pass through the scalar unchanged to the C api, use of Encode is required for utf16 parameters unless you write "P\x00E\x00R\x00L\x00". Should Win32::API always convert the ascii/utf8 scalar to UTF16 for utf16 parameters? Or thats a very bad idea because the source might not be "CP_ACP" and SV's utf8 flag is unreliable, see MultiByteToWideChar? Or should there be a package level flag variable whether to do the conversion automatically? Or perform no conversion, leave Win32::API as is, the user will do any utf16 conversion themselves? Or a package level callback that is called for all wide conversions, otherwise pass through string pointer unconverted? Or caller's probe caller's package for a particular variable or sub name and get the callback from there if that variable is defined? Or no package level variables due to 2 different modules that use Win32::API colliding on the setting so only per obj level wide conversion settings?
Currently all single char types are treated as scalar strings. "A" not 65, not 0x41. "©" not 168, not -87, not 0xA9. Would some kind of feature of chars as numbers be wanted? And how to implement it? Win32::API doesn't come with INT8, UINT8 and PINT8 and PUINT8 currently. Some users might be adding those 4 types explicitly to the type database at runtime, backwards compat issue then. Make these, and these alone, as chars as numbers? Or dont bother, user can pack/unpack himself, or if he is smart enough, type pun the C prototype to int types if he wants chars as numbers.
As a small note, a elaborate pack()/unpack() was already in Win32::API for pointers to handles/ints/shorts/etc, but due to an XS bug, the results of the un/pack() weren't used and the user had to manually pack/unpack himself. I am fixed this, but the fix goes into a new object type, along with any other backwards compat breaking bug fixes called Win32::API::More.
To be blunt, speak now or forever hold your peace.