> I asked Jan Dubois at ActiveState about this, just to verify - > the relevant excerpt of his reply follows ...
Luckily I'm on both lists (or at least I got a copy of Jan Dubois reply as well). Thank you for this. >>Perhaps related to this, was this build compiled with VC++ 6? > > Yes. For various reasons, we decided to continue to build > ActivePerl with VC++ 6 SP3. I'm pretty sure that later service > packs should be compatible too as the core Perl code doesn't use > C++ anymore (the PERL_OBJECT stuff contained pointers to member > functions, which changed size in VC++ 6 SP4 and later). > > I've also (just for testing) compiled extension DLLs for > ActivePerl 633 and 802 using the free, non-optimizing VC++ 7 > compiler from the .NET Framework SDK. It worked just fine, but > it will use MSVCR70 instead of MSVCRT for the runtime library, > resulting in 2 different C runtime libraries being loaded. This > is potentially a problem with structured exception handling for > C++, but should work fine for "normal" C extension code too. > >From this and other comments, I gather having two runtime libraries is a Not-So-Good-Thing (tm) I will probably breakdown and add VC++ 6 to my collection of toys. I'm far from an adaquate C programmer. Thank you for all your work supporting us red-headed step children in the Windows world. -Chris
