Jan Dubois wrote:
On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote:
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.
Bingo! Ok, so we are clear, we are still building to VC6. I just wanted
to clarify that this isn't mixing and matching to MSVCRxx headers from
a later compiler.
In theory that might even be possible, but it's only fair to point out that
it's becoming impossible to download VC6 or obtain the SDK flavor which
will actually compile under it. Or are you compiling with a more modern
VC against the older VC6 headers? (The issue with obtaining them remains).
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.
Right - understood.
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.
:) Ditto, although I'm less vigorous about providing dynaload thunks
now, unless a 2008/Vista or 2003/XP API would break on 2000.
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).
Right; we have entirely different designs on performance. For httpd,
5% would be a godsend :) I'll be collecting and reporting on such in
the near future.
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.
Yup - it's almost always the same story; some API returns memory that
it expects the caller to free(), rather than a corresponding API release
call. There are a host of such examples in the way that mod_perl was
implemented. Even some of the API's (as I hint about the SSL modules)
which are implemented as xs's that behave similarly.
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.
Right; we aren't talking about optimizing, but simply interop.
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.
Interesting detail, thanks. I had presumed as much (or that you had built
it against an earlier DDK before they incorporated this fully into the SDK).
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.
Right - of course should-be and are-actually are two different things :)
And it's only fair to point out this isn't win32 specific, libs linked
against an optimized allocator on various flavors of unix will blow up
in similar ways when the consuming app is linked to the 'stock' allocator.
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.
+1 - although it might not be possible for realistic applications today,
it's an admirable goal to define these API's correctly :-)
Bill
