RE: 3 Win32::API bugs

----------------------------------------
> Date: Fri, 11 May 2012 10:08:02 +0200
> From: [email protected]
> To: [email protected]
> CC: [email protected]; [email protected]
> Subject: Re: 3 Win32::API bugs
>
> as you may have realized, Win32::API::Callback is pure evil :-)
>
> I wouldn't spend too much time on it, it has always been more of a proof
> of concept than real working code. as the documentation goes, "highly
> experimental". I don't know of any code (or CPAN module) that relies on
> callbacks. good that you fixed some of the awkwardness, but I'm afraid
> the whole concept is too fragile to be *really* fixed.
I wouldn't say the concept is evil at all. .NET does something similar I think for its bytecode interpreter. Its just the current implementation of ::Callback is too complicated and too flawed by trying to manipulate a function that was made by arbitrary compiler. Hard coding the whole func in hex constants/string, would be more reliable. Or having the "section" asm strings be hard coded, not chopped up from a compiler. From the last time I looked at GCC asm, it doesn't ever use push/pop anyway by default, instead it does movs onto ebp+ or esp+. If I tried to write ::Callback, I would have just a asm function template with 1 void * 0xCODE pointer (a ::Callback SVHV or SVRV, or a SVPV off the HV or the PV of a SVPV of a HV) , and pass that 0xCODE and the value of original incoming ESP to a pure C func, then parse C stack in pure C. In theory you could just do & on one and only  auto var C func and that pointer is kindda the stack bottom (numeric top). The only thing you can't do from C absolutely is set the stack unwind amount. This design is much simpler design, and probably much easier to make x64 compatible than the asm function spliting, parsing, then pasting nightmare right now. Stack unwind info on x64 would need to be made dynamically for ::Callback to be x64 compatible. With section pasting, the unwind info would be harder to generate and register with windows. If there is a glaring problem with my "a better ::Callback" idea, its because I read ASM alot more than write it. I'm not rewriting ::Callback. I got it working "enough" as I described earlier.

My next problem is, pointerCallPack which calls Win32::API::Type::Pack and pointerCallUnpack which calls Win32::API::Type::UnPack do nothing. They are G_DISCARD, and Win32::API::Type::Pack and Win32::API::Type::UnPack dont change their parameters in place, so the un/pack they did on copy of $_[1] ($arg) is tossed. Is this a bug or a broken feature?

from XS Win32::API::Call
__________________________
            case T_POINTER:
                params[i].t = T_POINTER;
                origST[i] = ST(i+1);
                if(has_proto) {
                    if(SvOK(ST(i+1))) {
                        pointerCallPack(aTHX_ ST(i+1), i, intypes);
                        params[i].p = (char *) SvPV_nolen(ST(i+1));
                    /* When arg is undef, use NULL pointer */
                    } else {
                        params[i].p = NULL;
                    }
                } else {
____________________________
For a LPHANDLE prototype (specifically "BOOL __stdcall GetHandle(LPHANDLE pHandle)", WIn32::API::Type::Pack got $_[0] = 'LPHANDLE' and $_[1] was the argument from the test script call to Call(). For all the pointers to numbers/pointers/integers, Win32::API seems to require null padding and unpacking the PV string yourself. Is this by design (pointerCallPack is redundant and should be removed), or is this a bug (WIn32::API::Type::Pack the result of pack() should be assign to $_[1])?

Right now I'm thinking of implementing a sub VERSION for Win32::API to turn on unsigned and change S to short and struct to T and get WIn32::API::Type::Un/Pack updating their @_ params and whatever other compatibility breaking features/bugs I find in the next couple days.  I know you said the letters dont mean anything, but I believe they are directly related to and are fed to the pack command.