You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Gregg L. Smith" <gl...@gknw.net> on 2011/05/17 07:17:39 UTC
Windows Laundry List
Hi folks,
This was originally asked for by Jorge of blackdot.be back in July of 2006.
http://marc.info/?l=apache-httpd-dev&m=115394468128469&w=2
With the simple fact that every Windows computer I have seen being sold for some time now being x64, I do not see any reason to hold back on this since there is no functional change.
His patch looks like it would give out a redefinition warning, so here's my version. I'm using WIN64 where he uses _WIN64, the reason is both are being used, the former is used in numerous files throughout httpd & APR, the latter in mpm/winnt/child.c. My x64 conversion script defines WIN64 and the compiler _WIN64 so for me both are covered. Feel free to use whichever you prefer.
It would be nice to see this in both trunk & 2.2. Patch is against trunk, and patches 2.2 with fuzz due to following lines being different.
Thanks for your consideration in this matter.
Gregg
Re: Windows Laundry List
Posted by Jorge Schrauwen <jo...@gmail.com>.
On Tue, May 17, 2011 at 9:19 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> About the patch, yes this should go in. I'm busy for a day or few
> but flagged your message to come back to it, if there is a bugzilla
> incident please tag it 'depends on' PR 49997.
>
> On 5/17/2011 11:10 AM, Jorge Schrauwen wrote:
>>
>> Do the argument from a few year back still hold for the ASF not
>> providing them themselves still hold true for 2.3/2.4?
>> IIRC it had to due with VC6 being used for 3rd party module
>> compatibility. With the release of 2.4 series around the corner maybe
>> now is a good time to discuss this again?
>
> Correction; VC6 was used for *source file compatibility* within the
> build. dsp/dsw could be exported to makefiles, or loaded by later
> Developer Studio versions into vcproj/sln format. It was the only
> 'one single representation' that worked.
>
> For binaries, we used the MSVCRT which could be linked using VC6,
> but not safely by VC7 or later without DDK include files corresponding
> to the NT team's MSVCRT (rather than the compiler team's MSVCRxxx mess).
> Too many things relative to the MSVCR binaries are macros with all sorts
> of static assumptions.
>
> If I start preparing binaries for 2.4 to www.a.o/dist/httpd at all,
> it would be both 32 and 64 bit, and will either be Mladen's suggested
> WinDDK approach (using system MSVCRT) or the VC10 SP1 (current) way,
> still using industry-standard make/nmake, not msbuild nor gui proj.
>
That's good news, I had a chat with Guenter Knauf about this mess during FOSDEM,
We briefly discussed LLVM but I never got it working (most likely due
to time reasons).
I have no strong opinion on going VC10 or WInDDK... as long as the
users can get both flavors of binaries here.
> We may have reached the fork in the road where it no longer makes sense
> to maintain both a gui dsp/vcproj and makefiles from the studio solution.
> VC 7/2002 dropped support for exporting makefiles; VC 10 drops support
> for converting dsp/dsw into vcproj files. So if we want either dsp/dsw
> or vcproj/sln files, we may be at the point of adopting the subversion
> approach to generating these gui representations from makefiles or
> resources common to the unix build, as the apr project generates from
> the .
>
> We also continue to improve the interoperability with mingw/msys.
>
> Due to project and personal trolling, I've put the rest of the opinions
> on this (and certain individuals) into the /ignore list for now. I am happy
> to continue this dialog of what MS got wrong in the WinDDK approach,
> and why it may be just too much effort to ask users to assemble such
> a toolchain with comprehensive msvcrt link .lib's, and simply go with
> the VC10 optimizations and library (WinDDK includes a VC 9 generation
> of the compiler). MSVCRT is the kindest to our users consuming the
> software, but VC10's MSVCR100 is much kinder to module packagers and
> developers who wish to link to the same clib with minimal pain.
>
Indeed a system MSVCRT would be cleaner,... but if I look at most of
my windows machines they have a whole set of runtimes installed raging
from 2005,2008,... usually with and without SP's...
Chances are the end user will already have whatever version is needed.
Personally I think having it easier for the developers to link their
binaries would in the end be better for the user, since more modules
will be available for them to use (in binary form).
Jorge
Re: Windows Laundry List
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
About the patch, yes this should go in. I'm busy for a day or few
but flagged your message to come back to it, if there is a bugzilla
incident please tag it 'depends on' PR 49997.
On 5/17/2011 11:10 AM, Jorge Schrauwen wrote:
>
> Do the argument from a few year back still hold for the ASF not
> providing them themselves still hold true for 2.3/2.4?
> IIRC it had to due with VC6 being used for 3rd party module
> compatibility. With the release of 2.4 series around the corner maybe
> now is a good time to discuss this again?
Correction; VC6 was used for *source file compatibility* within the
build. dsp/dsw could be exported to makefiles, or loaded by later
Developer Studio versions into vcproj/sln format. It was the only
'one single representation' that worked.
For binaries, we used the MSVCRT which could be linked using VC6,
but not safely by VC7 or later without DDK include files corresponding
to the NT team's MSVCRT (rather than the compiler team's MSVCRxxx mess).
Too many things relative to the MSVCR binaries are macros with all sorts
of static assumptions.
If I start preparing binaries for 2.4 to www.a.o/dist/httpd at all,
it would be both 32 and 64 bit, and will either be Mladen's suggested
WinDDK approach (using system MSVCRT) or the VC10 SP1 (current) way,
still using industry-standard make/nmake, not msbuild nor gui proj.
We may have reached the fork in the road where it no longer makes sense
to maintain both a gui dsp/vcproj and makefiles from the studio solution.
VC 7/2002 dropped support for exporting makefiles; VC 10 drops support
for converting dsp/dsw into vcproj files. So if we want either dsp/dsw
or vcproj/sln files, we may be at the point of adopting the subversion
approach to generating these gui representations from makefiles or
resources common to the unix build, as the apr project generates from
the .
We also continue to improve the interoperability with mingw/msys.
Due to project and personal trolling, I've put the rest of the opinions
on this (and certain individuals) into the /ignore list for now. I am happy
to continue this dialog of what MS got wrong in the WinDDK approach,
and why it may be just too much effort to ask users to assemble such
a toolchain with comprehensive msvcrt link .lib's, and simply go with
the VC10 optimizations and library (WinDDK includes a VC 9 generation
of the compiler). MSVCRT is the kindest to our users consuming the
software, but VC10's MSVCR100 is much kinder to module packagers and
developers who wish to link to the same clib with minimal pain.
Re: Windows Laundry List
Posted by Jorge Schrauwen <jo...@gmail.com>.
I'm still all for this,
But do many people use a 64-bit variant of httpd it self? I've long
since switched to linux for both my server and my development
environment but still provide binaries I compile on my website. (If
I'm lazy I get about 2-3 mails per day asking for the newest release)
So here are some statistics from blackdot.be:
httpd/httpd-2.2.18-win64.rar 101 (went up yesterday)
httpd/httpd-2.2.17-win64.rar 16212
httpd/httpd-2.2.15-win64.rar 15750
httpd/httpd-2.2.14-win64.rar 10403
httpd/httpd-2.2.13-win64.rar 3110
httpd/httpd-2.2.12-win64.zip 801
httpd/httpd-2.2.11-win64.zip 14347
httpd/httpd-2.2.10-win64.zip 1521
httpd/httpd-2.2.9-win64.zip 2666
httpd/httpd-2.2.8-win64.zip 2181
httpd/httpd-2.2.4_x64.exe 4859
I wonder about the overall usage, more people seem to be compiling
them themselves recently and some other websites probably offer them.
Do the argument from a few year back still hold for the ASF not
providing them themselves still hold true for 2.3/2.4?
IIRC it had to due with VC6 being used for 3rd party module
compatibility. With the release of 2.4 series around the corner maybe
now is a good time to discuss this again?
Kind regards
~Jorge
On Tue, May 17, 2011 at 7:17 AM, Gregg L. Smith <gl...@gknw.net> wrote:
> Hi folks,
>
> This was originally asked for by Jorge of blackdot.be back in July of 2006.
> http://marc.info/?l=apache-httpd-dev&m=115394468128469&w=2
>
> With the simple fact that every Windows computer I have seen being sold for some time now being x64, I do not see any reason to hold back on this since there is no functional change.
>
> His patch looks like it would give out a redefinition warning, so here's my version. I'm using WIN64 where he uses _WIN64, the reason is both are being used, the former is used in numerous files throughout httpd & APR, the latter in mpm/winnt/child.c. My x64 conversion script defines WIN64 and the compiler _WIN64 so for me both are covered. Feel free to use whichever you prefer.
>
> It would be nice to see this in both trunk & 2.2. Patch is against trunk, and patches 2.2 with fuzz due to following lines being different.
>
> Thanks for your consideration in this matter.
>
> Gregg
>
>
>
>
>