On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote: > 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.
You can expect a new runtime library version for each compiler release from Microsoft. This started back with VS.NET (MSVCR70), VS2003 (MSVCR71), VS2005 (MSVCR80) and now VS2008 (MSVCR90). 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. > 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. This is not really true for Perl, which abstracts all runtime library dependencies away. As long as you include the Perl headers in your module code, you will use the same runtime library as Perl itself. > 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. This was a conscious decision: Using MSVCRT.dll as the runtime library has many advantages: the library is already installed on *all* Windows systems, so you never need to distribute it yourself. This is important for tools like PAR, PerlApp and Perl2Exe that create selfcontained executables of Perl applications. Using MSVCRT.dll also allows to use both VC++6 and GCC from MinGW without loading duplicate runtimes. 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, 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. > 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? > 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. > 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. 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. :) Cheers, -Jan
