From: Daniel Dragan via RT Tue Apr 09 22:28:45 2013: Request 84268 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeuchel@allgeier.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >


Closed.

From: Daniel Dragan via RT Tue Apr 09 01:09:13 2013: Request 84268 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeuchel@allgeier.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >


On Fri Mar 29 06:24:29 2013, keuchel@rainer-keuchel.de wrote:
> Here is the old code.. Unfortunatly there is no assembly magic. It
> just calls several functions with different numbers of args from 1
> to 10.
>

Thank you for the ARM code. Are you still having x86/x64 Win32::API problems or can I close the ticket?

From: Daniel Dragan via RT Tue Apr 09 01:05:23 2013: Request 81748 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: strawberry perl 5.8.9 with mingw.org gcc 3.4.5 alloca broken
Broken in: 0.74
Severity: Normal
Owner: Nobody
Requestors: BULKDD@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=81748 >


Fixed in 0.76_01. malloc.h is #included for the alloca define. Builds and passed on my strawberry on 5.8.9 but a different bug (can't load API.dll into the process) exists on some Perls with Mingw 3.4.5 compilers.

From: Daniel Dragan via RT Tue Apr 09 00:55:35 2013: Request 83191 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Win32::API doesn't keep C stack aligned on x64
Broken in: 0.75
Severity: Important
Owner: Nobody
Requestors: BULKDD@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83191 >


Fixed in 0.76_01. Test was added to api-test to check C stack alignment on x64.

From: Rainer Keuchel via RT Fri Mar 29 06:24:29 2013: Request 84268 was acted upon.
Transaction: Correspondence added by keuchel@rainer-keuchel.de
Queue: Win32-API
Subject: AW: [rt.cpan.org #84268] Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeuchel@allgeier.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >


Here is the old code.. Unfortunatly there is no assembly magic. It just calls several functions with different numbers of args from 1 to 10.


If you are the same Rainer Keuchel as in <http://tech.groups.yahoo.com/group/wince-devel/message/459> http://tech.groups.yahoo.com/group/wince-devel/message/459 , could you provide/attach what was in <http://www.rainer-keuchel.de/wince/perl-win32-api.tar.gz> http://www.rainer-keuchel.de/wince/perl-win32-api.tar.gz ? I'd like to integrate what was in there (ARM support) into the official Win32::API.

From: Daniel Dragan via RT Fri Mar 29 00:35:42 2013: Request 84268 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeuchel@allgeier.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >


On Thu Mar 28 17:11:32 2013, rkeuchel@allgeier.com wrote:
> It's really stdcall. Sorry, I should have checked this..
>
> Maybe I
> was biased because it worked in my old 5.14 ActiveState-Perl, which
> probably used the C version of "call" or an old asm version.
>
> I
> recompiled Win32::API for getting WriteMemory(), which was missing
> in the AS build.

If you are the same Rainer Keuchel as in http://tech.groups.yahoo.com/group/wince-devel/message/459 , could you provide/attach what was in http://www.rainer-keuchel.de/wince/perl-win32-api.tar.gz ? I'd like to integrate what was in there (ARM support) into the official Win32::API.

From: Daniel Dragan via RT Thu Mar 28 17:42:02 2013: Request 84268 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeuchel@allgeier.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >


On Thu Mar 28 17:11:32 2013, rkeuchel@allgeier.com wrote:
> It's really stdcall. Sorry, I should have checked this..

Then why does it crash for you if it really is stdcall?

>
> Maybe I
> was biased because it worked in my old 5.14 ActiveState-Perl, which
> probably used the C version of "call" or an old asm version.

Previous versions of Win32::API as far as I remember, didn't care if it was __cdecl or __stdcall, original esp from the XSUB is copied back in asm, "esp = *(void **)ebp; ebp = *(void **)esp; esp -= 4;" AKA "leave" or "mov esp, [ebp]; pop esp", so what the called C func left esp at was actually irrelevant (it can be esp == 0, and Call_asm didn't care).

>
> I
> recompiled Win32::API for getting WriteMemory(), which was missing
> in the AS build.

OT: "unpack('P'," can read any memory, but you can't write to random memory from core Perl. The undocumented RtlMoveMemory in kernel32.dll in old Win32::APIs (0.68 and older) had to be cludgingly used before. Internet grapevine says RtlMoveMemory exists for VB Classic programmers to use. So I added a WriteMemory so that foreign memory allocators can more easily be used (some C func wants a LocalAlloc memory block to take ownership of and free when it wants, not malloc or Newx (PV buffer)).

>
> And others also use the DLL from C# so I
> thought it would be stdcall..
>
>
> unsigned int __cdecl
> svapi_connect(...)
>
> push ebp
> mov ebp, esp
> push
> 0FFFFFFFEh
> push offset stru_1006F560
> push offset
> __except_handler4
> mov eax, large fs:0
> push eax
> add
> esp, 0FFFFFF68h
> mov eax, ___security_cookie
> xor
> [ebp+ms_exc.registration.ScopeTable], eax
> xor eax, ebp
> mov
> [ebp+var_24], eax
> push ebx
> push esi
> push edi
> push
> eax
> lea eax, [ebp+ms_exc.registration]
> mov large fs:0,
> eax
> mov [ebp+ms_exc.old_esp], esp
>
> ...
>
> mov ecx,
> [ebp+ms_exc.registration.Next]
> mov large fs:0, ecx
> pop
> ecx
> pop edi
> pop esi
> pop ebx
> mov ecx,
> [ebp+var_24]
> xor ecx, ebp ; cookie
> call
> @__security_check_cookie@4 ; __security_check_cookie(x)
> mov
> esp, ebp
> pop ebp
> retn
>

This is a __cdecl function, "retn" would have a number after it if was a __stdcall.

>
> > I plan to change the
> RaiseException to a Perl catchable croak based on the opinions in
> http://perlmonks.org/?node_id=1024423 in a future 0.76_02. Also >
> I might switch the RaiseException to a DebugBreak since
> RaiseException uses alot of C autos and changes esp/ebp alot (but
> ebp sort of points to the
> > incoming args to RaiseException from
> Call_asm).
>
> > Do you have another opinion of what to do when
> there is a prototype mistake?
>
> Yes, a DebugBreak() woud be nice
> to find the reg mismatch, but most people i.e. using an
> ActiveState-Build of Perl
> would not have debug syms.

You can sort-of, barely really, figure it out by just going to memory watch window, put "esp" as the address, set view to "4 byte integers" then do mental arthmitic (I think) to put back esp 4 bytes back (return address from DebugBreak()).

>
> Maybe do
> the DebugBreak() when IsDebuggerPresent() is true, else use croak.
> You could call IsDebuggerPresent() when api.dll is loaded.
> Thanks for your help and your work!
>

I like that idea, I forgot IsDebuggerPresent exists. Thanks for the idea.

From: Daniel Dragan via RT Thu Mar 28 15:58:57 2013: Request 84268 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeuchel@allgeier.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >


On Thu Mar 28 13:42:02 2013, rkeuchel@allgeier.com wrote:
> I get an exception in call_asm_x86_msvc.asm, raised at bad_esp.
> ESP
> and EBP do not match.

Your prototype is wrong. Either the func in the DLL is actually __cdecl because it doesn't explicitly say __stdcall or WINAPI in each declaration and wasn't compiled with -Gz and the default in Win32::API is always __stdcall unless specified otherwise (this is the opposite of Visual C and GCC's defaults), or it is a __stdcall which takes a different amount of args than you specified in the prototype string.

>
> Using the C version works. Why is the ASM-
> Version the default for MSVC?
>

The inline assembly version was very inefficient compared to the ideal design, the inline assembly version copied the same data between memory and register 2-4 times redundantly before writing it to memory for the final time, also the call instruction appears 3 different times (but called only once) in the inline assembly version instead of once. The C version (still used with GCC) doesn't compare ESP to EBP to find wrong prototypes yet (not sure if the C version ever will).

> I compiled a fresh perl for
> testing and debugging this.
> The called DLL is also built with MSVC
> 16 and uses WINAPI calling convention.

Are you sure?

>
> The signature is:
> Win32::API->Import("svapi32_vc100.dll", 'ULONG
> svapi_connect(LPVOID hsv,LPSTR s1,LPSTR s2,LPSTR s3,LPSTR s4,LPSTR
> s5,LPSTR s6,LPSTR s7,LPSTR s8,LPSTR s9, LPSTR s10)');


The above is probably a __cdecl in the DLL since __stdcall isn't specified anywhere and -Gr and -Gz weren't used (-Gd wasn't used either, but it is on by default). I made a test function below to try your prototype.
_______________________________________________

API_TEST_API ULONG svapi_connect(LPVOID hsv,LPSTR s1,LPSTR s2,LPSTR s3,
LPSTR s4,LPSTR s5,LPSTR s6,LPSTR s7,LPSTR s8,LPSTR s9, LPSTR s10) {
if(hsv == 0x0
&& atoi(s1) == 1
&& atoi(s2) == 2
&& atoi(s3) == 3
&& atoi(s4) == 4
&& atoi(s5) == 5
&& atoi(s6) == 6
&& atoi(s7) == 7
&& atoi(s8) == 8
&& atoi(s9) == 9
&& atoi(s10) == 10)
return 2;
else{
DebugBreak();
return 0;
}
}
___________________________________________________
this is fine, notice I changed the 1st parameter from LPVOID to ULONG (LPVOID is a char * in Win32::API, not an opaque pointer as normally thought of LPVOID)
_______________________________________________
use Win32::API;
Win32::API->Import("api_test.dll", 'ULONG __cdecl svapi_connect(ULONG '
.'hsv,LPSTR s1,LPSTR s2,LPSTR s3,LPSTR s4,LPSTR s5,LPSTR s6,LPSTR s7,LPSTR s8,'
.'LPSTR s9, LPSTR s10)');

die "bad return" if svapi_connect(0..10) != 2;
_______________________________________________


This causes "Unhandled exception at 0x7c812afb in perl.exe: 0xC0000028: An invalid or unaligned stack was encountered during an unwind operation." with 0.76_01.
_______________________________________________
use Win32::API;
Win32::API->Import("api_test.dll", 'ULONG svapi_connect(ULONG '
.'hsv,LPSTR s1,LPSTR s2,LPSTR s3,LPSTR s4,LPSTR s5,LPSTR s6,LPSTR s7,LPSTR s8,'
.'LPSTR s9, LPSTR s10)');

die "bad return" if svapi_connect(0..10) != 2;
_______________________________________________

I plan to change the RaiseException to a Perl catchable croak based on the opinions in http://perlmonks.org/?node_id=1024423 in a future 0.76_02. Also I might switch the RaiseException to a DebugBreak since RaiseException uses alot of C autos and changes esp/ebp alot (but ebp sort of points to the incoming args to RaiseException from Call_asm). Do you have another opinion of what to do when there is a prototype mistake?

From: Ludovico Stevens via RT Sun Feb 24 11:09:06 2013: Request 33513 was acted upon.
Transaction: Correspondence added by LSTEVENS
Queue: Win32-Console
Subject: Handle to std channel broken by the DESTROY method of Win32::Console
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: yon.ar.chall@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=33513 >


This issue also causes problems with the use of threads.
If a Win32::Console object exists and a thread is then joined (or
detached) the cloned Win32::Console object in the thread calls the
DESTROY method and renders the Console unuseable thereafter.
The following snippet illustrates; again the "Hello" is not displayed.

_CODE_BEGIN_
use threads;
use Win32::Console;
Win32::Console->new(Win32::Console::STD_OUTPUT_HANDLE());
$myThread = threads->create( sub { return } );
$myThread->join();
print "Hello\n";
_CODE_END_


I'm using:
Perl version : ActivePerl v5.12.3 (MSWin32-x86-multi-thread), build 1204
OS : Microsoft Windows XP Professional
Module version : Win32::Console 0.09


I had initally fixed this by inserting this line in Console.pm, just
before sub AUTOLOAD:

sub CLONE_SKIP { 1 } # Make module thread safe by not cloning it into
child threads

This ensures that the DESTROY method is only called once per object (and
not every time a clone of the object is destroyed in a thread). In fact
what this does is that it prevents any cloning of Win32::Console into
child threads, which works for me.

However the fix suggested in this bug report by Richard Burkert also
fixes the problem and is more general.

This bug report was raised on module version 0.07 five years ago and now
we are on 0.09.
Any chance this can be fixed in a new version ?
Thanks

From: Jan Dubois via RT Thu Feb 21 20:39:11 2013: Request 83474 was acted upon.
Transaction: Correspondence added by JDB
Queue: Win32
Subject: test of Win32::LoginName in Names.t fails
Broken in: 0.46
Severity: Normal
Owner: Nobody
Requestors: CHORNY@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83474 >


Fixed in Win32-0.47

From: Albert via RT Thu Feb 21 08:54:33 2013: Request 83237 was acted upon.
Transaction: Correspondence added by gepebril
Queue: Win32-API
Subject: Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs"
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: rejected
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83237 >


> I tested the newly released 0.12 of Win32-SystemInfo (
> http://search.cpan.org/~cjohnston/Win32-SystemInfo-0.12/ ). nmake test
and
> __________________________________________
> use Win32::SystemInfo;
> my %mHash = (TotalPhys => 0, AvailPhys => 0, MemLoad => 0);
> if (Win32::SystemInfo::MemoryStatus(%mHash)) {0;}
> __________________________________________
> don't fail anymore as they did in 0.11. So I am closing this bug.

Thanks very much!

From: Alexandr Ciornii via RT Wed Feb 20 07:11:53 2013: Request 83474 was acted upon.
Transaction: Ticket created by CHORNY
Queue: Win32
Subject: test of Win32::LoginName in Names.t fails
Broken in: 0.46
Severity: Normal
Owner: Nobody
Requestors: CHORNY@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83474 >


On my smokers I have login with 1 symbol ('c'), so this test fails:
cmp_ok( length($login), '>', 1, " - checking returned login name" );

--
Alexandr Ciornii, http://chorny.net

From: Daniel Dragan via RT Wed Feb 20 02:15:34 2013: Request 82611 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: make tool detection broken in Win32::API
Broken in: 0.74, 0.75
Severity: Normal
Owner: Nobody
Requestors: BULKDD@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=82611 >


On Wed Feb 06 23:28:10 2013, BULKDD wrote:
> Also improve the POD for how to pass NULL, in pack letter mode (NOT
> prototype mode) for a 'P'. In prototype mode undef is NULL, but in
> letter mode, 0 is NULL. There is live code (irc conversation) that
> uses
> letter mode 0 for NULL. so dont break back compat see this old ::API
> https://github.com/bulk88/perl5-win32-
> api/blob/067439edfd8fab5bc7f18f5bfb16fe7ff7a75259
> /API.xs#L324


more todo: get public opinions for putting a "scalar(@_) >= 3 &&
scalar(@_) <= 6" sanity check on ctor new(). Reason:
http://perlmonks.org/?node_id=1019723 .

From: Jan Dubois via RT Tue Feb 19 16:21:35 2013: Request 82572 was acted upon.
Transaction: Correspondence added by JDB
Queue: Win32
Subject: Using Win32.pm on Windows 2012 results in "Unknown Windows version [2:6:2]" warning
Broken in: 0.45
Severity: Critical
Owner: Nobody
Requestors: Thoke@northpeak.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=82572 >


Fixed in Win32-0.46

From: Daniel Dragan via RT Sat Feb 16 14:10:56 2013: Request 83237 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs"
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83237 >


On Fri Feb 15 00:24:06 2013, CJOHNSTON wrote:
>
> So, I don't blog much and I haven't fixed my broken contact form. It's
> taken me a couple of days to build an environment where I could work on
> this since I've moved away from Windows.
>
> I've updated 48008, but the gist right now is that the changes
> identified fail under ActivePerl. I haven't even tried any other distros
> yet. I've started a feature branch at
> https://github.com/iamthechad/perl-win32-systeminfo/tree/v012 in case
> anybody wants to take a look.

I tested the newly released 0.12 of Win32-SystemInfo (
http://search.cpan.org/~cjohnston/Win32-SystemInfo-0.12/ ). nmake test and
__________________________________________
use Win32::SystemInfo;
my %mHash = (TotalPhys => 0, AvailPhys => 0, MemLoad => 0);
if (Win32::SystemInfo::MemoryStatus(%mHash)) {0;}
__________________________________________
don't fail anymore as they did in 0.11. So I am closing this bug.

From: Ulrich Herbst via RT Sat Feb 16 11:31:20 2013: Request 83375 was acted upon.
Transaction: Ticket created by UHERBST
Queue: Win32-PerfLib
Subject: 64bit counter in cygwin are not reported correctly
Broken in: 0.06
Severity: Important
Owner: Nobody
Requestors: ulrich.herbst@uherbst.de
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83375 >


If we get big counter (I think: 64bit-integer values) with
GetObjectList, we see just "I64d", but not a number.
You can reproduce this with the processor script from
http://www.jkrb.de/jmk/showsource.asp?f=data/scripts/processor.pl on a
cygwin installation on XP or Win2008R2.

Reason (I think so):
in PerfLib.xs there are some calls (3 or 4) to sprintf("%I64d...).
For cygwin and gcc, that should be sprintf("%ld"...)

From: Chad Johnston via RT Fri Feb 15 00:24:06 2013: Request 83237 was acted upon.
Transaction: Correspondence added by CJOHNSTON
Queue: Win32-API
Subject: Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs"
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83237 >


On Thu Feb 14 13:56:10 2013, gepebril wrote:
> @bulk88
>
> Thanks for al the time and research.
>
> So What I understand from this webpage:
> https://github.com/iamthechad/perl-win32-systeminfo/issues/1 is that
> iamthechad is the owner of the module and don't have time any more to
> fix it. It seems if that is the case you can make the specific module
> available for adoption, so somebody else can take over. Sounds like a
> nice solution.
>
> I found that other people have also probs with the 64 bits version
>
> Until this happens I will continue to work on the 32 bits Perl version

So, I don't blog much and I haven't fixed my broken contact form. It's
taken me a couple of days to build an environment where I could work on
this since I've moved away from Windows.

I've updated 48008, but the gist right now is that the changes
identified fail under ActivePerl. I haven't even tried any other distros
yet. I've started a feature branch at
https://github.com/iamthechad/perl-win32-systeminfo/tree/v012 in case
anybody wants to take a look.

From: Albert via RT Thu Feb 14 13:56:10 2013: Request 83237 was acted upon.
Transaction: Correspondence added by gepebril
Queue: Win32-API
Subject: Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs"
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83237 >


@bulk88

Thanks for al the time and research.

So What I understand from this webpage:
https://github.com/iamthechad/perl-win32-systeminfo/issues/1 is that
iamthechad is the owner of the module and don't have time any more to
fix it. It seems if that is the case you can make the specific module
available for adoption, so somebody else can take over. Sounds like a
nice solution.

I found that other people have also probs with the 64 bits version

Until this happens I will continue to work on the 32 bits Perl version

From: Daniel Dragan via RT Wed Feb 13 19:19:32 2013: Request 83237 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs"
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83237 >


On Wed Feb 13 12:52:50 2013, BULKDD wrote:
>
> The author of ::SystemInfo last responded in 2009 in the ::SystemInfo
> bug. He will ultimately have to respond to get this mess fixed. He
> doesn't seem to be around much anymore. His http://www.megatome.com/
> blog's last post is oct 25 2012 and last CPAN upload 4.5 years ago,
> blog's contact page is broken http://www.megatome.com/contact/ which
> is
> domain parked to http://visitorcontact.com/embed/1876 but his github
> https://github.com/iamthechad?tab=activity had a push 2 days ago so
> there is some hope. Im filing a github bug ticket to try to contact
> him.
>
>

The module is basically abandoned according to
https://github.com/iamthechad/perl-win32-systeminfo/issues/1#issuecomment-13513853
. So what do you want to do? CCing possibly interested people also.

From: Daniel Dragan via RT Wed Feb 13 12:52:50 2013: Request 83237 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs"
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83237 >


On Wed Feb 13 06:12:08 2013, gepebril wrote:
> Tobyink has mentioned regarding this issue:
> - That particular message usually comes from using a sub designed to be
> used as an object method as a class method instead. -
> For more info: http://www.perlmonks.org/?node_id=1017850

the failure comes from "$MEMORYSTATUSEX->{dwLength} =
Win32::API::Struct->sizeof($MEMORYSTATUSEX);" which was added in
https://github.com/iamthechad/perl-win32-systeminfo/commit/6d1264e1899a54f1ec518ec1db4be8ea133401b3
The reason it works on 32 bits is because 2 different paths are taken in
::SystemInfo, starting at
https://github.com/iamthechad/perl-win32-systeminfo/blob/e311b78194335a8cfedf8951f495264072f0161d/SystemInfo.pm#L121
.

Looking at Win32::API's docs, its unclear in ::Type and ::Struct's POD
what is an object method and what is a class method. I looked in ::API's
test kit and all ::Struct::sizeof calls were on objects not classes. The
problem in ::SystemInfo on x64 is already covered by
https://rt.cpan.org/Ticket/Display.html?id=48008 . So what do you want
me to do? Add class method support to the ::Struct::sizeof method, or
improve the POD and say its object method only?

The author of ::SystemInfo last responded in 2009 in the ::SystemInfo
bug. He will ultimately have to respond to get this mess fixed. He
doesn't seem to be around much anymore. His http://www.megatome.com/
blog's last post is oct 25 2012 and last CPAN upload 4.5 years ago,
blog's contact page is broken http://www.megatome.com/contact/ which is
domain parked to http://visitorcontact.com/embed/1876 but his github
https://github.com/iamthechad?tab=activity had a push 2 days ago so
there is some hope. Im filing a github bug ticket to try to contact him.

From: Albert via RT Wed Feb 13 06:12:08 2013: Request 83237 was acted upon.
Transaction: Correspondence added by gepebril
Queue: Win32-API
Subject: Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs"
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83237 >


Tobyink has mentioned regarding this issue:
- That particular message usually comes from using a sub designed to be
used as an object method as a class method instead. -
For more info: http://www.perlmonks.org/?node_id=1017850

From: Albert via RT Wed Feb 13 06:04:28 2013: Request 83237 was acted upon.
Transaction: Correspondence added by gepebril
Queue: Win32-API
Subject: Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs"
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83237 >


> I reproduced it ("Can't use string ("Win32::API::Struct") as a HASH ref
> while "strict refs"") only on x64 Perl with a nmake test. 32 bit Perl
> passed an nmake test. Win32::API is supposed to support x64 as good as
> 32 bits. If the user's app that uses Win32::API is written *correctly*,
> his app will work transparently on x64 and 32 bit. I will investigate it
> further tomorrow.

Aha, thanks for taking the time to try to reproduce it. Good news. A bug
is bug when it can be reproduced. I used the sample from the Cpan module
Win32::SystemInfo so that part should be correctly. Or are you referring
to Win:System32Info that is not using Win32::API correctly?

> Google "perl make test" no quotes. I specifically used nmake (not make)
> since I use Visual C, not Cygwin/Linux.
Ok, I forgot. You have to use make when you don't use cpan -> install
but download the module manually. As for the last two years everything
with Perl went so smoothly I stopped using it.

From: Daniel Dragan via RT Wed Feb 13 02:44:43 2013: Request 83237 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs"
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83237 >


On Tue Feb 12 15:57:54 2013, gepebril wrote:
> I will check it hopefully tomorrow.
>
> Yup the problem didn't occur in the 32 bits (latest) version of Perl
> Strawberry. Should Win32::SystemInfo be compatible with the 64 release
> of Strawberry Perl?

I reproduced it ("Can't use string ("Win32::API::Struct") as a HASH ref
while "strict refs"") only on x64 Perl with a nmake test. 32 bit Perl
passed an nmake test. Win32::API is supposed to support x64 as good as
32 bits. If the user's app that uses Win32::API is written *correctly*,
his app will work transparently on x64 and 32 bit. I will investigate it
further tomorrow.

On Mon Feb 11 17:41:59 2013, gepebril wrote:
> Thanks for the reply and testing.
>
> > So what is the failing code? I tried a "make test" on Win32:SystemInfo
> > and it passed. I also tried
> I never done this make test, do you have the cli how to test that?

Google "perl make test" no quotes. I specifically used nmake (not make)
since I use Visual C, not Cygwin/Linux.

From: Albert via RT Tue Feb 12 15:57:54 2013: Request 83237 was acted upon.
Transaction: Correspondence added by gepebril
Queue: Win32-API
Subject: Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs"
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83237 >


I will check it hopefully tomorrow.

Yup the problem didn't occur in the 32 bits (latest) version of Perl
Strawberry. Should Win32::SystemInfo be compatible with the 64 release
of Strawberry Perl?

From: Albert via RT Mon Feb 11 17:41:59 2013: Request 83237 was acted upon.
Transaction: Correspondence added by gepebril
Queue: Win32-API
Subject: Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs"
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83237 >


Thanks for the reply and testing.

> So what is the failing code? I tried a "make test" on Win32:SystemInfo
> and it passed. I also tried
I never done this make test, do you have the cli how to test that?

> and saw nothing (like warnings/dies) in console. Using ::API 0.75 on
> 32bit winxp.
I tried to replicate my old environment with autobundle and it worked,
but not for the Win32::SystemInfo module. It mentioned I could only
install it with force. I just found out that my old environment is
5.12.3.0-32bit and not 5.12.3.0-64bit which I used on the new
environment. The problem only occurs on the new environment. I run on
both environments Win7 64 bits. So early conclusion is that the problem
only occurs on 64 bits versions of Strawberry Perl, not on the 32 bits
version. I will check it hopefully tomorrow.

From: Daniel Dragan via RT Sun Feb 10 14:49:15 2013: Request 83237 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs"
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83237 >


On Sat Feb 09 09:27:24 2013, gepebril wrote:
> Can't use string ("Win32::API::Struct") as a HASH ref while "strict
> refs" in use at C:/strawberry/perl/vendor/lib/Win32/A PI/Struct.pm line
> 158. Had to use force to install Win32:SystemInfo module. my %mHash =
> (TotalPhys => 0, AvailPhys => 0, MemLoad => 0); if
> (Win32::SystemInfo::MemoryStatus(%mHash)) # Failes on this line!!
> Problem wasn't there with 0.62 Thanks in advance
>
> Same as last bug, I just noticed that there was no subject and that I
> could upgrade from 0,73->0,75 and haven't figured out a way to remove
> the last entry

So what is the failing code? I tried a "make test" on Win32:SystemInfo
and it passed. I also tried
___________________________________________________________
use Win32::SystemInfo;
my %mHash = (TotalPhys => 0, AvailPhys => 0, MemLoad => 0);
if (Win32::SystemInfo::MemoryStatus(%mHash)) {0;}
___________________________________________________________
and saw nothing (like warnings/dies) in console. Using ::API 0.75 on
32bit winxp.

Also
______________________________________________________________________
C:\Documents and Settings\Owner\Desktop\cpan libs\w32si>perl test.pl
1..3
ok 1
ok 2
ok 3

C:\Documents and Settings\Owner\Desktop\cpan libs\w32si>
______________________________________________________________________

From: Albert via RT Sat Feb 09 09:27:24 2013: Request 83237 was acted upon.
Transaction: Ticket created by gepebril
Queue: Win32-API
Subject: Can't use string ("Win32::API::Struct") as a HASH ref while
"strict refs"
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83237 >


Can't use string ("Win32::API::Struct") as a HASH ref while "strict
refs" in use at C:/strawberry/perl/vendor/lib/Win32/A PI/Struct.pm line
158. Had to use force to install Win32:SystemInfo module. my %mHash =
(TotalPhys => 0, AvailPhys => 0, MemLoad => 0); if
(Win32::SystemInfo::MemoryStatus(%mHash)) # Failes on this line!!
Problem wasn't there with 0.62 Thanks in advance

Same as last bug, I just noticed that there was no subject and that I
could upgrade from 0,73->0,75 and haven't figured out a way to remove
the last entry

From: Albert via RT Sat Feb 09 09:16:50 2013: Request 83236 was acted upon.
Transaction: Ticket created by gepebril
Queue: Win32-API
Subject: (No subject given)
Broken in: 0.73
Severity: Critical
Owner: Nobody
Requestors: compuvision.sr@gmail.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83236 >


Can't use string ("Win32::API::Struct") as a HASH ref while "strict
refs" in use at C:/strawberry/perl/vendor/lib/Win32/A
PI/Struct.pm line 158.


Had to use force to install Win32:SystemInfo module.
my %mHash = (TotalPhys => 0, AvailPhys => 0, MemLoad => 0);
if (Win32::SystemInfo::MemoryStatus(%mHash)) # Failes on this line!!

Problem wasn't there with 0.62

Thanks in advance

From: Daniel Dragan via RT Thu Feb 07 03:04:29 2013: Request 83191 was acted upon.
Transaction: Ticket created by BULKDD
Queue: Win32-API
Subject: Win32::API doesn't keep C stack aligned on x64
Broken in: 0.75
Severity: Important
Owner: Nobody
Requestors: BULKDD@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83191 >


After a long IRC conversation with someone with a x64 Win 7 machine,
with Strawberry Perl and Mingw compiled API:: DLL. It was found that a
crash occurred when a movdqa was executed to save a XMM reg in a delay
loading DLL tailmerge. movdqa requires an aligned memory address. It was
found that (rsp+0x20)%16 == 8, unaligned. Adding an extra 0 param to the
prototype passed to C fixed the crash confirming the unalignment of the
C stack when there are 5 args with Win32::API.

before.
____________________________________________________________________
my $acquireCtx = Win32::API->new('advapi32', 'CryptAcquireContext',
'PPPNN', 'I') or die;
$acquireCtx->Call($ctx, 0, 0, 1, hex('40') | hex('F0000000')) or die
"CryptAcquireContext failed";
____________________________________________________________________
after
____________________________________________________________________
my $acquireCtx = Win32::API->new('advapi32', 'CryptAcquireContext',
'PPPNNN', 'I') or die;
$acquireCtx->Call($ctx, 0, 0, 1, hex('40') | hex('F0000000'), 0) or die
"CryptAcquireContext failed";
____________________________________________________________________
fixed the crash. Now this fix would crash on 32 bit due to stdcall.

____________________________________________________________________
__tailMerge_CRYPTSP_dll:
000007FEFE6FDC70 48 89 4C 24 08 mov qword ptr [rsp+8],rcx
000007FEFE6FDC75 48 89 54 24 10 mov qword ptr [rsp+10h],rdx
000007FEFE6FDC7A 4C 89 44 24 18 mov qword ptr [rsp+18h],r8
000007FEFE6FDC7F 4C 89 4C 24 20 mov qword ptr [rsp+20h],r9
000007FEFE6FDC84 48 83 EC 68 sub rsp,68h
000007FEFE6FDC88 66 0F 7F 44 24 20 movdqa xmmword ptr
[rsp+20h],xmm0 ;crash here
000007FEFE6FDC8E 66 0F 7F 4C 24 30 movdqa xmmword ptr
[rsp+30h],xmm1
000007FEFE6FDC94 66 0F 7F 54 24 40 movdqa xmmword ptr
[rsp+40h],xmm2
000007FEFE6FDC9A 66 0F 7F 5C 24 50 movdqa xmmword ptr
[rsp+50h],xmm3
000007FEFE6FDCA0 48 8B D0 mov rdx,rax
000007FEFE6FDCA3 48 8D 0D 5E E1 08 00 lea
rcx,[__DELAY_IMPORT_DESCRIPTOR_CRYPTSP_dll (7FEFE78BE08h)]
000007FEFE6FDCAA E8 01 DA 00 00 call __delayLoadHelper2
(7FEFE70B6B0h)
000007FEFE6FDCAF 66 0F 6F 44 24 20 movdqa xmm0,xmmword ptr
[rsp+20h]
000007FEFE6FDCB5 66 0F 6F 4C 24 30 movdqa xmm1,xmmword ptr
[rsp+30h]
000007FEFE6FDCBB 66 0F 6F 54 24 40 movdqa xmm2,xmmword ptr
[rsp+40h]
000007FEFE6FDCC1 66 0F 6F 5C 24 50 movdqa xmm3,xmmword ptr
[rsp+50h]
000007FEFE6FDCC7 48 8B 4C 24 70 mov rcx,qword ptr [rsp+70h]
000007FEFE6FDCCC 48 8B 54 24 78 mov rdx,qword ptr [rsp+78h]
000007FEFE6FDCD1 4C 8B 84 24 80 00 00 00 mov r8,qword ptr
[rsp+80h]
000007FEFE6FDCD9 4C 8B 8C 24 88 00 00 00 mov r9,qword ptr
[rsp+88h]
000007FEFE6FDCE1 48 83 C4 68 add rsp,68h
000007FEFE6FDCE5 EB 00 jmp
__tailMerge_CRYPTSP_dll+77h (7FEFE6FDCE7h)
000007FEFE6FDCE7 FF E0 jmp rax
000007FEFE6FDCE9 90 nop
000007FEFE6FDCEA 90 nop
000007FEFE6FDCEB 90 nop
000007FEFE6FDCEC 90 nop
000007FEFE6FDCED 90 nop
000007FEFE6FDCEE 90 nop
______________________________________________________________________

This delay loading of cryptsp.dll doesn't happen on my x64 Server 2003
machine (I can't reproduce this crash), but due to MS's reorganization
of DLLs over the last couple years, in Win 7 CryptAcquireContext is not
implemented in advapi32.dll anymore but in cryptsp.dll. MS requires C
stack to be 16 bytes aligned on Win64 for ABI.

I am creating this ticket as a reminder to myself.

From: Daniel Dragan via RT Wed Feb 06 23:28:10 2013: Request 82611 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: make tool detection broken in Win32::API
Broken in: 0.74, 0.75
Severity: Normal
Owner: Nobody
Requestors: BULKDD@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=82611 >


On Mon Feb 04 01:43:52 2013, BULKDD wrote:
> On Tue Jan 22 14:41:02 2013, BULKDD wrote:
> >
> > After discussion with Mithaldu/smoker owner above, {MAKE} is
> > 'C:\Perl\site\bin\dmake.exe', not 'dmake.exe' on his machine.
> > MM_Win32.pm has a is_make_type method which uses a more elaborate RE to
> > do it. Using is_make_type will probably be the solution. Remaining
> > issues are, is_make_type is not public API of EUMM (embedding the RE is
> > the alternative), and testing the whole thing on VC Perl, S Perl and Cyg
> > Perl.
>
> Also remove the Encode:: dependency in makefile.pl, add a dependency on
> Encode::compat, on 5.8 and newer on Win32 Encode::compat passes,
> http://www.cpantesters.org/distro/E/Encode-compat.html . So this might
> have Perl 5.6 reports show up in cpantesters for Win32::API. Also add
> skipping the native threads with API::Callback threads test that crashes
> on 5.6.


Also improve the POD for how to pass NULL, in pack letter mode (NOT
prototype mode) for a 'P'. In prototype mode undef is NULL, but in
letter mode, 0 is NULL. There is live code (irc conversation) that uses
letter mode 0 for NULL. so dont break back compat see this old ::API
https://github.com/bulk88/perl5-win32-api/blob/067439edfd8fab5bc7f18f5bfb16fe7ff7a75259
/API.xs#L324

From: Daniel Dragan via RT Mon Feb 04 01:43:52 2013: Request 82611 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: make tool detection broken in Win32::API
Broken in: 0.74, 0.75
Severity: Normal
Owner: Nobody
Requestors: BULKDD@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=82611 >


On Tue Jan 22 14:41:02 2013, BULKDD wrote:
>
> After discussion with Mithaldu/smoker owner above, {MAKE} is
> 'C:\Perl\site\bin\dmake.exe', not 'dmake.exe' on his machine.
> MM_Win32.pm has a is_make_type method which uses a more elaborate RE to
> do it. Using is_make_type will probably be the solution. Remaining
> issues are, is_make_type is not public API of EUMM (embedding the RE is
> the alternative), and testing the whole thing on VC Perl, S Perl and Cyg
> Perl.

Also remove the Encode:: dependency in makefile.pl, add a dependency on
Encode::compat, on 5.8 and newer on Win32 Encode::compat passes,
http://www.cpantesters.org/distro/E/Encode-compat.html . So this might
have Perl 5.6 reports show up in cpantesters for Win32::API. Also add
skipping the native threads with API::Callback threads test that crashes
on 5.6.

From: Daniel Dragan via RT Tue Jan 22 14:41:02 2013: Request 82611 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: make tool detection broken in Win32::API
Broken in: 0.74, 0.75
Severity: Normal
Owner: Nobody
Requestors: BULKDD@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=82611 >


On Thu Jan 10 02:26:07 2013, BULKDD wrote:
> see
>
http://www.cpantesters.org/cpan/report/621df9ed-7059-1014-86e5-1b72d871b27e
>
http://www.cpantesters.org/cpan/report/9af18357-71e1-1014-8cab-46ee168fd208
>
> somehow
> _______________________________________
> sub MY::post_constants {
> return 'CCFLAGS '.($_[0]->{MAKE} =~ /^make/ || $_[0]->{MAKE} =~
> /^dmake/ ? ':=' : '=')
> . ' $(CCFLAGS) '.GS_flag()."\n";
> }
> ________________________________________
>
> isn't working correctly.

After discussion with Mithaldu/smoker owner above, {MAKE} is
'C:\Perl\site\bin\dmake.exe', not 'dmake.exe' on his machine.
MM_Win32.pm has a is_make_type method which uses a more elaborate RE to
do it. Using is_make_type will probably be the solution. Remaining
issues are, is_make_type is not public API of EUMM (embedding the RE is
the alternative), and testing the whole thing on VC Perl, S Perl and Cyg
Perl.

From: Cosimo Streppone via RT Tue Jan 22 10:42:51 2013: Request 82879 was acted upon.
Transaction: Correspondence added by COSIMO
Queue: Win32-API
Subject: Obsolete source repository
Broken in: 0.75
Severity: Critical
Owner: Nobody
Requestors: dolmen@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=82879 >


Thanks for the report.
Repository was updated as requested.
I had tried to do that already, but merge caused conflicts, so it wasn't
a 1 minute operation.

Done now.

From: Steve Hay via RT Wed Jan 16 03:55:32 2013: Request 82572 was acted upon.
Transaction: Correspondence added by SHAY
Queue: Win32
Subject: Using Win32.pm on Windows 2012 results in "Unknown Windows version [2:6:2]" warning
Broken in: 0.45
Severity: Critical
Owner: Nobody
Requestors: Thoke@northpeak.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=82572 >


See also ticket #116352 on rt.perl.org regarding the same problem with
Windows 8:

https://rt.perl.org/rt3/Ticket/Display.html?id=116352

From: Daniel Dragan via RT Tue Jan 15 21:20:21 2013: Request 72018 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: When used with Selenium IE Driver (64-bit), this module crashes
Broken in: 0.64
Severity: Critical
Owner: Nobody
Requestors: aivaturi@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=72018 >


On Tue Jan 08 22:55:20 2013, BULKDD wrote:
> On Fri Oct 19 01:27:10 2012, BULKDD wrote:
> > On Fri Oct 28 14:37:58 2011, AIVATURI wrote:
> > > I'm trying to implement Selenium IE Driver bindings in Perl. This
> module
> > > works fine under 32-bit mode but in 64-bit mode it crashes with
the 64-
> > > bit IE dll.
> > >
> > > My environment:
> > >
> > > OS: Windows 7 64-bit
> > > Perl: ActivePerl 64-bit v5.10
> > > Win32::API v0.64
> > > Selenium IE Driver DLL:
> > >
http://selenium.googlecode.com/svn/trunk/cpp/prebuilt/x64/Release/IEDriv
> > > er.dll
> > >
> > > Here are the steps to reproduce:
> > >
> > > 1) Download the IEDriver.dll from the link above.
> > > 2) Use this script to start a simple IE Driver server:
> > >
> > > use strict;
> > > use warnings;
> > > use Win32::API;
> > >
> > > my $start = Win32::API->new('IEDriver.dll', 'StartServer', 'I', 'P',
> > > '_cdecl');
> > > my $server = $start->Call(4444);
> > >
> > > BTW, this same script on a 32-bit Windows with Perl (32-bit) &
> > > Win32::API works as expected. The crash happens only in Perl
64-bit on
> > > Windows 7.
> >
> > Can you try the latest version of Win32::API 0.72 from CPAN and see if
> > it fixes your problem?
>
> Try 2. The current version is 0.74 on CPAN.

No answer. Closing.

From: Daniel Dragan via RT Thu Jan 10 02:32:12 2013: Request 42694 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Callback and Structs
Broken in: 0.58
Severity: Normal
Owner: Nobody
Requestors: msjuniorc@hotmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=42694 >


On Tue Jan 08 22:57:15 2013, BULKDD wrote:
> On Fri Oct 19 04:19:35 2012, BULKDD wrote:
> > On Thu Jan 22 21:13:41 2009, juniorc wrote:
> > > Cosimo,
> > >
> > > I am currently writing a Win32::Video::Capture module making calls to
> > > avicap32.dll. Several "messages" require the use of "structs" and
> > > "callbacks". Thank to the "callback3.pl" example in the sample
> > > directory, it was clear how to use nested structs in a callback
> > > environment. Unfortunately both in my own code and the aforementioned
> > > example I encure repetitive errors: "Attempt to free unreferenced
> > > scalar". More details in the logs below.
> > > At the current time and in order to proceed without the
> > > Win32::API::Struct, I am using the Win32::API::Callback and a few
calls
> > > to the "RtlMoveMemory" and "lstrcpy" functions of the kernel32.dll.
> > > Although this work without any issues, I have to say the approach
lacks
> > > the "elegance & readability" that the use of Win32::API::Struct would
> > > give. It seems that there might be an "extra" call to a
"sv_2mortal" in
> > > the XS portion. Is there anything i can do on my end to help?
> > >
> > > Thank you in advance,
> > >
> > > Giuseppe "Jr."
> >
> > Can you try the latest CPAN version of Win32::API (0.72) and report how
> > it works for you?
>
> Try 2. The current version is 0.74 on CPAN.

Closing no response. Struct got some improvements and bug fixes in 2012,
so maybe one of them would have fixed the problems claimed by the OP.