FAQ
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

Search Discussions

  • Pierre Joye at Jan 18, 2012 at 10:49 am
    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 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
  • Lester Caine at Jan 18, 2012 at 11:21 am

    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
  • Pierre Joye at Jan 18, 2012 at 11:47 am
    Lester,
    On Wed, Jan 18, 2012 at 12:21 PM, Lester Caine 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,
  • Lester Caine at Jan 18, 2012 at 12:13 pm

    Pierre Joye wrote:
    Lester,

    On Wed, Jan 18, 2012 at 12:21 PM, Lester Cainewrote:
    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
  • William A. Rowe Jr. at Jan 18, 2012 at 5:38 pm

    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.
  • Lester Caine at Jan 18, 2012 at 6:14 pm

    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
  • William A. Rowe Jr. at Jan 18, 2012 at 7:25 pm

    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.
  • Pierre Joye at Jan 18, 2012 at 7:37 pm

    On Wed, Jan 18, 2012 at 8:25 PM, William A. Rowe Jr. 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 :)
  • Niel Archer at Jan 18, 2012 at 8:44 pm

    On Wed, Jan 18, 2012 at 8:25 PM, William A. Rowe Jr.
    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
  • Pierre Joye at Jan 18, 2012 at 8:49 pm

    On Wed, Jan 18, 2012 at 9:43 PM, Niel Archer wrote:
    On Wed, Jan 18, 2012 at 8:25 PM, William A. Rowe Jr.
    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 Joye at Jan 18, 2012 at 7:35 pm
    hi,

    On Wed, Jan 18, 2012 at 6:37 PM, 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.
    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,
  • Ángel González at Jan 18, 2012 at 11:04 pm

    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.
  • Pierre Joye at Jan 19, 2012 at 11:29 am

    2012/1/19 Ángel González <keisial@gmail.com>:

    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.
  • William A. Rowe Jr. at Jan 20, 2012 at 3:42 am

    On 1/19/2012 5:29 AM, Pierre Joye wrote:
    2012/1/19 Ángel González <keisial@gmail.com>:
    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).
  • Pierre Joye at Jan 20, 2012 at 9:20 am
    hi Bill,

    2012/1/20 William A. Rowe Jr. <wrowe@rowe-clan.net>:
    On 1/19/2012 5:29 AM, Pierre Joye wrote:
    2012/1/19 Ángel González <keisial@gmail.com>:
    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,
  • Anthony Ferrara at Jan 18, 2012 at 12:51 pm
    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 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 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJan 17, '12 at 11:46p
activeJan 20, '12 at 9:20a
posts17
users6
websitephp.net

People

Translate

site design / logo © 2022 Grokbase