RE: 3 Win32::API bugs

[bulk 88]

> From: bul...@hotmail.com
> To: d...@perl.it; libwin32@perl.org
> Subject: RE: 3 Win32::API bugs
> Date: Wed, 9 May 2012 10:10:40 -0400
> Since Callback is crashing, I dont know whether to try to fix it, so I have a 
> question, did 02_Callback.t ever not crash with a certain version number of 
> Win32::API, with a certain compiler, etc?
>
> Or should I forget about callback and try and fix the 3 other bugs (func not 
> found dll handle leak, no unsigned return values, no shorts) which are easier 
> targets to kill than Callback and then try Callback if I have the time?

I got Callback.pm to stop crashing on 32 bit VC 2003. The problem is VC uses a 
jump table ("ILT"), so when you take the pointer to a function, its actually a 
pointer to a jmp opcode, not to the head of machine code for that function. 
That messed everything up. I fixed that by testing and decoding the jmp opcode 
if its there. Next problem was, on -Od,  mov esp,ebp; pop ebp; ret; not leave; 
ret;, I put in a case for that, going down the CallbackTemplate < 
PerformCallback branch somehow didn't work for me and lead to a crash I didn't 
investigate.

Now my problem is parameters from Perl to the Perl callback are wrong values. 

I think for some reason my emails are blocked from libwin32@perl.org.   
  

RE: 3 Win32::API bugs

[bulk 88]

> Date: Wed, 9 May 2012 10:35:37 +0200
> From: d...@perl.it
> To: libwin32@perl.org
> CC: bul...@hotmail.com
> Subject: Re: 3 Win32::API bugs
>
> On 05/09/2012 09:23 AM, Cosimo Streppone wrote:
> >> How is the no short problem supposed to be fixed? Moving struct to
> >> letter "T" would break too many grandfathered perl scripts right? So
> >> should a short be "T" then?
> >
> > I would definitely try to keep backward compatibility.
>
> I was thinking about getting "$" for unsigned short. looks almost like
> an S... :-)
What about signed short? There is no lower case dollar sign for signed short.

Since Callback is crashing, I dont know whether to try to fix it, so I have a 
question, did 02_Callback.t ever not crash with a certain version number of 
Win32::API, with a certain compiler, etc?

Or should I forget about callback and try and fix the 3 other bugs (func not 
found dll handle leak, no unsigned return values, no shorts) which are easier 
targets to kill than Callback and then try Callback if I have the time?

Thanks for respond Aldo.
  

RE: 3 Win32::API bugs

[bulk 88]

> To: d...@perl.it; libwin32@perl.org; bul...@hotmail.com
> Subject: Re: 3 Win32::API bugs
> Date: Thu, 10 May 2012 10:53:45 +0200
> From: cos...@streppone.it
> > Or should I forget about callback and try and fix the 3 other bugs (func
> > not found dll handle leak, no unsigned return values, no shorts) which
> > are easier targets to kill than Callback and then try Callback if I have
> > the time?
>
> I would tend to agree with this.
>
> --
> Cosimo
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.

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.

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.

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.
  

RE: 3 Win32::API bugs

[bulk 88]

> Date: Thu, 10 May 2012 11:55:02 -0700
> From: dbec...@roadrunner.com
> To: bul...@hotmail.com
> CC: libwin32@perl.org
> Subject: Re: 3 Win32::API bugs
> By the way - not to make your job more difficult or anything, but
> there's a situation that isn't currently being handled. Some OS calls
> can return a pointer to another function which you would then use to
> call that function to get more info.
>
> An example would be IShellFolder::BindToObject which returns a 'void
> **ppvOut' parameter that is to then be used to iterate over the objects
> in question. What would need to be done is to treat that returned ptr
> as though it were a named library routine that could be looked up in
> the DLL and instead just assume it has already been looked up and just
> use the returned address and associate it with the name supplied.
..
> I wanted to use this technique to iterate over the Recycle bin and
> look for a specific item or optionally list the items found using
> Win32API calls but got short-circuited by that returned function
> ptr and no way to use it.
>
Read my post from the other day. Win32::API can already do this with some 
runtime package namespace messing. http://perlmonks.org/?node_id=969555 I 
highly suggest you write an XS library though. C or C++ for your COM code.
  

RE: 3 Win32::API bugs

[bulk 88]

> From: bul...@hotmail.com
> To: cos...@streppone.it; libwin32@perl.org; d...@perl.it
> Subject: RE: 3 Win32::API bugs
> Date: Thu, 10 May 2012 12:00:57 -0400
> 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.
>
Another serious backwards compatibility problem. Win32::API's documentation 
official states only the flags that exist (I N F D C P S K) are all upper case, 
but in pack() upper case is unsigned number. In Win32::API::Type types are 
correctly mirrored as unsigned to upper case, signed to lower case. How is this 
supposed to be solved? API versioning "use Win32::API 0.69;" and an internal to 
Win32::API flag to invert the meaning of upper and lower case and turn on 
unsigned support? Time to fork Win32::API under a new name? or make a new PM 
called Win32::API::V2 or something that turned on unsigned support and inverts 
meaning of upper and lower case?
  

RE: 3 Win32::API bugs

[bulk 88]

> Date: Fri, 11 May 2012 10:08:02 +0200
> From: d...@perl.it
> To: bul...@hotmail.com
> CC: cos...@streppone.it; libwin32@perl.org
> 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.
  

RE: 3 Win32::API bugs

[bulk 88]

> Date: Thu, 10 May 2012 11:55:02 -0700
> From: dbec...@roadrunner.com
> To: bul...@hotmail.com
> CC: libwin32@perl.org
> Subject: Re: 3 Win32::API bugs
> By the way - not to make your job more difficult or anything, but
> there's a situation that isn't currently being handled. Some OS calls
> can return a pointer to another function which you would then use to
> call that function to get more info.
I'm going to restart this discussion at 
http://www.perlmonks.org/?node_id=970481 . I hope more pairs of eyes see there 
and respond there.
  

RE: 3 Win32::API bugs

[bulk 88]

> 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 19(int a, int b)',
  );

That would work with pack letter interface like this, 
__
  $function = Win32::API->new(
  undef, 19, '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, 19, '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.
  

RE: 3 Win32::API bugs

[bulk 88]

I reached an interesting problem. I added buffer overflow protection to SVPV 
pointer types. Win32::API's own test suite died from a buffer overflow here 
https://github.com/cosimo/perl5-win32-api/blob/45847136293a8d6939fc319f91702d0b91287726/t/00_API.t#L115
 . The sentinal pattern is 2 wide nulls and a 64 bit number, no alignment 
padding. At the github link, 1.0 becomes PV "31 [char "1"] 00 00 00 00 [2 wide 
nulls] e6 85 69 6f 42 09 00 00 [64bit randomish number] 00[perl's end of scalar 
null]" with SvCUR 13. A double is 8 bytes. Buffer overflow protection trips. So 
what a dilemma. Backwards compatibility means ignoring memory corruption. I 
think its irresponsible to turn off a major security/stability improvement for 
any reason, I'm leaving it on. Comments?
  

rewrote Win32::API::Callback

[bulk 88]

I totally rewrote Win32::API::Callback. Its 95% (or 99%) Perl now. 1 old XSUB 
saved (every other one removed), 1 new XSUB, and 1 new C func is all the code 
in the XS file now and api.h isn't needed anymore for Win32::API::Callback. The 
XS file has 1 screenful of code now. There is no machine or asm code in the XS 
file for portability. No subs removed from Callback.pm I think. A couple new 
subs in Callback.pm. No public API changes. The rewrite allows a x64 version to 
be made much more easily now (I dont think I will try it tho). Original tests 
all pass now except for the flawed ctrl-c test (jim shaw.t how works perfectly 
after its use of non-public API of Win32::API was removed). Here is the 
problem. I (in hindsight wasted time) fixed the old "regexs in C without 
regexes copy pasting random machine code nightmare" a couple times already to 
make it uncrashable for me. So the old code "works" now but I've tossed it. I 
still have a copy of the old fixed Win32::API::Callback before I rewrote it. 
What should I do with the old Win32::API::Callback XS code? Anyone want it? Put 
it a separate folder and change the makefile.pl to makefile.pl.old so EUMM 
doesn't find it?
  

RE: rewrote Win32::API::Callback

[bulk 88]

> Please send your Win32::API::Callback to libwin32@.
> I will at least pick it up and put it in our github repository.
> I'm not asking you to fork the repository because
> IIRC I read somewhere that you don't use source control :)
>
> --
> Cosimo

I'm getting bogged down in the x64 part of rewrite Win32::API::Callback. So I 
think I will gather my Win32::API (not ::Callback) changes organize them into a 
clean patch and send them off to you. They will help alot more people than the 
experimental ::Callback. Getting the ::API patch organized and ready to publish 
should take a day or 2.
  

Win32::API::Struct's tests generate garbage structs

[bulk 88]

I ran into a problem. I made another improvement to Win32::API, in ::Struct, to 
fix this div by zero, http://perlmonks.org/?node_id=978667 . No changes to 
recognize(), since recognize already has a way
to signal failure, its just typedef() didn't check for failure before. 
recognize() indicated failure by returning a list with 1 undef, rather than the 
non-error list with 3 elements. The undefs/missing array elements later become 
0s which after that become div by 0s.
_
sub typedef {
    my $class  = shift;
    my $struct = shift;
    my ($type, $name, @recog_arr);
    my $self = {
    align   => undef,
    typedef => [],
    };
    while (defined($type = shift)) {
    $name = shift;
    $name =~ s/;$//;
    @recog_arr = recognize($type, $name);
#http://perlmonks.org/?node_id=978468, not catching the type not found here,
#will lead to a div 0 later
    if(@recog_arr != 3){ 
    warn "Win32::API::Struct::typedef: unknown member type=\"$type\", 
name=\"$name\"";
    return undef;
    }
    push(@{$self->{typedef}}, [@recog_arr]);
    }

    $Known{$struct} = $self;
    return 1;
}
_
the problem is 05_more_struct.t now fails its tests, specifically, 
_
C:\Documents and Settings\Owner\Desktop\cpan libs\Win32API\wrkinprog>perl ./t/05
_more_struct.t
1..28
ok 1 - "all_longs" struct defined
ok 2 - Size of struct "all_longs" is calculated correctly (20)
ok 3 - "array_of_chars" struct defined
ok 4 - Size of struct "array_of_chars" is calculated correctly (100)
ok 5 - "compound_1" struct defined
ok 6 - Size of struct "compound_1" is calculated correctly (212)
ok 7 - "compound_2" struct defined
not ok 8 - Size of struct "compound_2" is calculated correctly (14) # TODO Break
s atm
#   Failed (TODO) test 'Size of struct "compound_2" is calculated correctly (14)
'
#   at ./t/05_more_struct.t line 131.
#  got: '14'
# expected: '11'
ok 9 - "empty" struct defined
ok 10 - Size of struct "empty" is calculated correctly (0)
Win32::API::Struct::typedef: unknown member type="\n", name="\n" at C:/perl512/s
ite/lib/Win32/API/Struct.pm line 46.
Unknown Win32::API::Struct 'empty_with_spaces' at ./t/05_more_struct.t line 125
not ok 11 - "empty_with_spaces" struct defined
#   Failed test '"empty_with_spaces" struct defined'
#   at ./t/05_more_struct.t line 126.
Can't call method "sizeof" on an undefined value at ./t/05_more_struct.t line 13
5.
# Looks like you planned 28 tests but ran 11.
# Looks like you failed 1 test of 11 run.
# Looks like your test exited with 2 just after 11.

C:\Documents and Settings\Owner\Desktop\cpan libs\Win32API\wrkinprog>

if I comment out
_
    empty_with_spaces => {
    typedef => [qw(  \n   \n  )],
    sizeof  => 0,
    },
_
in 05_more_struct.t, 05_more_struct.t passes all its tests.

Since you (Cosimo) originally wrote 05_more_struct.t (I assume, per 
https://github.com/cosimo/perl5-win32-api/commit/99a1506e8a941f9625ead648c207f4639f9cbf07#t/05_more_struct.t
 ), I ask, what should I do?

Some ideas,
-make empty_with_spaces pass its tests (a 0 length struct is created 
successfully) at any cost (no idea how to implement, some kind of whitespace 
stripper/normalizer regex before passing off the string to defined/while?)
-remove empty_with_spaces test, note "empty" works fine with the new ::Struct
-or you (Cosimo) have your own idea how to fix this?

This email is going to Cosimo and libwin32 mailing list, anyone can give their 
opinion.
  

"Win32::API::Callback::IATPatch" name for DLL/SO hooker for Win32::API

[bulk 88]

I have decided to add import table hook/patching to 
http://search.cpan.org/~bulkdd/Win32-API-0.70_02/Callback.pm . The technique is 
old (an example http://sandsprite.com/CodeStuff/Understanding_imports.html ), 
but has never been available to Perl Code before. Import table hooking  allows 
a user to use Win32::API::Callback callbacks to intercept the function call 
from   DLL (shared library) (the importer) to another DLL (the exporter), on 
the importer side. This will allow a syscall/OS call to be hooked using Perl 
and Perl code is used to implement the original C function call, or intercept 
and modify the arguments and return value from the caller to the callee 
function. The hooking is done, and undone on demand during runtime. Most 
people's, or atleast my typical usage of the feature, callstack wise will be,

OS process start->runops/Perl code in Perl->XS or Perl Core call to imported C 
function or syscall->Win32::API::Callback::IATPatch patch to import table of XS 
lib or perl core interp->Win32::API::Callback's C/Asm code->runops/Perl sub in 
Perl->Win32::API->original imported function

I thought of the name Win32::API::Callback::IATPatch. 
Win32::API::Callback::IATPatch is package/class name, but not a separate PM 
file.  Win32::API::Callback::IATPatch is implemented entirely in 
Win32:::API::Callback's XS code. Does anyone have anything against this name or 
a better suggestion?

Other names I though of are Win32:::API::Callback::ImportPatch, 
Win32:::API::Callback::Patch, Win32::API::Callback::Hook, and 
Win32::API::Callback::Intercept.
  

RE: "Win32::API::Callback::IATPatch" name for DLL/SO hooker for Win32::API

[bulk 88]

> To: libwin32@perl.org; bul...@hotmail.com; j...@activestate.com
> Subject: Re: "Win32::API::Callback::IATPatch" name for DLL/SO hooker for 
> Win32::API
> Date: Wed, 29 Aug 2012 16:09:48 +0200
> From: cos...@streppone.it
> 
> Hi,
> 
> I think it's great that you're trying to push Win32::API forward.
> 
> However, having 2 separate Win32::API releases in CPAN
> is not good IMHO, because it creates confusion in users.
> (Which version should I try? What's the advantage of running one or the  
> other?)
> 
> Do you have your source tree anywhere public?
> 
> IIRC I invited you to contribute to the github repository on
> https://github.com/cosimo/perl5-win32-api.
> 
> That's still valid. I don't have resources and energy
> to test Win32::API on the set of platforms and compilers
> required for a "quality" release anymore, but if we
> try to converge towards one single tree/release, then
> we can get help from others too.
> 
> Opinions?
> 
> -- 
> Cosimo

My code lives at https://github.com/bulk88/perl5-win32-api . I absolutely would 
like to merge it in/make it the official Win32::API on CPAN, tell me your plan. 
.69 and .70 commits are fully working and tested on 32/64 times VC/Mingw Perl 
permutations and are CPAN grade (crash/bug wise) I wouldn't release them now 
(8-29-2012) since I did a backwards breaking change in 0.71 on UseMI64 method 
(you can release them, its upto you, aslong as the metadata/manifest are fixed 
up first, I didn't do that, I intended for .69 and .70 to be public). The 
commits since the .70 I wouldn't consider releasing to CPAN since I dont think 
I tested them on all Perl/Win platforms. I guess you want me to do a "pull 
request" on your username's repo on github? I'm very new to git.

Right now I have the IATPatch and other small changes that are uncommitted to 
git on my machine, last 3 things todo before IATPatch is ready for public 
consumption is.

1. figure out what to do if IATPatch encounters a ordinal import and how to 
detect an ordinal import table
2. x64 testing (no idea what will happen or if it will compile)
3. write docs for IATPatch, I am not sure where to place them, I plan to add 
them to Callback.pm, ::IATPatch is 100% XS and loaded with "use 
Win32::API::Callback", so an IATPatch.pm would be just POD and couldn't be 
"use"d.

 IATPatch will become Win32::API CPAN 0.71 in my book since its a large amount 
of new functionality (IATPatch). IATPatch's final complete test file passes on 
32 bit windows with VC Perl at the moment.

Here is IATPatch, no docs, http://pastebin.com/STHMyisc . Your opinion on the 
API interface, and specifically the various error numbers I chose for various 
conditions would be appreciated. I also asked for some API design advice here 
http://perlmonks.org/?node_id=987866 and incorporated some of the ideas into 
the future 0.71. Some DLLs might be the result of PE packers/other tricks, so 
alot of sanity checking was put in on parsing the PE file in IATPatch.

I never called IATPatch, "Patch", because something like MS Detours (source 
available, but not FOSS, will never be added to Win32::API) could be added one 
day that is capable of installing the hook in the exporting DLL .text section 
at the start of the function's asm code. MS calls this "hotpatching", but if 
there isn't space for a jmp asm op reserved (hot patch compliant), it becomes 
impossible to call the original function that was hooked unless you relocate 
the first, or first couple asm ops to a new memory block, but the asm ops that 
were relocated often use RIP addressing, so the patcher has to have a full 
knowledge of x64 and 32 bit asm opcodes for opcode size and operand fixups, 
also the patcher must not make the cut in the middle of an operand of an opcode 
when deciding what to relocate. Adding something that I described above would 
almost surely be a GPL or LGPL (not artistic) 3rd party C library which XS 
wrappers would be written around. I looked a little bit at something FOSS 
called EazyHook, but self written IATPatch is all I needed for my own personal 
use.

Also someone will have to get ActiveState to stop patching (and failing to 
patch) Win32::API::Callback so newer Win32::API CPAN releases start to build on 
PPM 
http://ppm4.activestate.com/MSWin32-x86/5.14/1400/C/CO/COSIMO/Win32-API-0.68.d/log-20120416T192317.txt
 .
  

RE: "Win32::API::Callback::IATPatch" name for DLL/SO hooker for Win32::API

[bulk 88]

> From: bul...@hotmail.com
> To: cos...@streppone.it; libwin32@perl.org; j...@activestate.com
> Subject: RE: "Win32::API::Callback::IATPatch" name for DLL/SO hooker for 
> Win32::API
> Date: Wed, 29 Aug 2012 18:48:34 -0400
>
>
>
>
> > To: libwin32@perl.org; bul...@hotmail.com; j...@activestate.com
> > Subject: Re: "Win32::API::Callback::IATPatch" name for DLL/SO hooker for 
> > Win32::API
> > Date: Wed, 29 Aug 2012 16:09:48 +0200
> > From: cos...@streppone.it
> >
> > Hi,
> >
> > I think it's great that you're trying to push Win32::API forward.
> >
> > However, having 2 separate Win32::API releases in CPAN
> > is not good IMHO, because it creates confusion in users.
> > (Which version should I try? What's the advantage of running one or the
> > other?)
> >
> > Do you have your source tree anywhere public?
> >
> > IIRC I invited you to contribute to the github repository on
> > https://github.com/cosimo/perl5-win32-api.
> >
> > That's still valid. I don't have resources and energy
> > to test Win32::API on the set of platforms and compilers
> > required for a "quality" release anymore, but if we
> > try to converge towards one single tree/release, then
> > we can get help from others too.
> >
> > Opinions?
> >
> > --
> > Cosimo
>
> My code lives at https://github.com/bulk88/perl5-win32-api . I absolutely 
> would like to merge it in/make it the official Win32::API on CPAN, tell me 
> your plan.

I haven't heard from you since my last post a month ago. I've submitted a pull 
request ( 
https://github.com/cosimo/perl5-win32-api/pulls?direction=desc&page=1&sort=created&state=open
 ) to you github a month ago, but there was no response to date. I am 
requesting that you either incorporate my changes and make a new CPAN release, 
or give me COMAINT on Win32::API (PAUSE ID is BULKDD). I am also forwarding 
this message to modu...@perl.org.
  

RE: "Win32::API::Callback::IATPatch" name for DLL/SO hooker for Win32::API

[bulk 88]

> To: bul...@hotmail.com
> CC: libwin32@perl.org; modu...@perl.org
> Subject: Re: "Win32::API::Callback::IATPatch" name for DLL/SO hooker for 
> Win32::API
> Date: Sun, 14 Oct 2012 21:25:31 +0200
> From: cos...@streppone.it
>
> On Sun, 14 Oct 2012 21:12:50 +0200, Cosimo Streppone 
> wrote:
>
> > I'll have a look at your pull request and
> > reply within 24 hours.
>
> Your pull request is now fully merged.
> I have looked at the commits and it's clear
> that this is way over my head now.
>
> I think it makes sense to give you co-maint of Win32::API.
> Your CPAN id is BULKDD, right?
>
> In the meantime, I pushed 0.71 to CPAN.
>
> --
> Cosimo

My CPAN ID is BULKDD see http://search.cpan.org/~bulkdd/ . It is a derivative 
of my online username bulk88. There is an unauthorized release of Win32::API 
there so that account is me. Also the unauth release did get a PASS cpantesters 
report, 
http://www.cpantesters.org/cpan/report/f87f09c0-3a6b-1015-863c-2ca505085451 . 
My plans in the near future once I get the pause permission is to close the 
fixed tickets on CPAN RT if that is ok. Thank you for the CPAN release. My goal 
is to get feedback or bug reports for all my changes to Win32::API from the 
public.
  

RE: "Win32::API::Callback::IATPatch" name for DLL/SO hooker for Win32::API

[bulk 88]

> Subject: RE: "Win32::API::Callback::IATPatch" name for DLL/SO hooker for 
> Win32::API
> Date: Mon, 15 Oct 2012 08:50:11 +0100
> From: steve@verosoftware.com
> To: bul...@hotmail.com; cos...@streppone.it
> CC: libwin32@perl.org
>
> Great to see this released to CPAN, but a small patch of mine for
> skipping tests when fork() is not available was missed.
>
> I produced it in the course of testing [perl #33096], and the patch was
> attached there. I've attached it here too for convenience. Would you
> like me to log a CPAN ticket for this, or will you take it from here?

I have the patch in my local git working directory. I saw your patch from Perl 
RT and did add it immediately. I didn't see a reason to up the version number 
and make a new cpan release since it wasn't a large amount of changes yet. If 
its important to you to have a CPAN copy that has the fork fix immediately, I'm 
all for it. Should I sync my working dir with the github and do another pull, 
should I or cosimo up the version number if you want a new CPAN release right 
now?
  

RE: "Win32::API::Callback::IATPatch" name for DLL/SO hooker for Win32::API

[bulk 88]

> From: bul...@hotmail.com
> To: steve@verosoftware.com; cos...@streppone.it
> CC: libwin32@perl.org
> Subject: RE: "Win32::API::Callback::IATPatch" name for DLL/SO hooker for 
> Win32::API
> Date: Mon, 15 Oct 2012 04:18:39 -0400
> I have the patch in my local git working directory. I saw your patch from 
> Perl RT and did add it immediately. I didn't see a reason to up the version 
> number and make a new cpan release since it wasn't a large amount of changes 
> yet. If its important to you to have a CPAN copy that has the fork fix 
> immediately, I'm all for it. Should I sync my working dir with the github and 
> do another pull, should I or cosimo up the version number if you want a new 
> CPAN release right now?
>
I submitted a pull request with the patch/snapshot of my local directory to 
cosimo rep since I'll be offline for next couple hours. If it is decided 
between you 2 (Cosimo, Steve) to not merge/apply the pull request/patch at this 
moment, I will delete/append the commit eventually the next time I do more 
substantial changes (something like 3-4 bug fixes and 0-2 new features) to 
Win32::API.
  

RE: [Win32-API] CPAN Testers Daily Summary Report

[bulk 88]

> To: libwin32@perl.org
> CC: steve@verosoftware.com; bul...@hotmail.com
> Subject: Re: Fwd: [Win32-API] CPAN Testers Daily Summary Report
> Date: Tue, 16 Oct 2012 08:08:42 +0200
> From: cos...@streppone.it
>
> On Tue, 16 Oct 2012 07:30:05 +0200, Cosimo Streppone 
> wrote:
>
> > Test failure report coming in for 0.71.
> > I still have to apply Steve's patch...
>
> And... 0.72 on its way to CPAN now.
>
> https://github.com/cosimo/perl5-win32-api/tree/0.72
>
> --
> Cosimo

Reading 
http://www.cpantesters.org/cpan/report/15122d17-6bf7-1014-b570-655f7b11b24e I 
dont think that fork detection was an issue in that test report. I dont think 
that that was a no fork perl based on the perl -V in the report. That also was 
not the exotic 32 bit perl with native quads Mingw build (which I predict will 
fail on Win32::API .71). It was a 64 bit strawberry perl. The Callback.dll 
never loaded into the process. In the test report I see "load_file:DLL ÃʱâÈ­ 
·çƾÀ» ½ÇÇàÇÒ ¼ö ¾ø½À´Ï´Ù ". What happened there with Dynaloader? Looking at 
Callback's DllMain ( 
https://metacpan.org/source/COSIMO/Win32-API-0.71/Callback/Callback.xs#L49 ), I 
dont see anything would cause an access vio. To make sure I'm not crazy, I 
reran .71 on my 64 bit strawberry perl and it worked. I'm not sure what to do 
about that report. 
_
C:\Documents and Settings\Administrator\Desktop\w32api71\p>dmake test
cp Type.pm blib\lib\Win32/API/Type.pm
cp Callback.pm blib\lib\Win32/API/Callback.pm
cp Test.pm blib\lib\Win32/API/Test.pm
cp Struct.pm blib\lib\Win32/API/Struct.pm
cp API.pm blib\lib\Win32/API.pm
cp IATPatch.pod blib\lib\Win32/API/Callback/IATPatch.pod
C:\sperl\perl\bin\perl.exe C:\sperl\perl\lib\ExtUtils\xsubpp  -typemap C:\sperl\
perl\lib\ExtUtils\typemap  Callback.xs > Callback.xsc && C:\sperl\perl\bin\perl.
exe -MExtUtils::Command -e mv -- Callback.xsc Callback.c
gcc -c  -ggdb -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS
 -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-ali
asing -mms-bitfields -O2  -DVERSION=\"0.71\"    -DXS_VERSION=\"0.71\"  "
-IC:\sperl\perl\lib\CORE"   Callback.c
Running Mkbootstrap for Win32::API::Callback ()
C:\sperl\perl\bin\perl.exe -MExtUtils::Command -e chmod -- 644 Callback.bs
C:\sperl\perl\bin\perl.exe -MExtUtils::Mksymlists \
 -e "Mksymlists('NAME'=>\"Win32::API::Callback\", 'DLBASE' => 'Callback', 'D
L_FUNCS' => {  }, 'FUNCLIST' => [], 'IMPORTS' => {  }, 'DL_VARS' => []);"
dlltool --def Callback.def --output-exp dll.exp
g++ -o ..\blib\arch\auto\Win32\API\Callback\Callback.dll -Wl,--base-file -Wl,dll
.base -mdll  -L"C:\sperl\perl\lib\CORE" -L"C:\sperl\c\lib" Callback.o   C:\sperl
\perl\lib\CORE\libperl514.a -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -l
comdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmp
r -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 dll.exp
dlltool --def Callback.def --base-file dll.base --output-exp dll.exp
g++ -o ..\blib\arch\auto\Win32\API\Callback\Callback.dll -mdll  -L"C:\sperl\perl
\lib\CORE" -L"C:\sperl\c\lib" Callback.o   C:\sperl\perl\lib\CORE\libperl514.a -
lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32
 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32
-lodbccp32 -lcomctl32 dll.exp
C:\sperl\perl\bin\perl.exe -MExtUtils::Command -e chmod -- 755 ..\blib\arch\auto
\Win32\API\Callback\Callback.dll
C:\sperl\perl\bin\perl.exe -MExtUtils::Command -e cp -- Callback.bs ..\blib\arch
\auto\Win32\API\Callback\Callback.bs
C:\sperl\perl\bin\perl.exe -MExtUtils::Command -e chmod -- 644 ..\blib\arch\auto
\Win32\API\Callback\Callback.bs
C:\sperl\perl\bin\perl.exe C:\sperl\perl\lib\ExtUtils\xsubpp  -nolinenumbers  -t
ypemap C:\sperl\perl\lib\ExtUtils\typemap -typemap typemap  API.xs > API.xsc &&
C:\sperl\perl\bin\perl.exe -MExtUtils::Command -e mv -- API.xsc API.c
gcc -c  -ggdb -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS
 -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-ali
asing -mms-bitfields -O2  -DVERSION=\"0.71\"    -DXS_VERSION=\"0.71\"  "
-IC:\sperl\perl\lib\CORE"   API.c
as  call_asm_x64_gnu.s -o call_asm_x64_gnu.o
Running Mkbootstrap for Win32::API ()
C:\sperl\perl\bin\perl.exe -MExtUtils::Command -e chmod -- 644 API.bs
C:\sperl\perl\bin\perl.exe -MExtUtils::Mksymlists \
 -e "Mksymlists('NAME'=>\"Win32::API\", 'DLBASE' => 'API', 'DL_FUNCS' => {
}, 'FUNCLIST' => [], 'IMPORTS' => {  }, 'DL_VARS' => []);"
dlltool --def API.def --output-exp dll.exp
g++ -o blib\arch\auto\Win32\API\API.dll -Wl,--base-file -Wl,dll.base -mdll  -L"C
:\sperl\perl\lib\CORE" -L"C:\sperl\c\lib" API.o call_asm_x64_gnu.o   C:\sperl\pe
rl\lib\CORE\libperl514.a -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcom
dlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_

RE: "Win32::API::Callback::IATPatch" name for DLL/SO hooker for Win32::API

[bulk 88]

> From: j...@activestate.com
> To: bul...@hotmail.com; cos...@streppone.it; libwin32@perl.org; 
> modu...@perl.org; cos...@cpan.org
> Subject: RE: "Win32::API::Callback::IATPatch" name for DLL/SO hooker for 
> Win32::API
> Date: Mon, 15 Oct 2012 13:33:55 -0700
>
> On Sun, 14 Oct 2012, bulk 88 wrote:
>>
>> I haven't heard from you since my last post a month ago.
>
> Sorry, I didn't have time to look at this in details. My gut
> feeling is that API hooking should be in a separate module, not
> not jammed into Win32::API. But this is not a fully informed
> opinion, so if e.g. implementation sharing makes this more
> convenient, then that may be a good reason to do so.
>
The post you replied to was mostly intended to Cosimo, not you. But lets go on.

::IATPatch is a class that is implemented in Callback.dll. Its full name is 
Win32::API::IATPatch and it is OO. It has no Perl code. Currently ::IATPatch 
peeks inside a ::Callback non publically.

Also many provisions or future changes (I have no plans to implement them ATM) 
would require ::IATPatch or (future) sister classes to use private API of other 
parts of Win32::API. ::IATPatch has proposed method, in a src comment, to 
create a Win32::API automatically from a Win32::API::Callback. Also if a 
Win32::API::HMODULE class is ever created for proper refcounting of DLLs, 
::IATPatch *may* need to use it, and it probably will be 100% internal to 
Win32::API with no public exposure. If something like MS Detours or a FOSS 
clone of it is ever added to Win32::API, it would need ::Callback's private API 
just as ::IATPatch does now.

::IATPatch is really small. It has no Perl code,  1 C func 0x2a3,  2 1 line 
method XSUBs 0x33+0xA2, 1 DESTROY XSUB 0xCD, 1 constructor XSUB 0x248, and 1 
other xsub 0x173, for a total of 0x7a0, 1952 bytes of 32 bit machine code, 
string literals and everything else excluded. Callback.dll is 10KB. ::IATPatch 
is not large enough to need a separate DLL.

Are you concerned about any security issues with adding API hooking to the 
Win32::API distribution?
  

ActiveState's PPM distropref patch of Win32::API

[bulk 88]

ActiveState has been patching Win32::API since API 0.58 to today (with patch 
http://ppm4.activestate.com/MSWin32-x86/5.10/1000/C/CO/COSIMO/Win32-API-0.58.d/log-20090527T160936.txt
 no patch 
http://ppm4.activestate.com/MSWin32-x86/5.10/1000/C/CO/COSIMO/Win32-API-0.57.d/log-20081017T081820.txt
 ) so the Win32::API::Callback tests are skipped since they used to crash on 
90% of compilers. Since API 0.65 the patch has failed (see 
http://ppm4.activestate.com/MSWin32-x86/5.14/1400/C/CO/COSIMO/Win32-API-0.65.d/log-20120213T025817.txt
 ) to apply because of a code formater being run on Win32::API between 0.64 and 
0.65 in this commit 
https://github.com/cosimo/perl5-win32-api/commit/ebbafaffc6b2c895c7a73bfa8d6e0ce97ec2a39a#L2L55
 . Can something please be done by ActiveState to stop the PPM build farm from 
trying to patch Win32::API?
  

RE: ActiveState's PPM distropref patch of Win32::API

[bulk 88]

> Date: Fri, 26 Oct 2012 16:40:30 -0700
> Subject: Re: ActiveState's PPM distropref patch of Win32::API
> From: j...@activestate.com
> To: bul...@hotmail.com
> CC: libwin32@perl.org
>
> I've removed the Win32-API distroprefs from the PPM build system and
> pushed the change to all Windows builders. I've then forced a rebuild
> of the latest Win32-API (0.73), and the builds all succeeded without
> problems. So the vestigial traces in the files to keep the patch
> working can now be removed.
>
> Cheers,
> -Jan

Thanks.
  

RE: [rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t - invalid unpack type

[bulk 88]

> Date: Mon, 5 Nov 2012 09:39:57 -0600
> Subject: Re: [rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t - 
> invalid unpack type
> From: rur...@x-ray.at
> To: bul...@hotmail.com
> CC: libwin32@perl.org
>
> On Sat, Nov 3, 2012 at 12:38 AM, bulk 88  wrote:
> > 
> >> From: jdhed...@cpan.org
> >> Date: Fri, 2 Nov 2012 10:44:05 -0400
> >> Subject: Re: [rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t - 
> >> invalid unpack type
> >> To: bul...@hotmail.com
> >> CC: rur...@x-ray.at
> >>
> >> I leave the debugging part to you, and possibly Reini and/or the
> >> Cygwin team, as all this is Greek to me. I just had the (mis)fortune
> >> of being the first to discover the issue. You may, of course, still
> >> call upon me to perform testing and send back results if needed. Good
> >> Luck.
> >
> > Can you run this script and send back the output with CPAN Win32::API .73 
> > or any .73 github derivative I've made so far?
>
> Sure, but I cannot reproduce the bugs.
> Only t/undef.t test 2 is failing on my cygwin non-threaded.
> And I needed to fix the Callback DESTROY #if identation from
> https://github.com/cosimo/perl5-win32-api/pull/6
> non-threaded needs to skip the t/threading_fails.t tests also.
>
> non-threaded:
> $ alias p
> alias p='/usr/local/bin/perl5.16.2d-nt.exe'
> $ alias pb
> alias pb='p -Iblib/arch -Iblib/lib'
> $ pb t/GetContext.pl
> $VAR1 = "?\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\177\2\377\377
> \0\377\377\377\377\377\377\177\377\24X\e\0\0\0pe-X#\0\377\377\210\225\"\0x\227\"\0\0\0\1\0\0\0(\233\nax\227\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\254\201\1
> \25\0\0\0\0\0\0\0\0\0\0\0\0\200\377?\0\0\0\0\374\377\377\377\34\@\0\0\0\0\0\0\0\0;\0\0\0#\0\0\0#\0\0\0_\36\32a\0\0\0\0\300\246\"\0\4\0\0\0\0\0\0\0\270\245\"\0\b\246\"\0\373*\201|\e\0\0\0F\2\0\0\264\245\"\0#\0\0\0\177\2
> \0\0\0\0\0\177\377\24X\e\0\0\0pe-X#\0\0\0\200\37\0\0\377\377\0\0\210\225\"\0x\227\"\0\0\0\0\0\0\0\0\0\1\0\0\0(\233\nax\227\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\254\201\1
> \25\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\200\377?\0\0\0\0\0\0\0\0\0\0\374\377\377\377\34\@\0\0\0\0\0\0\200\251\"\0_\300\16a#\0;\0\0\0#\0\200\251\"\0_\300\16a#\0;\0\0\0#\0D\377\"\0`\16\240_\0\0__register_frame_info\0\0\252\"\0\0\0\0\0\0\0\0\0\260_'a\0\0\0\\0<\0\310\222'a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\344}\310\16\267_\315\1qG\"\302A\271\315\1>\340\312\16\267_\315\1>\340\312\16\267_\315\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20(\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\nA\202\0\0\0\0\0\0\0\0\0\0\0\0\0
> \224\32a\303\0\0\0
> \224\32a\343z\0a\0\0\0\0\0\0\0\0<\246\"\0\234\226\"\0x\227\"\0\1\0\0\0\1\0\0\0\0\1\0\0\270\201\2
> \30\230\"\0\@\225\"\0q\230\na#\0;\0\0\0#\0D\377\"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0";
>
> threaded:
> $ alias p
> alias p='perl5.16.2d'
>
> $VAR1 = "?\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\177\2\377\377
> \0\377\377\377\377\377\377\0\322\26X\e\0\0\0\260t1X#\0\377\377\1\0\0\0(\233\nax\227\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\254\201\1
> \25\0\0\0\0\0\20(\0\0\@\0\0\0\377\0\0\0\0\0\0\0\0\200\377?\0\0\0\0\374\377\377\377\34\@\0\0\0\0\0\0\0\0;\0\0\0#\0\0\0#\0\0\0[\36\32a\0\0\0\0\260\246\"\0\4\0\0\0\0\0\0\0\230\245\"\0\350\245\"\0\373*\201|\e\0\0\0F\2\0\0\224\245\"\0#\0\0\0\177\2
> \0\0\0\0\0\0\322\26X\e\0\0\0\260t1X#\0\0\0\200\37\0\0\377\377\0\0\1\0\0\0(\233\nax\227\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\254\201\1
> \25\0\0\0\0\0\0\0\0\0\0\0\20(\0\0\@\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\200\377?\0\0\0\0\0\0\0\0\0\0\374\377\377\377\34\@\0\0\0\0\0\0D\377\"\0`\16\240_\0\0__regiD\377\"\0`\16\240_\0\0__register_frame_info\0\0\252\"\0\0\0\0\0\0\0\0\0\260_'a\0\0\0\\0<\0\@\223'a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\344}\310\16\267_\315\1qG\"\302A\271\315\1>\340\312\16\267_\315\1>\340\312\16\267_\315\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20(\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\nA\202\0\0\0\0\0\0\0\0\0\0\0\0\0
> \224\32a\303\0\0\0
> \224\32a\343z\0a\0\0\0\0\0\0\0\0<\246\"\0\234\226\"\0x\227\"\0\1\0\0\0\1\0\0\0\0\1\0\0\270\201\2
> \30\230\"\0\@\225\"\0q\230\na#\

RE: Perl's Win32::API on MSYS

[bulk 88]

> Date: Tue, 1 Oct 2013 18:20:40 +0200 
> From: cos...@cpan.org 
> To: libwin32@perl.org 
> Subject: Fwd: Re: Perl's Win32::API on MSYS 
>  
> Hi folks, 
>  
> can anyone have a look at this pull request 
> from Sebastian for Win32::API? 
>  
> It is about cygwin support AFAICS. 
> I'd appreciate your comments on the pull request. 
>  
>  Original Message  
> Subject:Re: Perl's Win32::API on MSYS 
> Date:   Tue, 1 Oct 2013 10:13:02 +0200 
> From:   Sebastian Schuberth  
>  
> To: Cosimo Streppone  
>  
>  
>  
> On Tue, Oct 1, 2013 at 10:07 AM, Cosimo Streppone 
>  wrote: 
>  
> > On 09/19/2013 01:53 PM, Sebastian Schuberth wrote: 
> >> Looks like my SUPER doe snot have a cflags function. How can that be, 
> >> is my ExtUtils::MM_Win32 too old? 
> > 
> > Sorry, but I have no really useful idea. 
> > Try to upgrade or send a message to 
> > libwin32@perl.org. 
>  
> Nevermind, I tried to work around this in this pull request: 
>  
> https://github.com/cosimo/perl5-win32-api/pull/10 
>  
> --  
> Sebastian Schuberth 
>


The commit looks very broken. var $dlib becomes an undeclared  global. I did 
test Win32::API with 
Visual C Perl 5.6 with 
__
package ExtUtils::MakeMaker;

BEGIN {require 5.005_03;}

$VERSION = '6.17';
($Revision) = q$Revision: 1.133 $ =~ /Revision:\s+(\S+)/;

require Exporter;
use Config;
use Carp ();
use File::Path;
_

How old is the MakeMaker your Msys Perl is using? What compiler and what 
version was Msys Perl
 made with? Its GCC something probably but what version?

The Makefile.PL code has to be able to remove compiler flags and add compiler 
flags, it also
has to see some -D defines on some compiler/platforms.  
  

RE: Perl's Win32::API on MSYS

[bulk 88]

> Date: Wed, 2 Oct 2013 10:11:47 +0200
> Subject: Re: Perl's Win32::API on MSYS
> From: sschube...@gmail.com
> To: bul...@hotmail.com
> CC: cos...@cpan.org; libwin32@perl.org
>
> On Wed, Oct 2, 2013 at 8:37 AM, bulk 88  wrote:
>
>> How old is the MakeMaker your Msys Perl is using? What compiler and what 
>> version was Msys Perl
>> made with? Its GCC something probably but what version?
>
> MSYS Perl currently ships with MakeMaker 6.30, GCC 3.4.4 and Perl 5.8.8.
>
Are you sure your MSYS Perl includes the file MM_Win32.pm on disk? Is your MSYS 
Perl the
Perl bundled with current official MSYS git packages?

Also, AFAIK, if a method isn't implemented in MM_Win32.pm, it falls back to 
MM_Unix.pm. A
Win32 MakeMaker makefile is made from a mix of methods from different .pms. 
MM_Unix implements
cflags method, so shouldn't that be getting called instead of the Win32 
specific cflags method if 
Win32 specific cflags method doesn't exist? 
  

RE: Perl's Win32::API on MSYS

[bulk 88]

> From: bul...@hotmail.com
> To: sschube...@gmail.com
> CC: cos...@cpan.org; libwin32@perl.org
> Subject: RE: Perl's Win32::API on MSYS
> Date: Thu, 3 Oct 2013 08:23:34 -0400
>
> 
>> Date: Wed, 2 Oct 2013 10:11:47 +0200
>> Subject: Re: Perl's Win32::API on MSYS
>> From: sschube...@gmail.com
>> To: bul...@hotmail.com
>> CC: cos...@cpan.org; libwin32@perl.org
>>
>> On Wed, Oct 2, 2013 at 8:37 AM, bulk 88  wrote:
>>
>>> How old is the MakeMaker your Msys Perl is using? What compiler and what 
>>> version was Msys Perl
>>> made with? Its GCC something probably but what version?
>>
>> MSYS Perl currently ships with MakeMaker 6.30, GCC 3.4.4 and Perl 5.8.8.
>>
> Are you sure your MSYS Perl includes the file MM_Win32.pm on disk? Is your 
> MSYS Perl the
> Perl bundled with current official MSYS git packages?
>
> Also, AFAIK, if a method isn't implemented in MM_Win32.pm, it falls back to 
> MM_Unix.pm. A
> Win32 MakeMaker makefile is made from a mix of methods from different .pms. 
> MM_Unix implements
> cflags method, so shouldn't that be getting called instead of the Win32 
> specific cflags method if
> Win32 specific cflags method doesn't exist?

tested cosimo head "SHA-1: c5f9fcc6df4ba00c65392576eaf0e66965ff9ece * Merge 
pull request #9 from sschuberth/master
Add support for building on MSYS in addition to Cygwin" + some local changes of 
mine, it didn't build on my 5.6
with MakeMaker 6.17 due to this makefile target which syntaxed errored with 
nmake. Correcting the "\" to be on the right
line made it compile/work (I need to work on MY::distdir). The methods are 
working on my Perl.
_
# --- MakeMaker distdir section:
distdir : metafile metafile_addtomanifest
    $(RM_RF) $(DISTVNAME)
    $(PERLRUN) "-MExtUtils::Manifest=manicopy,maniread" \
        -e "manicopy(maniread(),'$(DISTVNAME)', '$(DIST_CP)');"
"\
    && cd $(DISTVNAME) && chmod -v -x-x-x Makefile.PL && chmod -v -x-x-x 
./Callback/Makefile.PL

distdir : 
_   
  

RE: Perl's Win32::API on MSYS

[bulk 88]

> Date: Fri, 4 Oct 2013 15:23:36 +0200
> Subject: Re: Perl's Win32::API on MSYS
> From: sschube...@gmail.com
> To: bul...@hotmail.com
> CC: cos...@cpan.org; libwin32@perl.org
>
> Which version of my pull request did you actually test? Did you merge
> / cherry-pick commit f9fb2c5 [1], including or excluding 7fa2bb5 [2]?
>
> [1] 
> https://github.com/sschuberth/perl5-win32-api/commit/f9fb2c599e5d9ae244be8fb4e971d57a13c0d38d
> [2] 
> https://github.com/sschuberth/perl5-win32-api/commit/7fa2bb5cce9d5ce15f23ef1c5f451d066c287f8a
>
> --
> Sebastian Schuberth

Neither, I tested Cosimo master branch which has 
bae930423e8951107aa50453cb47b800312da18a
"Add support for building on MSYS in addition to Cygwin" in its history.
  

RE: Perl's Win32::API on MSYS

[bulk 88]

> Date: Fri, 4 Oct 2013 15:59:30 +0200
> From: d...@perl.it
> To: libwin32@perl.org
> Subject: Re: Perl's Win32::API on MSYS
>
>
> I can only guess that the "package ExtUtils::MM_Win32" inside the
> MY::cflags sub confuses perl 5.8.8's notion of inheritance somehow...
>
> @bulk88: why is that line needed in first place?
>
>

So SUPER class works. My code has to get the original makefile chunk MM would 
have
put there and then manipulate it. But I tried to not be dependent on MM's 
design so I didn't
want to call  an absolute named method/sub so I switch packages in the sub and 
did a SUPER
call. The MY package doesn't inherit anything and I didn't think about adding 
anything to it
since MM cleans out the MY package after each WriteMakefile call which sounds 
unfriendly but
it does that. 

RE: Perl's Win32::API on MSYS

[bulk 88]

> Date: Mon, 7 Oct 2013 08:42:54 +0200
> From: d...@perl.it
> To: bul...@hotmail.com; libwin32@perl.org
> Subject: Re: Perl's Win32::API on MSYS
>
> but... this is done differently in ExtUtils::MakeMaker docs:
>
> http://search.cpan.org/~bingos/ExtUtils-MakeMaker-6.78/lib/ExtUtils/MakeMaker.pm#Overriding_MakeMaker_Methods
>
> in particular:
>
> package MY; # so that "SUPER" works right
> sub c_o {
> my $inherited = shift->SUPER::c_o(@_);
> # ...
> }
>
> I checked as back as CPAN goes (ExtUtils::MakeMaker 6.54 from 2009) and
> this was still the documented way of doing it, so it doesn't seem to be
> a new thing (and hopefully works on 5.8 too).
>
>
> cheers,
> Aldo

Changed the design in a branch 
https://github.com/bulk88/perl5-win32-api/tree/msys 
   

RE: Perl's Win32::API on MSYS

[bulk 88]

> Date: Thu, 10 Oct 2013 15:51:36 +0200
> Subject: Re: Perl's Win32::API on MSYS
> From: sschube...@gmail.com
> To: bul...@hotmail.com
> CC: d...@perl.it; libwin32@perl.org
>
> On Tue, Oct 8, 2013 at 12:26 PM, bulk 88  wrote:
>
>> Changed the design in a branch 
>> https://github.com/bulk88/perl5-win32-api/tree/msys
>
> I've checked out your "msys" branch and your commit at [1] seems to
> have fixed the MSYS build issues for me, "perl Makefile.PL && make"
> produces API.dll and Callback.dll just fine now. As this solution is
> much nicer than mine in the commit at [2], I'll split out the substr
> length fix to a separate pull request [3] and delete my original one
> at [4].
>
> @bulk88, any idea when your "msys" branch will be merged to cosimo's repo?
>
> [1] 
> https://github.com/bulk88/perl5-win32-api/commit/3ef519b70431eef01859f859b8a7c4ea3a457f3c
> [2] 
> https://github.com/sschuberth/perl5-win32-api/commit/f9fb2c599e5d9ae244be8fb4e971d57a13c0d38d
> [3] https://github.com/cosimo/perl5-win32-api/pull/11
> [4] https://github.com/cosimo/perl5-win32-api/pull/10
>
> --
> Sebastian Schuberth

Is  https://github.com/cosimo/perl5-win32-api/pull/11 a bug fix or just code 
cleanup/refactor? I think it is just
cleanup for prettyness.

In regards to #11, do you want your commit under your name or not in git? I 
don't care too much so its
upto you.

I plan to squash 
3ef519b70431eef01859f859b8a7c4ea3a457f3c "remove "package ExtUtils::MM_Win32;" 
uses" onto
the previous commit 865055254afb2161b0dc634fb11779fbecb15d0d "old < ~6.25 
MakeMakers made a bad makefile, Changes update for contribs". collapse your 
pull #11 commit onto those 2 and give you just changes file credit, or 
keep it a separate commit?

Merging to cosimo's repo isn't very important. He takes many weeks historically 
to do it. It
doesn't matter because both of use are COMAINT on CPAN so both us can release a 
new Win32::API
whenever we want. Currently there is alot of experimental code related to 
performance in 0.76 alpha series.
I haven't decided how much of it to keep. I also am very slowly working on 
__fastcall/__thiscall
support on x86-32. It is very complicated, because 

int add4things( double one, double two, int three,  __int64 four, int five, int 
six)

 in asm/machine code is actually called like 

int add4things( int three, int five, double one, double two, __int64 four, int 
six) 

args three and five go into ecx/edx, all other 4 byte args go on stack, which 
means the SV stack/@_ are now
to keep things sane has to be shifted around with per element offsets to make 
the later ecx/edx destined args
be first in the APIPARAM array.

So basically, when you respond, I'll squash the commits, then have cosimo merge 
it. Do you require a CPAN
release or can you live with a github checkout? 
  

RE: Perl's Win32::API on MSYS

[bulk 88]

> Date: Thu, 10 Oct 2013 21:31:41 +0200
> Subject: Re: Perl's Win32::API on MSYS
> From: sschube...@gmail.com
> To: bul...@hotmail.com
> CC: d...@perl.it; libwin32@perl.org
>
>
> I was hoping to make clear in the commit message that it actualy *is*
> a bug fix. The original code has
>
> length($dlib)-$pos+length('CCFLAGS = ')
>
> which should actually be
>
> length($dlib)-($pos+length('CCFLAGS = '))
>
> Note the parenthesis. In the same run I've simplified the code a bit
> to not recalculate $pos+length('CCFLAGS = ') multiple times.
>

You should've just said the 3rd param to substr was overflowing/larger than the 
size of the 2nd half of string being returned by the substr. What confused me 
was
there was no visible side effects of this bug, since substr will return upto 
the end
of the string, not pad it out, if you request more bytes than there are left in 
the string.

>
> As it's an unrelated bug fix I'd like to keep it as a separate commit.
> And also to maintain my authorship. Feel free to cherry-pick the
> commit. If it's of any help to you I can also create the same pull
> request for your fork.

Cherry picked. You're in the git log.

>
> Why squash the commits? Strictly spoken they are unrelated, because
> the one is about old MakeMaker versions (not necessarily from MSYS),
> and the other one for MSYS / old Perl compatibility. But it's of
> course up to you.
>

I like fatter commits rather than smaller. It makes the git history easier to 
understand 
and git being more responsive.

>
> I'd require a CPAN release. Maybe you could do something like a 0.75.1
> release which just adds MSYS support?
>

http://search.cpan.org/~bulkdd/Win32-API-0.76_04/   
  

RE: Perl's Win32::API on MSYS

[bulk 88]

> Date: Sat, 12 Oct 2013 21:37:35 +0200
> Subject: Re: Perl's Win32::API on MSYS
> From: sschube...@gmail.com
> To: bul...@hotmail.com
> CC: d...@perl.it; libwin32@perl.org
>
> On Sat, Oct 12, 2013 at 8:02 PM, bulk 88  wrote:
>
>>> I'd require a CPAN release. Maybe you could do something like a 0.75.1
>>> release which just adds MSYS support?
>>>
>>
>> http://search.cpan.org/~bulkdd/Win32-API-0.76_04/
>
> Thanks. But how can I make my CPAN install this? Just using "install
> Win32::API" still installs version 0.75.
>

Try "cpan[2]> install BULKDD/Win32/Win32-API-0.76_04.tar.gz". If you find
more bugs in 0.76 series please report them.