Re: 3 Win32::API bugs

On 05/16/2012 12:35, bulk 88 wrote:
>
> I would rather not change the dll parameter to a dual purpose ref or non ref, its not obvious what the code is doing then. Someone might ask does Win32::API correct "unnormalized" dll names now or returns the full path name of the DLL loaded from a relative or incomplete name. undef as a dllname is obvious for non-dll func pointers there is no dll involved. I looked up what Win32::API::Prototype is. It was last and first released in Apr 2001 and it uses the pre C prototype interface of Win32::API. It is older than Win32::API 0.40 (Mar 2003) which introduced the C prototype parsing. Win32::API::Prototype will continue to work as before under proposed method 1 and method 2 I posted on perlmonks for non-dll func pointers, it won't get the new feature though. From a quick reading of Win32::API::Prototype was a good attempt in 2001 to make Win32::API easier to use  but it is throughly obsolete (less types built in than Win32::API::Type) and unmaintained (last and only release 2001, no 
bug reports ever filed on it on cpan RT). Perhaps you are asking for non-dll func pointers to work with the old pack letter style interface?
> _________________
>    $function = Win32::API->new(
>        undef, 'int 1900000000(int a, int b)',
>    );
> ____________________

That has no beauty and looks confusing since nobody would actually have a
literal number to use.  :)  Most likely you would need to use a sprintf to
create the 2nd arg to the new using the returned addr as the function name.

PS: I have a fair amount of API::Prototype code in use - I like it better
than the API interface but that's just me - if it were bug free, that's
what I would probably use - it's prettier.  :)

> That would work with pack letter interface like this,
> __________________
>    $function = Win32::API->new(
>        undef, 1900000000, 'II', 'I',
>    );
> _____________________

Same with this one except you could probably use the return addr directly
if it's unpacked.

> I dont like this approach for the reasons I said on PerlMonks since there is no friendly name associated with the function now.
> With a tiny bit of work by me
> _____________________
>    $function = Win32::API->new(
>        undef, 1900000000, 'meaninglessName','II', 'I',
>    );
> ____________________
> can work too. Is this what you want?

That one would certainly be better than the first two options - you
have to have the name so you can call the function using it.

Possible additional alternatives:

1) create a new method that specifically handles only the new dynamic
function interface and then there is no compatibility issue and it
could call the old Win32::API new with whatever extra hidden parameters
that are needed;

2) use a sub-package - Win32::API::Dynamic or some such could be
created that inherited from Win32::API to handle the new code in a
similar manner.

Mind you, these are only suggestions to possibly help to make it easier
to follow the logic.  It comes down to what you feel comfortable
implementing.  I thought my ref idea was easier to implement even
though it may be a bit convoluted using the DLL arg to do the logic
switching.