Jan Dubois wrote:
The initial switch away from MSVCRT.dll was due to a conflict inside
Microsoft between the Windows and the VC++ teams: MSVCRT.dll has become
so important to the operation of Windows itself that the compiler team
was no longer allowed to update it; ownership had been transferred to
the OS team and the only update vehicle was Windows Update. This made it
impossible to include updated versions of MSVCRT.dll with Visual Studio
releases, and the compiler team went back to versioned runtime
libraries.
A very interesting perspective, thanks!
I still haven't seen a compelling argument why someone wants to move
away from using MSVCRT.dll (and then continue switching CRTs then every
other year).
The obvious question is; what are your include libraries for that module?
The modern compiler's? (e.g. studio 200X?) The SDK's? Or continue to
build with VC 6?
I'm concerned about drift; I understand the advantages to msvcrt.dll, but
fail to see where the proper headers are derived from, and agree with some
other posters that the performance advantage to moving to a more modern
compiler will outweigh the desire to remain "windows 9x" compatible.
One aspect of my current vc perspective is that really NT 4.0 and 9x are
now "dead", as in "harmful when installed in the network cloud". So with
the loss of further security fixes to the NT4/9x class OS's, I'm moving
away from their support whatsoever for httpd 2.4 (3.0?) binaries.
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.
I tried back in the VS.NET days to compile with VC7 and link against
MSVCRT.dll. It turned out to fail in some cases when compiler generated
code (under C++) called help functions not present in MSVCRT.dll.
I'd expect that... but I'm more concerned about insidious failures which
aren't clean compile/link time exceptions.
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.
Why? What problems are going to happen?
The major class of problems happens that there is one posix files table
per linked clib, one memory pool per linked clib, etc. When resources
cross from one to the next, that's the crux of the issue.
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.
This is not correct. All the 64-bit support code is already in Perl 5.8.x
as well.
Ack, 5.8.9 IIUC, but AFAIK the 5.8.9 release was held up by our favorite
perlmongers to put their full attention to 5.10 first (good choice IMHO).
I have no idea what you are trying to get at here, and where your
fatalistic attitude comes from. If there is a real problem using
ActivePerl with mod_perl, then please let me know about it. I'm
sure we can work it out. :)
Certainly some folks who are actively using it already will chime in,
I'm looking forward to their specific examples - it's why I brought this
up on modperl's list.
I'm not meaning to badmouth AS (to the contrary, it's my bootstrap of
any new box I personally use until and if I get around to building perl
and python myself), but point out that the glue in malloc/free, faux-posix
entities etc that have to span httpd to apr to modperl to perl do have
issues today that have been reported on-list.
I suspect a good number of these will, ultimately, be resolved with a
consistent clib across all components.
Alternate solution is for each component to manage it's own resources
and abstract them for the consumer; we are getting there, slowly. The
breadth of cpan packages doesn't make this easier ;-)
For example, OpenSSL needs to be built for both a host of perl ssl
packages and for httpd mod_ssl (and apr-util, in the near future).
Which build? One compiled on VC 9 or VC 6?
Bill
