> 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
.
