RE: 3 Win32::API bugs

----------------------------------------
> Date: Tue, 15 May 2012 11:44:30 -0700
> From: [email protected]
> To: [email protected]
> CC: [email protected]
> 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.