Well folks, here's the news... Studio 2008, true to form, proves that MS is incapable of keeping around a stdc library any longer than one product cycle. Yes, our long awaited (not) MSVCR90 is here.
Just to put it in perspective, cross-library malloc/free, stdio and some other facilities are tightly integrated into the clib, such that compiling the application under one flavor, and using a library of another which modifies the application's memory/stdio allocations causes no end of troubles. You might be also curious if AS is making progress at coming to a new baseline msvcrt for perl, since they had adopted Studio 2003's msvcr71 for python. Unfortunately, this version is also built under msvcrt. The obvious question, why not compile apache and perl under vc 8 or 9 but link to msvcrt.dll? The trouble which comes in here is that their std headers correspond to msvcr90, not to msvcrt. As that library evolves, it's going to inevitably drift from the msvcrt.lib. My instinct, with 2008 adding the new SDK features for apr such as multicast group filtering, and the continued availability of a 2008 'express'/'lite' free version, is to take httpd 2.4 (3.0?) binaries for apache httpd to this 2008 release. Yes, probably retain either .dsp files, or a makefile structure which allows folks to build to anything from VC6 to a 'plain SDK' (it now includes the compilers and tools), but for binaries, this will become foobar for folks who use ActiveState. Perl 5.10 is interesting for it's attention to Win32 64P model builds (64ILP reflects an OS which represents int, long, pointer as 64 bits, so Win32's 64P model reflects a 32 bit int/long, and 64 bit pointer). Because 64P is unusual in the family of 64 bit OS's, it's received the least attention of all of the platforms. Perl 5.10 is purported to catch win32 up significantly to the tried-and-true linux, solaris, bsd 64 bit flavors. So I'm posting this mostly for feedback to the rational of moving to a compiler that will generate reliable 32 *and* 64 bit builds of httpd, will be freely available (the point of the ASF is the source, and that users can do something with it), and that decision will be locked at the 2.4 release based on our strong commitment to binary compatibility. It's very true that modules compiled for another runtime can coexist very happily when the module does not free allocations from another component, don't attempt to share faux-posix stdio resources, etc. mod_aspdotnet is a great example; compiled with VS.NET or VS2005 it lives very happily in a VC6 build of httpd. But the way that perl, mod_perl and httpd interact is not that trivial, and highly prone to this class of problems. So I figure if there's a plan here, it will likely satisfy the 80/20. If AS Perl can't part of that solution, so be it. Bill
