On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote:
> Jan Dubois wrote:
>> 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?
That Platform SDK headers (in case the module uses APIs that were
introduced with Win2K or later), followed by the VC6 ones for traditional
CRT stuff.
> 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.
I don't see how Windows 9X/NT compatibility plays a role here. E.g.
for ActivePerl 5.10.0.10xx the minimum *supported* Windows version is
Windows 2000, but the code is still using MSVCRT.dll for the various
reasons I listed.
That being said, we don't go out of our way to *break* Win9X
compatibility, but we don't test on it, and won't try to fix anything
unless it is obvious/trivial.
I'm interested in the potential performance advantage though. Did
you do any measurements? I've only heard anecdotal evidence of a 5%
improvement that leaves me quite unimpressed (for things like PerlBench
a 5% difference is almost at the noise level).
>>> 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.
Sure, but how do resources cross? Isn't this always a module bug
to start with? Note that I have virtually no experience with the
particular issues you may see with Perl inside Apache, but I've
worked on many Perl embedding scenarios, putting Perl into COM
controls, Windows services and .NET applications, so I'm well aware
of the general issues, and how to solve them/work around them.
Therefore I'm genuinely interested to learn where the problems are
if you build say Apache with VS2008, Perl with VC6 and e.g. mod_perl
with VC7. I would expect this to work just fine if we ignore the
address space wasted by essentially unused surplus clibs.
>> 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).
It used to work in earlier Perl 5.8.x versions too, but later releases
of the 64-bit VC compiler in the Platform SDK broke things. I thought
I fixed this ages ago, but I guess I only submitted the necessary
patches earlier this year and they had not been included in any
official P5P release:
http://public.activestate.com/cgi-bin/perlbrowse/p/30878
However, there have been 64-bit ActivePerl releases of 5.8.8 on
Windows since August 2006.
Just FYI, all the 64-bit ActivePerl on Windows releases have been built
with the VC version from the Windows Server 2003 SP1 SDK. That compiler
is a special version of the VS2003 compiler that links against the
64-bit MSVCRT.dll instead of the MSVCR71.dll. You need to link in
a special bufferoverflowU.lib library if you use the /GS compiler option
because MSVCRT.dll doesn't include the runtime support for the buffer
overrun detection.
> 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.
Yes, please speak up; I'm very interested to hear about it.
> 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 may have missed these, as I only skim the mod_perl mailing lists.
I always assumes that you would either use the Newx()/Safefree() mechanism
from Perl, or a corresponding mechanism from APR to manage your memory.
Mixing them can be dangerous even with a single clib because the Perl
mechanism may use memory before and after the allocated block to detect
buffer overruns in testing builds etc.
> 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).
It should not really matter. OpenSSL is a separate DLL and it should
work regardless which clib the user is using. Everything else would be
a bug in OpenSSL (or very poor design of the API, by e.g. accepting
a FILE* parameter directly).
I sure hope that the problems can be solved by proper encapsulation of
the different components. Re-releasing all components in sync whenever
Microsoft releases a new compiler sounds like a very bad idea to me.
Cheers,
-Jan
