Re: [rt.cpan.org #55660] [PATCH] Partial win64 support for Win32::API

----- Original Message ----- 
From: "Stephen Bennett" <[email protected]>
To: "Sisyphus" <[email protected]>; <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, April 27, 2010 8:01 AM
Subject: RE: [rt.cpan.org #55660] [PATCH] Partial win64 support for
Win32::API


> Apologies for the delayed reply -- I was rather busy at the time and then
> subsequently just forgot about this.
>
>> ###############################
>> Test Summary Report
>> -------------------
>> t/00_API.t        (Wstat: 1280 Tests: 11 Failed: 0)
>>   Non-zero exit status: 5
>>   Parse errors: Bad plan.  You planned 25 tests but ran 11.
>> t/01_Struct.t     (Wstat: 1280 Tests: 5 Failed: 0)
>>   Non-zero exit status: 5
>>   Parse errors: Bad plan.  You planned 7 tests but ran 5.
>> Files=6, Tests=53, 19 wallclock secs ( 0.17 usr +  0.11 sys =  0.28 CPU)
>> Result: FAIL
>> Failed 2/6 test programs. 0/53 subtests failed.
>> NMAKE : fatal error U1077: 'C:\_64\perl1007\bin\perl.exe' : return code
>> '0xff'
>> Stop.
>> ###############################
>>
>> Is that as anticipated ?
>
> No; the Win32::API tests should pass (and do on my build). Can you find
> out which tests exactly are failing? That looks somewhat like the
> testsuite is crashing perl; in which test?

It's test 12 that crashes. When I clear the pop-up the test script aborts - 
no more tests get run in that script.

Here's the output:

C:\cygwin\home\Rob\GIT\win32-api>perl -Mblib t/00_API.t
1..25
ok 1 - use Win32::API;
ok 2 - use Win32::API::Test;
ok 3 - use Win32;
ok 4 - loaded
# API test dll found at (API_test64.dll)
ok 5 - found API test dll
ok 6 - GetCurrentProcessId() function found
ok 7 - GetCurrentProcessId() result ok
ok 8 - GetCurrentProcessId() result ok
ok 9 - Import of GetCurrentProcessId() function from kernel32.dll
ok 10 - GetCurrentProcessId() result ok
ok 11 - sum_integers() function defined

It's the '$function->Call(2, 3)' that causes the crash - which I guess means 
that the dll being accessed ("our own DLL") is not to my compiler's liking.

>
>> Now ... to try and find out why ml.exe is being called, instead of
>> ml64.exe.
>
> That sounds like your environment is set up for the 32-bit MSVC++
> toolchain, instead of the x64 one. Assuming you're using the vcvars batch
> file to set up your environment for NMAKE, are you giving it the right
> arguments for an x64 build?

I'm using the Microsoft Platform SDK for Windows Server 2003 R2 compiler
(same as ActiveState use to build x64 ActivePerl) and, to set up the
environment I run:

SetEnv.cmd /XP64 /RETAIL

That's the correct thing to do, afaik, and I've been getting good mileage
out of it.

I notice, however, that 'nmake /P' lists:

AS = ml

instead of the expected 'AS = ml64' - so, I guess either it's a bug in
nmake, or it's an nmake that expects a 32-bit environment. (I've checked,
and there's no 'nmake64.exe' or anything like that.)

As a fix, I've simply created a copy of ml64.exe named ml.exe in the same 
folder. (The 32-bit ml.exe is in a folder that's not in my path.)

Cheers,
Rob