Re^2: Win32::API Memory Exception with GetCommandLine() (which returns a static string)

[BrowserUk]

At the core of Win32::API are several small piece of assembler code:

#if (defined(__BORLANDC__) && __BORLANDC__ >= 452)
    #define ASM_LOAD_EAX(param,type)  {   \
        __asm {                      \
            mov    eax, type param ; \
            push   eax             ; \
        }
/* MSVC compilers */
#elif defined _MSC_VER
    /* Disable warning about one missing macro parameter.
       TODO: How we define a macro with an optional (empty) parameter?
+ */
    #pragma warning( disable : 4003 )
    #define ASM_LOAD_EAX(param,type) { \
    __asm { mov eax, type param }; \
    __asm { push eax };            \
    }
/* GCC-MinGW Compiler */
#elif (defined(__GNUC__))
    #define ASM_LOAD_EAX(param,...)  asm ("push %0" :: "g" (param));
#endif

...
              ASM_LOAD_EAX(pParam, dword ptr); ## many similar

...

#if (defined(_MSC_VER) || defined(BORLANDC))
                __asm {
                    mov   eax, dword ptr [dParam + 4]  ;
                    push  eax                          ;
                    mov   eax, dword ptr [dParam]      ;
                    push  eax                          ;
                };
#elif (defined(__GNUC__))
/* probably uglier than necessary, but works */
asm ("pushl %0":: "g" (((unsigned int*)&dParam)[1]));
asm ("pushl %0":: "g" (((unsigned int*)&dParam)[0]));

/* { 
  int idc;
  printf ("dParam = ");
  for (idc = 0; idc < sizeof(dParam); idc++) {
    printf(" %2.2x",((unsigned char*)&dParam)[idc]);
  } 
  printf("   %f\n", dParam);
} */
#endif

One has to suspect, if the OP confirms he is using a mingw built version of Perl that the problem lies in there somewhere. Does mingw build using similar calling conventions to MSC? That is the PASCAL calling convention for system apis.

[syphilis]

One has to suspect, if the OP confirms he is using a mingw built version of Perl that the problem lies in there somewhere

There's a couple of different possibilities:
1)It's MinGW-built perl using MinGW-built Win32::API;
2)It's MinGW-built perl using VC-built Win32::API;

I'm in the second category (with Win32-API-0.46). I also have Win32-API-0.46 on ActiveState perl (build 819) - it is exactly the same binary as I'm running on my MinGW-built perl, but there's no GPF with ActivePerl ... which leads me to the conclusion that the problem might lie outside Win32::API.

I still get the same length discrepancy on ActivePerl - ie Inline's 20 vs Win32::API's 21.

Cheers,
Rob

[BrowserUk]

I still get the same length discrepancy on ActivePerl - ie Inline's 20 vs Win32::API's 21.

I have a vague recollection that somewhere in Win32::API, they have code to extend the length of various strings/buffers passed in and/or out by one to 'allow room for terminating nulls'.

Maybe I'm too tired or mis-remembering, because I cannot find it now? :(

[syphilis]

I've just noticed that if I take the OP's code out of the batch file, it works ok (no faults) though it still returns the wrong string.

Also, if I replace the OP's code in the batch file with:

use Win32::API;

$function = new Win32::API("kernel32", "GetCommandLine", '', 'P');

$string = $function->Call();

print "string[".length($string)."] = '$string'\n";

then the batch file runs without error and $string no longer contains the additional trailing space - ie Win32::API and Inline are in complete agreement.

A problem with the Import method perhaps ? ... I've never trusted it.

Cheers,
Rob
Update: As BrowserUk has subsequently demonstrated, it's the pack('Z*', ...) that leads to the extra trailing space - nothing to do with Win32::API->Import() at all.