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
