[PHP-DEV] 64bit Windows builds

Hello all,

I've noticed that on windows.php.net that all the builds are x86. I
was wondering if there is any reason (technical or not) not to
distribute x64 builds as well there. It's quite annoying having to
constantly drop to a VM every time I need to test something that's 64
bit dependent...

Just a thought.

Thanks,

Anthony

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

hi,

Yes, there is a reason.

We do not support x64 binaries yet, for php itself and many libs used
by PHP. Some argues that it is safe. Btw, it is not faster to run on
x64 either.

php-next will have x64 support tho'.

Cheers,

On Wed, Jan 18, 2012 at 12:46 AM, Anthony Ferrara <[email protected]> wrote:
> Hello all,
>
> I've noticed that on windows.php.net that all the builds are x86.  I
> was wondering if there is any reason (technical or not) not to
> distribute x64 builds as well there.  It's quite annoying having to
> constantly drop to a VM every time I need to test something that's 64
> bit dependent...
>
> Just a thought.
>
> Thanks,
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Pierre Joye wrote:
> Yes, there is a reason.
>
> We do not support x64 binaries yet, for php itself and many libs used
> by PHP. Some argues that it is safe. Btw, it is not faster to run on
> x64 either.

Pierre ... please do not continue that statement without any evidence. ALL of
the benchmarks I've run on an identical hardware base with 64 bit Windows7 show
at least a 10% faster performance using a 64bit build of PHP. Speed improvements
are even more when all of the elements of the stack are 64bit, but even just
running 64bit PHP has an improvement. It would probably be useful to benchmark
32bit windows on the same hardware, but I don't have time to do that and the
machine was supplied with a 64bit W7, so I dn't hame a 32bit version of W7.

Of cause running 64bit Linux on the same hardware is at least 3 times faster
than the windows setup, and the machine is now just running Linux.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Lester,

On Wed, Jan 18, 2012 at 12:21 PM, Lester Caine <[email protected]> wrote:
> Pierre Joye wrote:
>>
>> Yes, there is a reason.
>>
>> We do not support x64 binaries yet, for php itself and many libs used
>> by PHP. Some argues that it is safe. Btw, it is not faster to run on
>> x64 either.
>
>
> Pierre ... please do not continue that statement without any evidence. ALL
> of the benchmarks I've run on an identical hardware base with 64 bit
> Windows7 show at least a 10% faster performance using a 64bit build of PHP.
> Speed improvements are even more when all of the elements of the stack are
> 64bit, but even just running 64bit PHP has an improvement. It would probably
> be useful to benchmark 32bit windows on the same hardware, but I don't have
> time to do that and the machine was supplied with a 64bit W7, so I dn't hame
> a 32bit version of W7.
>
> Of cause running 64bit Linux on the same hardware is at least 3 times faster
> than the windows setup, and the machine is now just running Linux.

This answer (totally uninformed and ignoring the main reason why we do
not support 64bit yet) is exactly what I warned about. Performance, if
it was faster (and it is not), is only the 3rd or 4th reason why we
cannot support x64 builds yet. Understand it.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Pierre Joye wrote:
> Lester,
>
> On Wed, Jan 18, 2012 at 12:21 PM, Lester Caine<[email protected]> wrote:
>> Pierre Joye wrote:
>>>
>>> Yes, there is a reason.
>>>
>>> We do not support x64 binaries yet, for php itself and many libs used
>>> by PHP. Some argues that it is safe. Btw, it is not faster to run on
>>> x64 either.
>>
>> Pierre ... please do not continue that statement without any evidence. ALL
>> of the benchmarks I've run on an identical hardware base with 64 bit
>> Windows7 show at least a 10% faster performance using a 64bit build of PHP.
>> Speed improvements are even more when all of the elements of the stack are
>> 64bit, but even just running 64bit PHP has an improvement. It would probably
>> be useful to benchmark 32bit windows on the same hardware, but I don't have
>> time to do that and the machine was supplied with a 64bit W7, so I dn't hame
>> a 32bit version of W7.
>>
>> Of cause running 64bit Linux on the same hardware is at least 3 times faster
>> than the windows setup, and the machine is now just running Linux.
>
> This answer (totally uninformed and ignoring the main reason why we do
> not support 64bit yet) is exactly what I warned about. Performance, if
> it was faster (and it is not), is only the 3rd or 4th reason why we
> cannot support x64 builds yet. Understand it.

Why not explain that better then? Rather than throwing in what is an incorrect
claim. I've PUBLISHED the performance figures (using the php benchmark
programs!)... and we have documented what 64bit stack works fine and passes all
the production tests. YES the 64bit build has a number of problems, and throws
lots of warnings when compiling, but using performance as a reason for why they
are not supported is not valid. There has been nothing posted to show why the
figures I am getting are wrong?

A much better reason for not supporting the build is probably that the 64bit
compiler is not available in the free development stack? We have to buy a
development stack to get the 64bit compiler which blocks rather than working
with the publicly available process :( But actually that is a better reason for
supplying a 64 bit build, and why others are providing that service.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Perfect, thanks.

And to be fair, I don't care about performance. I would like 64 bit integers...

Anthony

On Wed, Jan 18, 2012 at 1:45 AM, Pierre Joye <[email protected]> wrote:
> hi,
>
> Yes, there is a reason.
>
> We do not support x64 binaries yet, for php itself and many libs used
> by PHP. Some argues that it is safe. Btw, it is not faster to run on
> x64 either.
>
> php-next will have x64 support tho'.
>
> Cheers,
>
> On Wed, Jan 18, 2012 at 12:46 AM, Anthony Ferrara <[email protected]> wrote:
>> Hello all,
>>
>> I've noticed that on windows.php.net that all the builds are x86.  I
>> was wondering if there is any reason (technical or not) not to
>> distribute x64 builds as well there.  It's quite annoying having to
>> constantly drop to a VM every time I need to test something that's 64
>> bit dependent...
>>
>> Just a thought.
>>
>> Thanks,
>>
>> Anthony
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
>
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 1/18/2012 6:13 AM, Lester Caine wrote:
>
> A much better reason for not supporting the build is probably that the 64bit compiler is
> not available in the free development stack? We have to buy a development stack to get the
> 64bit compiler which blocks rather than working with the publicly available process :(
> But actually that is a better reason for supplying a 64 bit build, and why others are
> providing that service.

Actually, no. There are any number of free mechanisms to build 64 bit code.

The root problem is that Windows "WIN64" is a 64P architecture. Linux and
*nix variants, on the other hand, are 64ILP or 64LP. Meaning Windows has
longs/ints which are undersized compared to the *nix brethren. The old and
stale abuse such as unsigned long X = (unsigned long)pY; will not do what
the author intended.

This means all packages ported to *nix 64 bits may have very serious flaws
which have not been fixed for *Windows 64 bit* architecture. I'd anticipate
CoApp identifying and resolving most of these applicable to PHP over the
coming months, but it is a non-trivial problem requiring a number of pairs
of eyeballs to get right.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

William A. Rowe Jr. wrote:
> On 1/18/2012 6:13 AM, Lester Caine wrote:
>> >
>> > A much better reason for not supporting the build is probably that the 64bit compiler is
>> > not available in the free development stack? We have to buy a development stack to get the
>> > 64bit compiler which blocks rather than working with the publicly available process:(
>> > But actually that is a better reason for supplying a 64 bit build, and why others are
>> > providing that service.
> Actually, no. There are any number of free mechanisms to build 64 bit code.
Could you elaborate on that?
Building 64bit windows applications which are VC9 compliant would seem to need
the 'official' compiler, and while I have not done a lot of looking, there was
nothing being offered when I tried to set up the windows build environment form
Pierre's original notes although that was some time ago. I ended up buying an M$
development pack to plug the hole.

> The root problem is that Windows "WIN64" is a 64P architecture. Linux and
> *nix variants, on the other hand, are 64ILP or 64LP. Meaning Windows has
> longs/ints which are undersized compared to the *nix brethren. The old and
> stale abuse such as unsigned long X = (unsigned long)pY; will not do what
> the author intended.
>
> This means all packages ported to *nix 64 bits may have very serious flaws
> which have not been fixed for*Windows 64 bit* architecture. I'd anticipate
> CoApp identifying and resolving most of these applicable to PHP over the
> coming months, but it is a non-trivial problem requiring a number of pairs
> of eyeballs to get right.

I do accept that there are inherent problems with the current unsupported
builds, my own sites have not had any errors in serving PHP pages via a 64bit
Apache/PHP/Firebird stack on 64 bit windows XP. But I am more than happy to help
if a serious effort is made to tidy this up, and I still have two sites that I
can soak test on, although one of them is scheduled to switch to Linux in the
next six months.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 1/18/2012 12:14 PM, Lester Caine wrote:
> William A. Rowe Jr. wrote:
>> On 1/18/2012 6:13 AM, Lester Caine wrote:
>>> >
>>> > A much better reason for not supporting the build is probably that the 64bit
>>> compiler is
>>> > not available in the free development stack? We have to buy a development stack to
>>> get the
>>> > 64bit compiler which blocks rather than working with the publicly available process:(
>>> > But actually that is a better reason for supplying a 64 bit build, and why others are
>>> > providing that service.
>> Actually, no. There are any number of free mechanisms to build 64 bit code.
> Could you elaborate on that?
> Building 64bit windows applications which are VC9 compliant would seem to need the
> 'official' compiler, and while I have not done a lot of looking, there was nothing being
> offered when I tried to set up the windows build environment form Pierre's original notes
> although that was some time ago. I ended up buying an M$ development pack to plug the hole.

The SDK and DDK remain free with a minimal toolchain, including 64 bit
compilers. Of course they aren't called that anymore, because things
are only fun in the Windows world when they overhaul the glossary of
terms every 3 years.

You probably started with Express edition of Visual Studio, and I note
that it claims not to support 64 bit. But the compilers in the SDK or WDK
(Windows Drivers Kit formerly DDK) should solve your issue. I don't know
offhand whether these contain visual studio 15 or 16.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

hi,

On Wed, Jan 18, 2012 at 6:37 PM, William A. Rowe Jr.
<[email protected]> wrote:
> On 1/18/2012 6:13 AM, Lester Caine wrote:
>>
>> A much better reason for not supporting the build is probably that the 64bit compiler is
>> not available in the free development stack? We have to buy a development stack to get the
>> 64bit compiler which blocks rather than working with the publicly available process :(
>> But actually that is a better reason for supplying a 64 bit build, and why others are
>> providing that service.
>
> Actually, no.  There are any number of free mechanisms to build 64 bit code.

None of them are part of what we support tho' (we do not support mingw
for example, and won't support it).

> The root problem is that Windows "WIN64" is a 64P architecture.  Linux and
> *nix variants, on the other hand, are 64ILP or 64LP.  Meaning Windows has
> longs/ints which are undersized compared to the *nix brethren.  The old and
> stale abuse such as unsigned long X = (unsigned long)pY; will not do what
> the author intended.
>
> This means all packages ported to *nix 64 bits may have very serious flaws
> which have not been fixed for *Windows 64 bit* architecture.

That's a perfect good example of the numerous issues, and not only in
PHP itself but in all dependencies.

> I'd anticipate
> CoApp identifying and resolving most of these applicable to PHP over the
> coming months, but it is a non-trivial problem requiring a number of pairs
> of eyeballs to get right.

Not going to be supported by PHP any time soon, so I won't hold my
breath or put one cent on that tool at this stage (for php, as it is
what I can talk about right now).

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Wed, Jan 18, 2012 at 8:25 PM, William A. Rowe Jr.
<[email protected]> wrote:

> The SDK and DDK remain free with a minimal toolchain, including 64 bit
> compilers.  Of course they aren't called that anymore, because things
> are only fun in the Windows world when they overhaul the glossary of
> terms every 3 years.

The SDK only supports 64bit now too? I remember it was not the case,
but if yes that's pretty good :). VS Express editions do not, but
that's not really a problem :)

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

> On Wed, Jan 18, 2012 at 8:25 PM, William A. Rowe Jr.
> <[email protected]> wrote:
>
> > The SDK and DDK remain free with a minimal toolchain, including 64 bit
> > compilers.  Of course they aren't called that anymore, because things
> > are only fun in the Windows world when they overhaul the glossary of
> > terms every 3 years.

> The SDK only supports 64bit now too? I remember it was not the case,
> but if yes that's pretty good :). VS Express editions do not, but
> that's not really a problem :)

I can't say for VC9, but VC10 Express will compile 64 bit with the
"Windows SDK for Windows 7" + .NET Framework 4.0 installed. I believe
the compilers come with the Framework build additions. I'm currently
using this on another project.

> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Wed, Jan 18, 2012 at 9:43 PM, Niel Archer <[email protected]> wrote:
>> On Wed, Jan 18, 2012 at 8:25 PM, William A. Rowe Jr.
>> <[email protected]> wrote:
>>
>> > The SDK and DDK remain free with a minimal toolchain, including 64 bit
>> > compilers.  Of course they aren't called that anymore, because things
>> > are only fun in the Windows world when they overhaul the glossary of
>> > terms every 3 years.
>
>> The SDK only supports 64bit now too? I remember it was not the case,
>> but if yes that's pretty good :). VS Express editions do not, but
>> that's not really a problem :)
>
> I can't say for VC9, but VC10 Express will compile 64 bit with the
> "Windows SDK for Windows 7" + .NET Framework 4.0 installed. I believe
> the compilers come with the Framework build additions. I'm currently
> using this on another project.

IIRC you do not need to install Visual studio or VC express at all
with the Platform SDK. They all come with their own compiler. 6.1 has
VC9 (what we use for PHP), and 7+ has VC10 afair (or maybe only 7.1
has VC10).

However some tools that we use to build the official binaries are not
available in these versions, nor in the Express ones, especially for
5.4 where PGO builds are used.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 18/01/12 20:35, Pierre Joye wrote:
>> Actually, no. There are any number of free mechanisms to build 64 bit code.
> None of them are part of what we support tho' (we do not support mingw
> for example, and won't support it).
Actually, why couldn't mingw be supported one day?
(supposing someone did the work to change half the PHP_WIN defines to
PHP_MSVC)

Such binaries wouldn't be compatible with IIS, but mingw seems
preferible to the
legacy VC6 for use with the oficial Apache binaries.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/1/19 Ángel González <[email protected]>:

> Actually, why couldn't mingw be supported one day?
> (supposing someone did the work to change half the PHP_WIN defines to
> PHP_MSVC)

Too painful, somehow buggy (while it is way better lately) but the
main reason is total lack of binary compatibility with supported VC
versions. And we do not have the resources to provide support for more
than one compiler version at a time.

> Such binaries wouldn't be compatible with IIS, but mingw seems preferible to
> the
> legacy VC6 for use with the oficial Apache binaries.

There is no such thing like "official apache binaries", they provide
some as conveniences.

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 1/19/2012 5:29 AM, Pierre Joye wrote:
> 2012/1/19 Ángel González <[email protected]>:
>
>> Such binaries wouldn't be compatible with IIS, but mingw seems preferible
>> to the legacy VC6 for use with the oficial Apache binaries.

A couple of things to remember; msvcrt.dll is quite actively maintained,
even when it's maintained against the interests of php or the c language
standards bodies. This would not be true of msvcr70.dll, for example.
Actively supported is msvcr100.dll, of VisualStudio 2010, and that is what
the httpd project expects to ship some httpd 2.4.0 binaries with. But the
msvcrt.dll itself is neither less or more maintained so far than the
per-studio-release flavor. It's a shame that the NT/kernel team and the
VisualStudio team simply can't get along.

Any mingw/gcc build is going to bind right back to msvcrt.dll, nullifying
whatever train of thought you were pursuing. There are php-specific
defects that MS has chosen to err on the side of incompatibility to spec.

> There is no such thing like "official apache binaries", they provide
> some as conveniences.

Just as with php; these are open source, we give you the source. What
you the user proceed to do with it is with our blessings :) This is one
of the advantages of keeping build systems and dependencies as accessible
as possible, something I consider a flaw in php's win (and aix, solaris
and hpux support), and a laudable goal of the coapp effort (all the way
through pushing upstream their own shallow fork fixes).


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

hi Bill,

2012/1/20 William A. Rowe Jr. <[email protected]>:
> On 1/19/2012 5:29 AM, Pierre Joye wrote:
>> 2012/1/19 Ángel González <[email protected]>:
>>
>>> Such binaries wouldn't be compatible with IIS, but mingw seems preferible
>>> to the legacy VC6 for use with the oficial Apache binaries.
>
> A couple of things to remember; msvcrt.dll is quite actively maintained,
> even when it's maintained against the interests of php or the c language
> standards bodies.  This would not be true of msvcr70.dll, for example.
> Actively supported is msvcr100.dll, of VisualStudio 2010, and that is what
> the httpd project expects to ship some httpd 2.4.0 binaries with.  But the
> msvcrt.dll itself is neither less or more maintained so far than the
> per-studio-release flavor.  It's a shame that the NT/kernel team and the
> VisualStudio team simply can't get along.

Build tools suite and the crt available by default with windows are
totally different stories. Support VC compilers today (and for the
next couple of years) are VC9 and later (don't remember the state of
VC8 right now). And VC6 is dead. Mingw is barely a solution, sorry,
not only because of its VC6 binaries but its set of tools as well.

> Any mingw/gcc build is going to bind right back to msvcrt.dll, nullifying
> whatever train of thought you were pursuing.  There are php-specific
> defects that MS has chosen to err on the side of incompatibility to spec.

Not sure to understand what you try to say here. I suppose it is about
the incompatibilities between the various CRTs.

>> There is no such thing like "official apache binaries", they provide
>> some as conveniences.
>
> Just as with php;  these are open source, we give you the source.

Wrong, we do provide official binaries that we support. This is
totally different than what is done in Apache.

> What
> you the user proceed to do with it is with our blessings :)  This is one
> of the advantages of keeping build systems and dependencies as accessible
> as possible, something I consider a flaw in php's win (and aix, solaris
> and hpux support).

What you call a flaw, we call it reliability and easiness, for windows.

For Solaris, hpux or other aix, I never understood why they do not
provide native out of the box gcc+posix support in the same way *BSDs
do, but that's another story.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php