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
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.