{ php: (CG.newObjects.GateCGI)
  (string):Engine=\PHP\PHP.EXE "%s" %q
  (int)IsScriptEngine=1
  (int)Timeout=60
  (int)RequireAsynch=2
  (int)CheckThatFileExists=1
  (int)ShowErrOutputSample=0
} php;

This entry is in the ExtensionMap section of the alp.application file in your application (not the global/default alp.application located in the ALP binaries directory). The :Engine option is used in it (see the GateCGI configuration). This means that the referred PHP.EXE is in the subdirectory "PHP" of the current ALP site. In other words this configuration sample assumes the PHP processor binaries are located in the directory tree of your application's virtual site. This is very convenient if you want to be sure that your application will have its own copy of the PHP processor and will use it (no matter if other copies exist/are installed somewhere on the PC). Thus this is probably the most convenient configuration for wide redistribution. (The tests were made with PHP 4.x).

However the above is not enough! You need to configure PHP too. As a security precaution PHP 4.x included some additional requirements to the WEB servers and seems the only one that fits in the ALP environment is the configuration setting:

doc_root=<drive>:\<path to the ALP site>\

in the php.ini file.

Note that you should create this file from scratch. In fact if it contains only this setting it will be enough to start up. Better add additional settings one by one and see if everything is ok. As the default behavior of the CGI PHP for Windows includes the most of the widely needed features you will rarely need to adjust something more.

The above is a bit inconvenient if you intend autorun or something close to it as scenario. You can download a deployment sample from http://www.newobjects.com/product.asp?Category=57&Story=310 where the setup generates the php.ini file entry to point to the application install directory.

PHP documentation mentions some other opportunities to achieve the same result in more dynamic fashion. Unfortunately the tests show that they are not available or are buggy in the Windows CGI version. May be an appeal to the PHP community will have effect and they will be corrected. They are environment variable that plays the same role and PHP.EXE command line parameter. If they were functional it would be possible to run PHP without need to install it and generate php.ini file. Apparently this will allow pure autorun applications to be built.

Notes: Portability of the application depends also on the extended/external features used. Do not forget to evaluate them and see what changes/adjustments you need to do. For example a PHP application that uses MS Access database will be able to run much easily through the PHP's ODBC support (in fact this will not need any adjustments as long as no physical paths are encoded in the PHP files) than an application that uses MySQL which will need installation (thus it will require additional steps in the installation process and  is generally not suitable for autoruns).