I noticed that here the memory used by httpd.exe is less when I comment out:
#Win32DisableAcceptEx
#EnableSendfile Off
#EnableMMAP off
Looks like the use of AcceptEx()is no pain anymore.
I made a build available on http://www.apachelounge.com
The supported Windows I have bumped up, and the minimum system required:
Windows Server 2008
Windows Vista
Windows Server 2003 SP1
Windows XP SP2
Consequense is that Win2000 and Windows less then XP2 is not supported.
Interesting new in VC9 is:
The compiler contains tuning for the Intel Core microarchitecture during
code generation. This tuning is on by default and cannot be disabled as it
also helps Pentium 4 and other processors.
Steffen.
----- Original Message -----
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, 05 March, 2008 22:42
Subject: Re: Experience with Visual Studio 2008 Professional Edition
Steffen wrote:
Just to inform you.
We at Apache Lounge done the first build with Visual Studio 2008
Professional Edition.
Congrats - did the same last week against 2008 in 64 bit mode. My
results essentially mirrored yours for 32 bit builds, although I'm having
mixed success with x86_64 (which you wouldn't touch not looking at trunk,
more on that story in a moment)...
Changed in apr.hw (otherwise errors):
#define _WIN32_WINNT 0x0600
Actually - not necessary with the patch already committed to 1.2.x branch,
hoping we can release an apr 1.2 before the next roll (our Mac OSX fans
should appreciate that as well, if sendfile can be coerced to behave).
IDE build goes fine with no errors.
My struggle is on trunk; changes I hope to apply back to the live branch.
Right now, VS 2008 (unlike 2005) has a bug of "eating" and discarding the
x64 project targets. This is badness since APR already provides x64
flavor
projects, and these set up the NT-only code paths (so we aren't pretending
to be compatible to 9x or ME).
We could also conditionally allow the macro you mention above,
_WIN32_WINNT,
to bump up to 0x0501 or so. This would also break NT (funny the macro is
named WINNT), but speed things up at run time some small bit, and permit
us
to use the multicasting API's.
The goal was to extend x64 targets to httpd; but considering the failures
to import these into visual studio 2008 I'm less excited about the idea
now.
May proceed for 2.2.9, but the caviat will be - import first as a VS 2005
project, then convert that solution to VS 2008.
First impression:
Apache runs fine on my XP box, including mod_ssl.
Only mod_deflate was not loading. Rebuilding Zlib (ms-asm) with VC9 and
then build mod_deflate again and it
starts and works.
missed a step with your initial build of zlib, perhaps? Have had no
trouble
with zlib at all, note the build patches that have been used which are at
http://www.apache.org/dist/httpd/binaries/win32/patches_applied/
which tweaks the rev bits, embeds the manifests and quiets the compiler.
The biggest hassle has been perl (again!) Various perl packages when
built
against ActiveState for x86_64 cannot speak politely to openssl. Too many
stupid sizeof(int) == sizeof(void *) ass*u*me*ptions.
Also all the modules build with VC8, like mod_security 2.5.0, mod_watch,
mod_fcgid, mod_vieuw are running.
Yup - 32 bit is really painless; its the 64 bit universe that is painful,
still.
Bill
