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