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 20
01, 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.
