in reply to a tale of the windows runtime libs

I was doing something similar a short time ago. ActiveState Perl is built using a compiler that uses the run-time library that's used by the Windows internal stuff and many supplied apps, so that's easier. ActiveState Perl is built using a version of the compiler (from "PlatformSDK for Windows Server 2003 R2") that doesn't require the "Manifest" be inserted, and behaves normally if that DLL is just plain found, so that is easier.

The static lib is only available on 32-bit platforms, BTW.

The crash occurs because of memory heaps. Windows was designed to avoid this problem by having a per-process heap that all code can discover. The compiler RTL then circumvents this and creates a new heap instance. Had they used GetProcessHeap instead of CreateHeap (or whatever they are called), it would not have been an issue.

If code allocates memory from one heap and frees it on another, things break.

The solution would be for the main perl interpreter dll to export a malloc/free pair of functions that are to be used by all XS code. Maybe it does and is under appreciated. Maybe that feature is missing? I don't know.

—John
Updated.

Replies are listed 'Best First'.
Re^2: a tale of the windows runtime libs
by syphilis (Archbishop) on Jun 05, 2009 at 00:45 UTC
    ActiveState Perl is built using a compiler that uses the run-time library that's used by the Windows internal stuff and many supplied apps, so that's easier

    Both ActiveState Perl and Strawberry Perl use the same C runtime. Wrt to cfreeman's specific issues, neither has any advantage over the other.

    cfreeman have you considered using the MinGW compiler (that ships with Strawberry Perl, and is also freely available elsewhere) to build the dll's - instead of using the incompatible VC9 ? That would be the best solution, imo - there would then be no problem using those dll's with either ActivePerl or Strawberry Perl.

    Cheers,
    Rob
      It would still have the malloc/free problem with ActiveState.

      If the XS doesn't use the rtl's malloc and free (see the other reply from Anonymous), I agree the MinGW's code is easier to distribute.

Re^2: a tale of the windows runtime libs
by Anonymous Monk on Jun 05, 2009 at 02:23 UTC
    See perlclib, XS code is supposed to use New/Safefree