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.

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?