This is one of a series of blog posts about my experience competing in the European WinPHP Challenge 2009. Sponsored by iBuildings, Microsoft and Leaseweb, competitors are asked to build a PHP app for Windows Server 2008 and IIS 7 to showcase the FAST in FastCGI. The winner gets travel and tickets to Microsoft MIX 2010 in Las Vagas in March. My entry is “Give It A REST”, a SOAP <-> REST gateway.

In an earlier post, I described my experience in building a (hopefully) suitable PHP development environment on Windows Server 2008. Since then, a couple of folks have kindy sent some feedback to help improve my understanding a couple of the sticking points I mentioned.

In the Zend Forums, this post describes how to get xdebug up and running under Zend Server on Windows (via Bram). Sadly, Zend’s build of PHP still crashes after following these instructions. Commenting out the Zend Extension Manager seems to stop these crashes, but I’m not sure that’s a compromise I’m willing to make. As I mentioned before, whilst I’d normally choose to install xdebug into any environment I’m working on, it’s not a big deal for me on this project because I am interested in seeing what Zend’s environment has to offer on Windows.

Elizabeth N. Smith from the PHP Windows teams kindly pointed out that the downloads page on www.php.net does indeed offer a NTS (non-thread-safe) build of PHP for Windows further down the page. I’m planning on plundering the PDO driver for MS SQL from there and evaluating it as part of my R&D phase.

Sadly, though, I’ve not seen anything said about why there isn’t a binary standard for PHP on Windows :( These binary incompatibilities just seem to re-enforce why proprietary products on proprietary platforms should be avoided.

13 Comments

  1. Pierre says:
    April 30th, 2009 at 8:51 am

    php.net’s PHP on windows is not a proprietary software. Everything is available, sources, libraries used, how it is built, etc. You can find all binaries and installers here: http://windows.php.net. I would recommend to use the snapshots for 5.3, until the next RC :)

    However the Zend Server is a proprietary software (community edition included). It does not rely on the stock php sources and has its own changes and builds.

    If you use IIS for your development, you can also use the Microsoft Web Platform installer to configure your box. It installs everything you may need (IIS, sqlserver, fcgi module, etc.) and uses http://windows.php.net binaries. That means that you can even get support via php.net without troubles.

  2. Pierre says:
    April 30th, 2009 at 9:18 am

    PHP 5.2 supports SqlServer via PDO_MSSQL, ext/mssql or the microsoft SQL Server driver (known as sqlsrv).

    PHP 5.3 on windows has no sqlserver support (sigh). That’s rather bad as 5.3 is really the best PHP release ever for windows.

  3. Stuart Herbert says:
    April 30th, 2009 at 2:54 pm

    Hi Pierre,

    If PHP 5.3 on Windows has no SQL Server support, how can it possibly be the best PHP release ever for Windows? :P Come on, be serious.

    Any chance of an answer about my comment on establishing a binary format for PHP on Windows? I notice it’s been dodged again :( It’s not for me really to say one way or the other, but I’m not clear on why the files at the top of downloads.php.net (and therefore, the files most people will download) are the thread-safe builds, rather than the NTS builds.

    Have you got any information about why someone should choose one over the other? If not, why offer both? I really feel you’re making somewhat of a mess for real ISVs looking to use Windows, and as a result Zend Server will probably become the standard for PHP on Windows over time.

    Microsoft Web Platform installer I’ve already commented on, and explained why I couldn’t recommend it as things stand. Since then, also occurred to me … MWP might be useful for a dev environment, but in a production environment, who would choose SQL Server Express? Isn’t that version of SQL Server somewhat crippled, and also does its licensing allow for use in production?

    Best regards,
    Stu

  4. Pierre says:
    April 30th, 2009 at 3:14 pm

    > Come on, be serious.

    I’m damned serious. Look at we have done so far, portability, new features, new libraries, perf improvement, use of a modern compiler.

    about NTS (non thread safe) vs TS (thread safe), It is not a matter of choice but a matter of what kind of SAPI you use:
    - NTS is for fastcgi and CLI
    - TS is for Apache or ISAPI

    Fastcgi is the recommended SAPI for IIS5/6/7. You can download the PHP NTS version at http://windows.php.net

    Zend Server has the *exact* same situation, with another problem: they are not compatible with php.net’s binaries which brings even more troubles for the end user.

    Last but not least, it is *not* windows specific. The same applies on unix platform where you can have a TS or NTS SAPI (apache2 MPM vs prefork or fastcgi). That’s PHP 101 tbh.

    About the WebPi, you can install SqlServerExpress or not… It is one of the tools you can install with the WebPi.

  5. Stuart Herbert says:
    April 30th, 2009 at 3:39 pm

    I had a look at the source tarball. I didn’t spot the additional libraries required to build the extensions? Did I miss them, or do they need to be downloaded from somewhere else?

  6. Shahar Evron says:
    April 30th, 2009 at 3:40 pm

    Hi

    (full disclosure: I am the product manager of Zend Server @ Zend)

    If xDebug still causes PHP to crash when loaded on Zend Server (and ZEM is not disabled), this is a bug – and not intentional, and we will look into it and hopefully solve it. The incompatibility is probably not because of how we compile PHP itself – it is more likely to be in one of the Zend extensions or ZEM itself and not in any patches we put into PHP (note that I am saying this from my experience – not because I have verified this…). We do know that NTS DLLs work well with Zend Server, despite the different compilers used.

    xDebug is a bit of an edge case because it loads as a zend_extension and probably collides with some of the things we do with our own proprietary extensions – but those problems are very likely solvable and we intend to solve them.

    In any case thanks for the feedback – we will definitely look into improving our compatibility with xDebug and with php.net binary builds of extensions.

  7. Stuart Herbert says:
    April 30th, 2009 at 3:48 pm

    Re: TS vs NTS … hasn’t Rasmus et al have clearly stated that the PHP Group doesn’t support TS, because even if the PHP code itself is fully thread-safe, the underlying libraries are not all thread safe? Don’t all the major Linux distros ship with non-TS PHP (and use Apache w/ mpm-prefork)?

    I just don’t get how you can say PHP 5.3 is the best version of PHP for Windows if it currently is missing the extensions for SQL Server. Whether you agree with me or not, we obviously can’t use the PHP 5.3 snapshots for your company’s competition if we’re being judged on how well we exploit the many excellent features the Windows platform has to offer :) If we want to use SQL Server, we’ll have to stick with the PHP 5.2.9-2 release for now … unless you’re going to push out new snapshots with the SQL Server support addressed?

  8. Pierre says:
    April 30th, 2009 at 3:48 pm

    Where you install PHP on linux you have to install various libraries (openssl, postgresql, png, etc.).

    It is the same for windows except that we provide them with PHP directly. They are either statically linked (built in) or as DLL (the library itself is kept as a file, a dll, like libeay.dll (openssl)).

    This page describes what is used with which PHP version:

    http://wiki.php.net/internals/windows/libs

  9. Stuart Herbert says:
    April 30th, 2009 at 3:56 pm

    Thanks.

    And, in full fairness to Zend, you’ve always been very clear that xdebug isn’t explicitly supported on Zend Server.

    As an aside, are you able to comment on Zend’s longer-term plans for Zend Debugger? I’m not clear on the advantages that Zend Debugger offers over xdebug, only the perceived disadvantages relating to cost and the need to use Zend Studio. Are there any articles available from Zend to cover the advantages?

  10. Stuart Herbert says:
    April 30th, 2009 at 4:11 pm

    Yes, but the difference is that these libraries are native to Linux; they have all the makefiles etc required to compile. If I downloaded the upstream tarballs of each of these libraries, could I build them using the supplied upstream makefiles?

    Can you recompile PHP for Windows without downloading the tarball for these libraries that you have on the wiki? If you can, then it’s no big deal … but if you can’t, then wouldn’t it be a good idea to tell users where to find these libraries? :)

    Why don’t you link to that very useful wiki page from the same page as the PHP for Windows sources are downloaded?

  11. Pierre says:
    April 30th, 2009 at 6:22 pm

    Many libraries are portable (png, jpeg, pgsql, etc.), other not (snmp, ldap). If we had to patch the upstream sources, we provide the patched source package as well. Libraries have to be built using the same runtime version than php itself, that’s why we provide them with php or as development packages for the PHP core or extension developers (see http://pecl2.php.net/downloads/php-windows-builds/), for each supported visual c++ version.

    Unlike linux, you can actually compile php 5.3 without any library but the Windows SDK, a 5min tutorial can be read here (http://blog.harddisk.is-a-geek.org/index.php/dev/php/php-on-windows/ English version in the bottom).

    In the wiki, when you click on a library name, you will get a page describing how to build this library yourself, where to fetch it, etc.

    It does not make a lot of sense to provide a link to this page as it is mainly for extension/core developers. However the version of each library will be provided with the PHP release notes.

  12. Stuart Herbert says:
    April 30th, 2009 at 10:00 pm

    As an open source project, don’t you think it would be in better keeping with the spirit of open source to make sure that your users have everything they need to be able to rebuild everything from source if they so choose? It’s very frustrating that this information isn’t easily found. If someone is visiting http://www.php.net to download the required sources, how would they find the useful pages and download sites you’ve kindly mentioned today?

  13. Pierre says:
    May 1st, 2009 at 9:08 am

    There will be links in all required places. But most of this stuff is for 5.3 which is not officially released yet.