in reply to WIN32-API Purgetory

Frankly I'm staggered that Win32::API version 0.47 compiles, never mind actually works sometimes.

There is a source code error in http://search.cpan.org/src/COSIMO/Win32-API-0.47/API.xs:

/* Borland C */ #if (defined(__BORLANDC__) && __BORLANDC__ >= 452) #define ASM_LOAD_EAX(param,type) { \ ^ |-- THIS IS AN UNMATCH BRACE __asm { \ mov eax, type param ; \ push eax ; \ } /* MSVC compilers */ #elif defined _MSC_VER

But...in the resultant .c file after XS preprocessing the effect is that the apparent closing brace of the Call function:

#line 841 "API.c" PUTBACK; return; } } <-----------THIS MATCHES THE EXTRA OPEN BRACE ABOVE>

matches up with that conditionally compiled excess open brace above.

And if you delete the excess brace, the closing brace of the Call function:

#line 837 "API.c" PUTBACK; return; } } <-------------THIS ONE

Now no longer matches anything. The second to last closing brace (the line above) matches the open brace of the Call function. Quite how that succeeds in compiling is a mystery to me.

The upshot (so far) is that the function USPS4CB is being called successfully and the return parameters are being stacked successfully. But when the Call function attempts to return to the Perl code, the stack violation occurs. The changes that have been made recently (for compatibility with Strawberry Perl?) seem to have royally screwed things.

Beyond that, the problem is shrouded in the mysteries of XS preprocessing which is beyond my frustration level. Now I'm off to relocate a copy of Win32::API 0.41 that works. The simplest alternative I can offer is a C program callable with backticks. See the comment at the bottom for build instructions and sample usage:

[0] Perl> print `663116.exe 30702021202000000001 27203643012`;; ATTDAATFADDDTDDTFTFFADADFDTDDAFTATTAAATAAFTFADFDTTTFADAFDDATDDTFT

The C source:

#include <stdio.h> #include <windows.h> typedef int (*USCS4CB)( char t[21], char r[12], char b[66] ); int main(int argc, char *argv[]) { HINSTANCE hinstLib; USCS4CB fp; char track[21]; char route[12]; char bar[66]; int rc; if( argc != 3 ) { fprintf( stderr, "usage: %s trackcode(20) routecode(11)\n", ar +gv[0] ); exit( -3 ); } if( hinstLib = LoadLibrary( TEXT("usps4cb") ) ){ if( !( fp = (USCS4CB) GetProcAddress( hinstLib, "USPS4CB" ) ) +) { fprintf( stderr, "Couldn't obtain proc addr for USCS4CB(); rc:%x\n", GetLastError() ); exit( -5 ); } } else { fprintf( stderr, "Couldn't load USCS4CB.dll; rc %x\n", GetLast +Error() ); exit( -4 ); } if( strlen( argv[ 1 ] ) != 20 ) { fprintf( stderr, "Param 1 (Track code) not 20 digits\n" ); exit( -1 ); } memcpy( track, argv[1], 20 ); track[20] = '\0'; if( strlen( argv[ 2 ] ) != 11 ) { fprintf( stderr, "Param 2 (Route code) not 11 digits\n" ); exit( -2 ); } memcpy( route, argv[2], 11 ); route[11] = '\0'; memset( bar, 0, sizeof( bar) ); if( rc = (fp)( track, route, bar ) ) { fprintf( stderr, "USPS4CB failed with rc:%d\n", rc ); exit( rc ); } printf( bar ); return 0; } /* C:\test>cl 663116.c Microsoft (R) 32-bit C/C++ Standard Compiler Version 13.00.9466 for 80 +x86 Copyright (C) Microsoft Corporation 1984-2001. All rights reserved. 663116.c Microsoft (R) Incremental Linker Version 7.00.9466 Copyright (C) Microsoft Corporation. All rights reserved. /out:663116.exe 663116.obj C:\test>.\663116 usage: .\663116 trackcode(20) routecode(11) C:\test>.\663116 3070202120200000001 27203643012 Param 1 (Track code) not 20 digits C:\test>.\663116 30702021202000000001 2720364302 Param 2 (Route code) not 11 digits C:\test>.\663116 30702021202000000001 27203643012 ATTDAATFADDDTDDTFTFFADADFDTDDAFTATTAAATAAFTFADFDTTTFADAFDDATDDTFT */

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^2: WIN32-API Purgetory
by cosimo (Hermit) on Jan 29, 2008 at 22:51 UTC

    This is a lot of useful information for me, as I'm still willing to fix problems and make Win32::API more usable. I'm not abandoning that, even if I have really little spare time, which BTW is partly dedicated to Perl 6.

    I have discovered this node randomly. Please next time you find problems in Win32::API, can you also forward me your comments?

    I know I'm certainly not the best Win32 developer out there, but I'm trying to get the job done. Thanks!

      Since someone managed to take offence at my previous purely factual post, I'll add a little opinion.

      Please do not be defensive about your "Win32 developer"skills, nor take offense at my "royally screwed" remark. The problem that is apparently the cause of this has nothing to do with you, or your skills. There is no way that file should compile with unbalanced curlies in the C-level source code.

      The problem lies entirely in the XS pre-preprocessor processing as far as I can tell. It all seems to come down to the bugbear that is XS programming, namely macro hell. The fact that my editor can detect the unbalanced curly in the source, but the compiler does not, indicates that the unbalanced curly is not making it into the compiler. Ie. the C-pre-processor is conditionally excluding the responsible bit of source before it gets to the C parsing phase.

      The reason it hasn't show up as a compile time erro, is because it is in a piece of code conditionally included only for the Borland compiler, and no one uses that anymore. But that still doesn't explain how it can be affecting MSC builds?

      I did try to examine the post preprocessor output (/E), but once you've run that, all of the XS and guts macros are expanded and it is nigh impossible to relate pre-processed C to post-processed C. Never mind pre-preprocessed XS to post-processed C.

      I spent nearly 4 hours trying to understand what was going on. But as 735 lines of XS becomes 865 lines of C, becomes 114,700 lines of preprocessor output, it is a nearly pointless task. Even once you've discarded the 90,000 blank lines, it still leaves 25,600 to wade through. Even doing my best to whittle that lot down to just the stuff produced from the API.XS/API.c file, you still end up with 4000+ lines. And they look like this:

      And I'm afraid that even if my editor could handle bracket matching in that lot, my brain can't. That's why I stay as far away from XS programming as I can. When it works it's fine. But when it stops working, the unix-centric documentation, total reluctance to share or help by the practitioners and sheer insanity of the macros make it a totally thankless task.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
      Please next time you find problems in Win32::API, can you also forward me your comments?

      Sorry. I would have done so if the OP hadn't already said "I have placed bug reports on the ActiveState website #74361 and CPAN #32424". Which I assumed would come to you, and point you here?


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
Re^2: WIN32-API Purgetory
by jkretlow (Novice) on Jan 22, 2008 at 18:47 UTC
    Thank you for looking into this. I have placed bug reports on the ActiveState website #74361 and CPAN #32424. I am sure that your input would be helpful in resolving this for the community.