Re: 3 Win32::API bugs

On 05/10/2012 06:00 PM, bulk 88 wrote:
> I still don't know what letter to use for shorts. $ has no lower case version for signed short. H is too closed to hex numbers and pack's existing H unpack feature letter (H="Half"), someone might want to put in a 'H' type code one day to get strings back in ASCII HEX from Win32::API rather than binary gibberish.  T (T="shorT", also "strucT", but sturct is S already), isn't used by pack, W (W="Word") is used for BER numbers by pack, and I've never seen those anywhere, so W or T I think are safe choices.

note that Win32::API letters have nothing to do with Perl's pack/unpack. 
I know, I know, it would be nice to keep it consistent, but this is not 
necessary.

furthermore, the C-like prototype feature completely hides the letters 
used. you could simply say that using Win32::API with letters is 
deprecated, and choose whatever ugly letter you want :-)

heck, you can even use compound type identifiers, eg. "I" for int and 
"UI" for unsigned int, or something like that.

> The unsigned features I'm not sure how to implement, I dont think it makes any sense for in parameters, since on a C level, a function can't tell if it got a signed or unsigned. The only kind of pointer fill supported by Win32::API is fill a string pointer, so for a pointer to int or pointer to handle you still have to unpack it yourself (I think, I've only used Win32::API for a few days). For the return parameter currently I thinking of a bit flag field for T_NUMBER and T_INTEGER that gets masked off for the switch, and then the flag is check on whether to make an IV or a UV. If the return unsigned bug is fixed, small but I think irrelevant risk of breakage complaints.

regarding pointers, if you define a type (eg. 
Win32::API::Type->typedef), Win32::API creates a corresponding "LP" type 
that is packed/unpacked for you. if I remember correctly :-)

> Implementing the short feature is the most difficult I think. I made a test for the Dll handle leak and fixed that already. *I think* I fixed Callback. A couple problems with Callback was the ILT jump table, all the functions are 1 opcode long with the ILT jump table, shannons law has been broken by MS. Fixed that. The biggest problem I think was, assuming that the compiler will always copy the fake global vars which are replaced with EBP stack reads, into EDX. Any, slight, tiny, change of the compiler by MS can, and probably has in the past, broken it. I rewrote it that any mov from fake global pointer to any register will be caught and replaced. Also, under -Od, VC didn't use the traditional mov opcode, it used one specific for EAX (ask intel about that one), fixed that. I also reworked the optimization pragma to be more specific what ::Callback wants (dont toss the 0XC0DEs) to CallbackTemplate, and CallbackTemplate can be compiled with O1 O2 and Od now.

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.

> In 00_API.t, there are a bunch of cdecl tests that are commented out. They refer to functions like c_call_sum_int c_call_sum_int_dbl? Does anyone have these, they aren't in API_test.cpp.
    		 	   		
no idea about this one, sorry.

cheers,
Aldo