----------------------------------------
> Date: Tue, 15 May 2012 11:44:30 -0700
> From: dbec...@roadrunner.com
> To: bul...@hotmail.com
> CC: libwin32@perl.org
> Subject: Re: 3 Win32::API bugs
>
..............................
> This would also not break Win32::API::Prototype which would also
> have to change if you add args to the new call. The only non
> obvious thing is how to specify the reference to the function addr
> (is it a packed address pointer or what ?).
>
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 would work with pack letter interface like this,
__________________
$function = Win32::API->new(
undef, 1900000000, 'II', 'I',
);
_____________________
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?
Regarding what a pointer is. Previously HANDLE was 1234/0x04D2. LPHANDLE was
"\xD2\x04\x00\x00". There was supposed to be automatic packing and unpacking of
pointers for C prototype style ::API objs. It was broken. It now works in a new
class for backwards compat breaking Win32::API features/bug fixes. I believe it
is best to keep pointers as SVUVs, or less ideally SVIVs, never SVPVs. The
values then can have integer arthmitic done to them in Perl (structs, etc) and
the pointers can easily be compared from what is seen from a Perl debugger
watch window or a Perl print() or printf() of the pointer to the console, to a
C debugger on the perl process. Win32::API::GetProcAddress and
Win32::GetProcAddress already return numeric SVs. The default perl XS typemap
keeps void * as SVIV. Most CPAN Win32 perl modules keep their pointers as IVs,
including Win32API::File and Win32::IPC. The interp guarantees that an IV/UV is
large enough to store a pointer.
