Previous Next

Thread: PHP FastCGI x64 glitch

Last post 01-02-2008 8:24 AM by Amrlafi. 3 replies.

Average Rating Rate It (5)

RSS

Page 1 of 1 (4 items)

Sort Posts:

  • 10-13-2007, 12:03 AM

    PHP FastCGI x64 glitch

    I just installed the Go Live release of the Microsoft FastCGI Extension and am using it to run PHP 5.2.3 under IIS 6 on Windows 2003 Server Standard x64 Edition (whew! what a mouthful).

    I had previously run the same version of PHP as a [32-bit] ISAPI module under IIS. To accomplish this, I had to configure IIS 6 to run 32-bit application pools, which was not an issue. Once I installed the x64 version of the FastCGI extension, however, I decided to restrict my application pools once again to x64 only, just to see if this would work. Well, for the most part, it did.

    Here's the catch...

    I host multiple web sites in IIS, and each site requires a slightly different set of configuration parameters from the ones defined in the boilerplate php.ini file. PHP provides for this type of setup by allowing you to specify "Per-directory" values in the Windows registry. Normally, these values would be contained in the key: HKLM\Software\PHP. If running the 32-bit PHP ISAPI module in an x64 edition of Windows, as I was, then the key's location would be: HKLM\Software\Wow6432Node\PHP.

    After I installed the x64 version of the FastCGI extension (and turned off 32-bit application pools in IIS), I moved my Per-directory values from their previous location in HKLM\Software\Wow6432Node\PHP to HKLM\Software\PHP (i.e., where other x64-native apps look for their settings). But PHP didn't like that. It couldn't see the custom settings. Only after I dropped the Per-directory values back into the Wow6432Node container key did PHP register them again. And that's where I left it.

    Now, I recognize that I may be the only living soul on Earth trying to run PHP in this way, so I won't be surprised in the slightest if I never receive a single response to this thread :) which is just fine by me because everything is basically working. Nevertheless, I just wanted to put this out there because the behavior I described is technically not consistent with that of other x64 apps.

    Please note that the fcgiext.ini file I am using to configure the FastCGI handler to work with PHP resides in my C:\WINDOWS\system32\inetsrv directory - NOT the C:\WINDOWS\SysWOW64\inetsrv directory. I mention this only to refute any suggestion that IIS may still be configured to run 32-bit application pools. If that were the case, then my FastCGI handler would not be able to process PHP files. At least that is my understanding. I could be wrong.

  • 10-13-2007, 6:44 PM In reply to

    Re: PHP FastCGI x64 glitch

    If the PHP version you are using is 32bit, then surely it will only load the settings from the Wow6432Node registry key; FastCGI doesn't access the registry on PHP's behalf. Baring in mind that FastCGI will be running the php-cgi.exe independently. FastCGI will not run PHP as if it were 64bit - the ISAPI extension is 64bit, but the exe process it launches isn't.

    What I am trying to say is that since php-cgi.exe is 32bit, it is meant to load its registry setting from the Wow6432Node registry key - regardless of the fact it is launched by a 64bit library.

  • 10-13-2007, 10:35 PM In reply to

    Re: PHP FastCGI x64 glitch

    Thanks, Red. That makes sense. You're right. I was assuming that just because the FastCGI handler is x64 that the PHP process would be running as x64 too. Now, if only the PHP folks would make an x64 binary available for Windows...
  • 01-02-2008, 8:24 AM In reply to

    • Amrlafi
    • Not Ranked
    • Joined on 03-22-2006, 8:22 PM
    • Posts 7

    Re: PHP FastCGI x64 glitch

    complete tutorial found here : http://blahblah.webunusual.com/index.php/2008/01/01/x64-fashioned-speed-iis-on-x64-php-and-fastcgi/

Page 1 of 1 (4 items)
Page view counter