perl.libwin32

perl.libwin32 http://www.nntp.perl.org/group/perl.libwin32/ ... Copyright 1998-2013 perl.org Sat, 25 May 2013 04:30:51 +0000 ask@perl.org [rt.cpan.org #84268] Win32::API: Bug/Exception in call_asm_x86_msvc.asm by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/04/msg885.html Wed, 10 Apr 2013 02:28:58 +0000 AW: [rt.cpan.org #84268] Win32::API: Bug/Exception in call_asm_x86_msvc.asm by Keuchel, Rainer via RT Tue Apr 09 04:56:26 2013: Request 84268 was acted upon. Transaction: Correspondence added by rkeuchel@allgeier.com 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 > You can close the ticket, cdecl works.. Mit freundlichen GrÃ¼ssen Rainer Keuchel Rainer Keuchel Entwicklungsleiter Enterprise Content Management Allgeier IT Solutions GmbH Hans-Bredow-Str. 60 28307 Bremen Tel: +49 (421) 43841294 Fax: +49 (421) 438419294 E-Mail: rkeuchel@allgeier.com Internet: www.allgeier-it.de ALLGEIER IT SOLUTIONS GmbH Amtsgericht Bremen | HRB 20924 GeschÃ¤ftsfÃ¼hrer: Hubert Rohrer, Johannes HÃ¤ringslack, Ralf Nitzgen St.-Nr. 803/11449 | USt.-ID-Nr. DE114397847 Diese E-Mail enthÃ¤lt vertrauliche und/oder rechtlich geschÃ¼tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtÃ¼mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail sind nicht gestattet. This message (and any associated files) is intended only for the use of bug-Win32-API@rt.cpan.org and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not bug-Win32-API@rt.cpan.org you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author rkeuchel@allgeier.com and do not necessarily represent those of the company. -----UrsprÃ¼ngliche Nachricht----- Von: Daniel Dragan via RT [mailto:bug-Win32-API@rt.cpan.org] Gesendet: Dienstag, 9. April 2013 07:09 An: Keuchel, Rainer Betreff: [rt.cpan.org #84268] Win32::API: Bug/Exception in call_asm_x86_msvc.asm <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? http://www.nntp.perl.org/group/perl.libwin32/2013/04/msg884.html Tue, 09 Apr 2013 08:56:35 +0000 [rt.cpan.org #84268] Win32::API: Bug/Exception in call_asm_x86_msvc.asm by 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? http://www.nntp.perl.org/group/perl.libwin32/2013/04/msg883.html Tue, 09 Apr 2013 05:09:20 +0000 [rt.cpan.org #81748] strawberry perl 5.8.9 with mingw.org gcc 3.4.5 alloca broken by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/04/msg882.html Tue, 09 Apr 2013 05:05:35 +0000 [rt.cpan.org #83191] Win32::API doesn't keep C stack aligned on x64 by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/04/msg881.html Tue, 09 Apr 2013 04:55:43 +0000 AW: [rt.cpan.org #84268] Win32::API: Bug/Exception in call_asm_x86_msvc.asm by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/03/msg880.html Fri, 29 Mar 2013 10:24:40 +0000 [rt.cpan.org #84268] Win32::API: Bug/Exception in call_asm_x86_msvc.asm by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/03/msg879.html Fri, 29 Mar 2013 04:35:54 +0000 [rt.cpan.org #84268] Win32::API: Bug/Exception in call_asm_x86_msvc.asm by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/03/msg878.html Thu, 28 Mar 2013 21:42:14 +0000 RE: [rt.cpan.org #84268] Win32::API: Bug/Exception in call_asm_x86_msvc.asm by Keuchel, Rainer via RT Thu Mar 28 17:11:32 2013: Request 84268 was acted upon. Transaction: Correspondence added by rkeuchel@allgeier.com Queue: Win32-API Subject: RE: [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 > 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. 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 > 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. 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! Rainer Keuchel Entwicklungsleiter Enterprise Content Management Allgeier IT Solutions GmbH Hans-Bredow-Str. 60 28307 Bremen Tel: +49 (421) 43841294 Fax: +49 (421) 438419294 E-Mail: rkeuchel@allgeier.com Internet: www.allgeier-it.de ALLGEIER IT SOLUTIONS GmbH Amtsgericht Bremen | HRB 20924 GeschÃ¤ftsfÃ¼hrer: Hubert Rohrer, Johannes HÃ¤ringslack, Ralf Nitzgen St.-Nr. 803/11449 | USt.-ID-Nr. DE114397847 Diese E-Mail enthÃ¤lt vertrauliche und/oder rechtlich geschÃ¼tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtÃ¼mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail sind nicht gestattet. This message (and any associated files) is intended only for the use of bug-Win32-API@rt.cpan.org and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not bug-Win32-API@rt.cpan.org you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author rkeuchel@allgeier.com and do not necessarily represent those of the company. http://www.nntp.perl.org/group/perl.libwin32/2013/03/msg877.html Thu, 28 Mar 2013 21:11:41 +0000 [rt.cpan.org #84268] Win32::API: Bug/Exception in call_asm_x86_msvc.asm by 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? http://www.nntp.perl.org/group/perl.libwin32/2013/03/msg876.html Thu, 28 Mar 2013 19:59:05 +0000 [rt.cpan.org #84268] Win32::API: Bug/Exception in call_asm_x86_msvc.asm by Keuchel, Rainer via RT Thu Mar 28 13:42:02 2013: Request 84268 was acted upon. Transaction: Ticket created by rkeuchel@allgeier.com 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 > I get an exception in call_asm_x86_msvc.asm, raised at bad_esp. ESP and EBP do not match. Using the C version works. Why is the ASM-Version the default for MSVC? I compiled a fresh perl for testing and debugging this. The called DLL is also built with MSVC 16 and uses WINAPI calling convention. 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)'); Compiler: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Build Log: nmake -f Makefile all -nologo C:\perl\5.16.3\bin\perl.exe C:\Perl\5.16.3\lib\ExtUtils\xsubpp -typemap C:\perl\5.16.3\lib\ExtUtils\typemap Callback.xs > Callback.xsc && C:\perl\5.16.3\bin\perl.exe -MExtUtils::Command -e mv -- Callback.xsc Callback.c cl -c -GS- -nologo -GF -W3 -Od -MD -Zi -DDEBUGGING -DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DPERL_TEXTMODE_SCRIPTS -DUSE_PERLIO -Od -MD -Zi -DDEBUGGING -DVERSION=\"0.76_01\" -DXS_VERSION=\"0.76_01\" "-IC:\perl\5.16.3\lib\CORE" Callback.c Callback.c Running Mkbootstrap for Win32::API::Callback () C:\perl\5.16.3\bin\perl.exe -MExtUtils::Command -e chmod -- 644 Callback.bs C:\perl\5.16.3\bin\perl.exe -MExtUtils::Mksymlists -e "Mksymlists('NAME'=>\"Win32::API::Callback\", 'DLBASE' => 'Callback', 'DL_FUNCS' => { }, 'FUNCLIST' => [], 'IMPORTS' => { }, 'DL_VARS' => []);" link -out:..\blib\arch\auto\Win32\API\Callback\Callback.dll -dll -nologo -nodefaultlib -debug -libpath:"c:\perl\5.16.3\lib\CORE" -machine:x86 "/manifestdependency:type='Win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'" Callback.obj C:\perl\5.16.3\lib\CORE\perl516.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib -def:Callback.def Creating library ..\blib\arch\auto\Win32\API\Callback\Callback.lib and object ..\blib\arch\auto\Win32\API\Callback\Callback.exp if exist ..\blib\arch\auto\Win32\API\Callback\Callback.dll.manifest mt -nologo -manifest ..\blib\arch\auto\Win32\API\Callback\Callback.dll.manifest -outputresource:..\blib\arch\auto\Win32\API\Callback\Callback.dll;2 if exist ..\blib\arch\auto\Win32\API\Callback\Callback.dll.manifest del ..\blib\arch\auto\Win32\API\Callback\Callback.dll.manifest C:\perl\5.16.3\bin\perl.exe -MExtUtils::Command -e chmod -- 755 ..\blib\arch\auto\Win32\API\Callback\Callback.dll C:\perl\5.16.3\bin\perl.exe -MExtUtils::Command -e cp -- Callback.bs ..\blib\arch\auto\Win32\API\Callback\Callback.bs C:\perl\5.16.3\bin\perl.exe -MExtUtils::Command -e chmod -- 644 ..\blib\arch\auto\Win32\API\Callback\Callback.bs cd .. C:\perl\5.16.3\bin\perl.exe C:\Perl\5.16.3\lib\ExtUtils\xsubpp -nolinenumbers -typemap C:\perl\5.16.3\lib\ExtUtils\typemap -typemap typemap API.xs > API.xsc && C:\perl\5.16.3\bin\perl.exe -MExtUtils::Command -e mv -- API.xsc API.c cl -c -GS- -nologo -GF -W3 -Od -MD -Zi -DDEBUGGING -DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DPERL_TEXTMODE_SCRIPTS -DUSE_PERLIO -Od -MD -Zi -DDEBUGGING -DVERSION=\"0.76_01\" -DXS_VERSION=\"0.76_01\" "-IC:\perl\5.16.3\lib\CORE" API.c API.c ml -Zi -c call_asm_x86_msvc.asm Assembling: call_asm_x86_msvc.asm Running Mkbootstrap for Win32::API () C:\perl\5.16.3\bin\perl.exe -MExtUtils::Command -e chmod -- 644 API.bs C:\perl\5.16.3\bin\perl.exe -MExtUtils::Mksymlists -e "Mksymlists('NAME'=>\"Win32::API\", 'DLBASE' => 'API', 'DL_FUNCS' => { }, 'FUNCLIST' => [], 'IMPORTS' => { }, 'DL_VARS' => []);" link -out:blib\arch\auto\Win32\API\API.dll -dll -nologo -nodefaultlib -debug -libpath:"c:\perl\5.16.3\lib\CORE" -machine:x86 "/manifestdependency:type='Win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'" API.obj call_asm_x86_msvc.obj C:\perl\5.16.3\lib\CORE\perl516.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib -def:API.def Creating library blib\arch\auto\Win32\API\API.lib and object blib\arch\auto\Win32\API\API.exp if exist blib\arch\auto\Win32\API\API.dll.manifest mt -nologo -manifest blib\arch\auto\Win32\API\API.dll.manifest -outputresource:blib\arch\auto\Win32\API\API.dll;2 if exist blib\arch\auto\Win32\API\API.dll.manifest del blib\arch\auto\Win32\API\API.dll.manifest C:\perl\5.16.3\bin\perl.exe -MExtUtils::Command -e chmod -- 755 blib\arch\auto\Win32\API\API.dll C:\perl\5.16.3\bin\perl.exe -MExtUtils::Command -e cp -- API.bs blib\arch\auto\Win32\API\API.bs C:\perl\5.16.3\bin\perl.exe -MExtUtils::Command -e chmod -- 644 blib\arch\auto\Win32\API\API.bs Rainer Keuchel Entwicklungsleiter Enterprise Content Management [cid:imageb271b8.JPG@f9d174aa.46bf0687] Allgeier IT Solutions GmbH Hans-Bredow-Str. 60 28307 Bremen Tel: +49 (421) 43841294 Fax: +49 (421) 438419294 E-Mail: rkeuchel@allgeier.com Internet: www.allgeier-it.de ALLGEIER IT SOLUTIONS GmbH Amtsgericht Bremen | HRB 25242 GeschÃ¤ftsfÃ¼hrer: Hubert Rohrer, Johannes HÃ¤ringslack, Ralf Nitzgen St.-Nr. 71/551/06446 | USt.-ID-Nr. DE114397847 Diese E-Mail enthÃ¤lt vertrauliche und/oder rechtlich geschÃ¼tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtÃ¼mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail sind nicht gestattet. This message (and any associated files) is intended only for the use of bug-Win32-API@rt.cpan.org and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not bug-Win32-API@rt.cpan.org you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author rkeuchel@allgeier.com and do not necessarily represent those of the company. http://www.nntp.perl.org/group/perl.libwin32/2013/03/msg875.html Thu, 28 Mar 2013 17:42:11 +0000 [rt.cpan.org #33513] Handle to std channel broken by the DESTROY method of Win32::Console by 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 http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg874.html Sun, 24 Feb 2013 16:09:17 +0000 [rt.cpan.org #83474] test of Win32::LoginName in Names.t fails by 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 http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg873.html Fri, 22 Feb 2013 01:39:19 +0000 [rt.cpan.org #83237] Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs" by 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! http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg872.html Thu, 21 Feb 2013 13:54:46 +0000 [rt.cpan.org #83474] test of Win32::LoginName in Names.t fails by 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 http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg871.html Wed, 20 Feb 2013 12:12:01 +0000 [rt.cpan.org #82611] make tool detection broken in Win32::API by 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 . http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg870.html Wed, 20 Feb 2013 07:15:44 +0000 [rt.cpan.org #82572] Using Win32.pm on Windows 2012 results in "Unknown Windows version [2:6:2]" warning by 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 http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg869.html Tue, 19 Feb 2013 21:21:44 +0000 [rt.cpan.org #83237] Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs" by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg868.html Sat, 16 Feb 2013 19:11:05 +0000 [rt.cpan.org #83375] 64bit counter in cygwin are not reported correctly by 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"...) http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg867.html Sat, 16 Feb 2013 16:31:28 +0000 [rt.cpan.org #83237] Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs" by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg866.html Fri, 15 Feb 2013 05:24:16 +0000 [rt.cpan.org #83237] Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs" by 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 http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg865.html Thu, 14 Feb 2013 18:56:21 +0000 [rt.cpan.org #83237] Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs" by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg864.html Thu, 14 Feb 2013 00:19:46 +0000 [rt.cpan.org #83237] Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs" by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg863.html Wed, 13 Feb 2013 17:53:01 +0000 [rt.cpan.org #83237] Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs" by 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 http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg862.html Wed, 13 Feb 2013 11:12:20 +0000 [rt.cpan.org #83237] Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs" by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg861.html Wed, 13 Feb 2013 11:04:41 +0000 [rt.cpan.org #83237] Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs" by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg860.html Wed, 13 Feb 2013 07:44:51 +0000 [rt.cpan.org #83237] Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs" by 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? http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg859.html Tue, 12 Feb 2013 20:58:02 +0000 [rt.cpan.org #83237] Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs" by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg858.html Mon, 11 Feb 2013 22:42:07 +0000 [rt.cpan.org #83237] Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs" by 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> ______________________________________________________________________ http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg857.html Sun, 10 Feb 2013 19:49:24 +0000 [rt.cpan.org #83237] Can't use string ("Win32::API::Struct") as a HASH ref while "strict refs" by 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 http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg856.html Sat, 09 Feb 2013 14:27:31 +0000 [rt.cpan.org #83236] by 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 http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg855.html Sat, 09 Feb 2013 14:16:59 +0000 [rt.cpan.org #83191] Win32::API doesn't keep C stack aligned on x64 by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg854.html Thu, 07 Feb 2013 08:04:37 +0000 [rt.cpan.org #82611] make tool detection broken in Win32::API by 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 http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg853.html Thu, 07 Feb 2013 04:28:20 +0000 [rt.cpan.org #82611] make tool detection broken in Win32::API by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/02/msg852.html Mon, 04 Feb 2013 06:44:02 +0000 [rt.cpan.org #82611] make tool detection broken in Win32::API by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/01/msg851.html Tue, 22 Jan 2013 19:41:15 +0000 [rt.cpan.org #82879] Obsolete source repository by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/01/msg850.html Tue, 22 Jan 2013 15:43:00 +0000 [rt.cpan.org #82879] Obsolete source repository by Olivier Mengué via RT Tue Jan 22 05:03:48 2013: Request 82879 was acted upon. Transaction: Ticket created by DOLMEN 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 > In META.yml/Makefile.PL the source repository is listed as being: https://github.com/cosimo/perl5-win32-api But this repo has not been updated for 3 months while some new releases appeared on CPAN. Please, either push to the repo or remove the invalid meta. -- Olivier MenguÃ© - http://perlresume.org/DOLMEN http://www.nntp.perl.org/group/perl.libwin32/2013/01/msg849.html Tue, 22 Jan 2013 10:03:57 +0000 [rt.cpan.org #82572] Using Win32.pm on Windows 2012 results in "Unknown Windows version [2:6:2]" warning by 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 http://www.nntp.perl.org/group/perl.libwin32/2013/01/msg848.html Wed, 16 Jan 2013 08:55:40 +0000 [rt.cpan.org #72018] When used with Selenium IE Driver (64-bit), this module crashes by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/01/msg847.html Wed, 16 Jan 2013 02:20:29 +0000 [rt.cpan.org #42694] Callback and Structs by 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. http://www.nntp.perl.org/group/perl.libwin32/2013/01/msg846.html Thu, 10 Jan 2013 07:32:21 +0000