Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

speak up Win32::API users

by bulk88 (Priest)
on May 14, 2012 at 18:29 UTC ( #970481=perlquestion: print w/replies, xml ) 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 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
$function = Win32::API->new( 'mydll.dll', 'int sum_integers(int a, int b)', ); #### Method 2: with parameter list $function = Win32::API->new( 'mydll.dll', 'sum_integers', 'II', 'I', );
I was thinking of, for non-DLL function pointers,
$function = Win32::API->new( undef, 1900000000, 'int meaninglessName(int a, int b)', ); ############ OR #if dll name undef, func name is numeric pointer $function = Win32::API->new( undef, 'int 1900000000(int a, int b)', );
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.

Replies are listed 'Best First'.
Re: speak up Win32::API users
by jswalker (Initiate) on May 14, 2012 at 18:53 UTC
    Something to make life easier in the world of UTF-16 would be great. We use a commercial software package that started out pure ASCII for its control files but has, with subsequent releases/upgrades, begun to use UTF-16 for their files. We have put off upgrading to later versions of thier software because we have quite a number of perl scripts that add functionality (allow bulk changes instead of item-by-item) for us, but we haven't had the time to try to convert our scripts to adapt to UTF-16. Something seamless to allow for either input with a minimum of fuss/translation would be a godsend.
Re: speak up Win32::API users
by Anonymous Monk on May 14, 2012 at 20:15 UTC
      Win32::API::Wide should also probably complain (warn) if they're not given unicode strings because its probably a mistake

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://970481]
Front-paged by davies
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (5)
As of 2018-05-24 04:04 GMT
Find Nodes?
    Voting Booth?