18 years ago by Hector Santos — view source — reply

unread

I'm relatively new to PHP development. I hope this is the appropriate
area for this question since I was thinking maybe I could use the
opportunity to get involved with the internals by making a patch
regarding how DLLs are loaded.

Specifically, the extension_dir="path" directive which only allows a
single path for finding dlls.

I'm nearly done with a new Windows-based PHP extension (php_wildcat.dll)
and one of the issues was DLL dependencies.

The PHP extension offers direct SDK/API support for our application
server and all our DLLs are in a specific server folder.

The installation of the Extension is preferred to be placed in our
server folder so ideally, something like so would be ideal:

extension_dir="./ext;c:/wildcat"

But of course, this isn't supported and it will not work, in fact, it
fails the loading of other PHP extensions.

The official method of placing extensions in the PHP "./Ext" requires
that we alter our long (12 years) recommended policy of a) not copying
our DLLS to other folders (for auto update/version control reasons) or
not requiring of adding the server folder in the Windows PATH.

I came up with an somewhat "kludgy" solution but I somewhat feel this
has to be a common PHP extension issues with extension authors, thus
maybe I must of a missed something where I don't have to do any of this.

The solution I came up with is to use DELAY LOADING where the extension
is compiled and linked with delayed loading of implicit dlls.

For example: the extension is compiled/linked using pragma directives
like so:

#define USE_DELAY_LOADING
...
#ifdef USE_DELAY_LOADING

pragma comment(lib, "delayimp.lib")

pragma comment(linker, "/delayload:wcsrv2.dll")

pragma comment(linker, "/delayload:door32.dll")

#endif

delayimp.lib is part of the VC6.0 C/C++ runtime library and it handles
the delayed implicit loading of dlls. The DLLs above are part of our
RPC server API interface.

Now, our RPC server folder is recorded in the registry so using the dll
entry point DllMain(), the registry location is read and this is used
to add to the process environment path. So I have this at the end of my
PHP_WILDCAT.CPP code:

#ifdef USE_DELAY_LOADING

#define GETENV GetEnvironmentVariable
#define SETENV SetEnvironmentVariable

BOOL GetRegistry(const TCHAR *key,
const TCHAR *name,
DWORD type,
void *data,
DWORD datasize)
{
BOOL ok = FALSE;
HKEY k;
if (RegOpenKeyEx(HKEY_LOCAL_MACHINE,
key, 0, KEY_READ, &k) == ERROR_SUCCESS) {
DWORD t;
if (RegQueryValueEx(k, (TCHAR *)name, NULL,
&t, (BYTE *)data, &datasize) == ERROR_SUCCESS) {
ok = t == type;
}
RegCloseKey(k);
}
return ok;
}

BOOL GetRegistryString(const TCHAR *name,
TCHAR *data,
DWORD datasize,
const TCHAR *key = "SOFTWARE\SSI\Wildcat")
{
return GetRegistry(key, name, REG_SZ, data, datasize);
}

BOOL PrepareWildcatPath()
{
char srvPath[MAX_PATH]={0};
if (GetRegistryString("ServerDirectory",srvPath,MAX_PATH-1)) {
char ePath[1024*4] = {0};
strcpy(ePath,srvPath);
strcat(ePath,";");
DWORD dw = strlen(ePath);
return (GETENV("PATH",&ePath[dw],sizeof(ePath)-dw) &&
SETENV("PATH",ePath));
}
return FALSE;
}

////////////////////////////////////////////////////////////////////
// DllMain
////////////////////////////////////////////////////////////////////

BOOL APIENTRY DllMain(HINSTANCE hinstDLL, DWORD dwReason, LPVOID)
{
switch (dwReason) {
case DLL_PROCESS_ATTACH:
PrepareWildcatPath();
break;
}
return TRUE;
}

#endif

This works really well. We can install PHP*.DLLs in the PHP "./EXT"
folder and when the extension is loaded by PHP, all of its dependencies
are now resolved during the temporary PHP runtime residence time.

I could of gone deeper (and more elegant without having to alter the
process PATH) by using the delayimp.lib helper hooks available which
will issue a callback for the delayed implicit dlls. But seems overly
complexed and before I begin on that I wanted so see if a) there was
already a method to address this and/or b) I could patch PHP to offer an
multi-path extension_dir method.

Ideally we would love to keep our specific PHP*.DLL files in our server
folder and have extension_dir defined to look at multiple paths.

Comments?

TIA

--
Hector Santos

18 years ago by Hector Santos — view source — reply

unread

I probably over did my past post.

Let me simply ask, do you think there is technical merit (worth while)
to create a patch which offers multi-directory DLL loading support for
the PHP.INI extension_dir= option?

Example:

 extension_dir="./ext;c:/myserver/bin;c:/otherext"

Reasons:

Currently, it only allows for a single folder and this present some
support issues.

But offering multi-directory support, PHP can:

Reduce extension DLL (non-PHP related) dependency issues,
Better support for PHP integration with Application Servers, and
Better support for security isolation, sand-boxing applications.

Do you see a technical reason why this is not a good idea? Would it be
transparent enough that it would not cause issues with current extensions?

TIA

--
Hector

Hector Santos wrote:

I'm relatively new to PHP development. I hope this is the appropriate
area for this question since I was thinking maybe I could use the
opportunity to get involved with the internals by making a patch
regarding how DLLs are loaded.

Specifically, the extension_dir="path" directive which only allows a
single path for finding dlls.

I'm nearly done with a new Windows-based PHP extension (php_wildcat.dll)
and one of the issues was DLL dependencies.

The PHP extension offers direct SDK/API support for our application
server and all our DLLs are in a specific server folder.

The installation of the Extension is preferred to be placed in our
server folder so ideally, something like so would be ideal:

extension_dir="./ext;c:/wildcat"

But of course, this isn't supported and it will not work, in fact, it
fails the loading of other PHP extensions.

The official method of placing extensions in the PHP "./Ext" requires
that we alter our long (12 years) recommended policy of a) not copying
our DLLS to other folders (for auto update/version control reasons) or
not requiring of adding the server folder in the Windows PATH.

I came up with an somewhat "kludgy" solution but I somewhat feel this
has to be a common PHP extension issues with extension authors, thus
maybe I must of a missed something where I don't have to do any of this.

The solution I came up with is to use DELAY LOADING where the extension
is compiled and linked with delayed loading of implicit dlls.

For example: the extension is compiled/linked using pragma directives
like so:

#define USE_DELAY_LOADING
...
#ifdef USE_DELAY_LOADING

pragma comment(lib, "delayimp.lib")

pragma comment(linker, "/delayload:wcsrv2.dll")

pragma comment(linker, "/delayload:door32.dll")

#endif

delayimp.lib is part of the VC6.0 C/C++ runtime library and it handles
the delayed implicit loading of dlls. The DLLs above are part of our
RPC server API interface.

Now, our RPC server folder is recorded in the registry so using the dll
entry point DllMain(), the registry location is read and this is used
to add to the process environment path. So I have this at the end of my
PHP_WILDCAT.CPP code:

#ifdef USE_DELAY_LOADING

#define GETENV GetEnvironmentVariable
#define SETENV SetEnvironmentVariable

BOOL GetRegistry(const TCHAR *key,
const TCHAR *name,
DWORD type,
void *data,
DWORD datasize)
{
BOOL ok = FALSE;
HKEY k;
if (RegOpenKeyEx(HKEY_LOCAL_MACHINE,
key, 0, KEY_READ, &k) == ERROR_SUCCESS) {
DWORD t;
if (RegQueryValueEx(k, (TCHAR *)name, NULL,
&t, (BYTE *)data, &datasize) == ERROR_SUCCESS) {
ok = t == type;
}
RegCloseKey(k);
}
return ok;
}

BOOL GetRegistryString(const TCHAR *name,
TCHAR *data,
DWORD datasize,
const TCHAR *key = "SOFTWARE\SSI\Wildcat")
{
return GetRegistry(key, name, REG_SZ, data, datasize);
}

BOOL PrepareWildcatPath()
{
char srvPath[MAX_PATH]={0};
if (GetRegistryString("ServerDirectory",srvPath,MAX_PATH-1)) {
char ePath[1024*4] = {0};
strcpy(ePath,srvPath);
strcat(ePath,";");
DWORD dw = strlen(ePath);
return (GETENV("PATH",&ePath[dw],sizeof(ePath)-dw) &&
SETENV("PATH",ePath));
}
return FALSE;
}

////////////////////////////////////////////////////////////////////
// DllMain
////////////////////////////////////////////////////////////////////

BOOL APIENTRY DllMain(HINSTANCE hinstDLL, DWORD dwReason, LPVOID)
{
switch (dwReason) {
case DLL_PROCESS_ATTACH:
PrepareWildcatPath();
break;
}
return TRUE;
}

#endif

This works really well. We can install PHP*.DLLs in the PHP "./EXT"
folder and when the extension is loaded by PHP, all of its dependencies
are now resolved during the temporary PHP runtime residence time.

I could of gone deeper (and more elegant without having to alter the
process PATH) by using the delayimp.lib helper hooks available which
will issue a callback for the delayed implicit dlls. But seems overly
complexed and before I begin on that I wanted so see if a) there was
already a method to address this and/or b) I could patch PHP to offer an
multi-path extension_dir method.

Ideally we would love to keep our specific PHP*.DLL files in our server
folder and have extension_dir defined to look at multiple paths.

Comments?

TIA

18 years ago by Lars Strojny — view source — reply

unread

Hi Hector,

Am Freitag, den 09.05.2008, 20:39 -0400 schrieb Hector Santos:
[...]

Do you see a technical reason why this is not a good idea? Would it be
transparent enough that it would not cause issues with current
extensions?

I would really love to see this. A use case I have in mind is extension
development. If one has a continuous integration solution, the in-house
developed module can be easily auto-deployed and live with system-wide
default extensions.

cu, Lars

18 years ago by Hector Santos — view source — reply

unread

Lars Strojny wrote:

Hi Hector,

Do you see a technical reason why this is not a good idea? Would it be
transparent enough that it would not cause issues with current
extensions?

I would really love to see this. A use case I have in mind is extension
development. If one has a continuous integration solution, the in-house
developed module can be easily auto-deployed and live with system-wide
default extensions.

cu, Lars

Great! Got two positives on this, so I'll work on this. Now, if I can
only figure out the Windows Build. What a mess!! :-)

--
Hector Santos

18 years ago by Elizabeth M Smith — view source — reply

unread

Hector Santos wrote:

Lars Strojny wrote:

Hi Hector,

Do you see a technical reason why this is not a good idea? Would it be
transparent enough that it would not cause issues with current
extensions?

I would really love to see this. A use case I have in mind is extension
development. If one has a continuous integration solution, the in-house
developed module can be easily auto-deployed and live with system-wide
default extensions.

cu, Lars

Great! Got two positives on this, so I'll work on this. Now, if I can
only figure out the Windows Build. What a mess!! :-)

Actually building for windows is easy - it's the dependencies that are
hard ;) check out the wiki for build help

Thanks
Elizabeth

18 years ago by Hector Santos — view source — reply

unread

(Elizabeth, this is a public follow up to the previous message (shown
below))

Of course, I must not be doing something right, but I was finally able
to compile and successful link by:

Adding pcrec_newline.c to the project PCRE source group #3
Adding a #include "config.h" to pcre_internal.h
to resolve the LINK_SIZE define
Adding tokenizer_data.c to the project XML source group #4
Changing the link lib "libxml2_a.lib" to libxml2_a_dll.lib which
probably means libxml2.dll will be used with php5ts.dll
And to resolve the _ftol2 link libxml2 error, add the following chunk
to ext\dom\xpath.c:

// HLS, only for MSDEV 6.0
#if (_MSC_VER == 1200)
extern long _ftol( double ); //defined by VC6 C libs
extern long _ftol2( double dblSource ) { return _ftol(dblSource ); }
#endif

I also had to alter the INCLUDE paths for some of the projects where
it was using a ....\FOLDER entry to ..\FOLDER. I often find this to
be a common issue with DSP projects under the vs 6.0 IDE because of the
stock File OPEN/SAVE dialog not restoring the original directory. When
include references are adding, the programmer needs to make sure the
proper project ROOT folder is set when the project is saved so that it
can create and establish the proper persistent paths. IOW, when you add
a file to a project source folder and you had to switch directories, the
IDE is implementing OPEN/SAVE dialog to remember this location and this
can alter how include file are found when using relatives INCLUDE paths.

Anyway, not sure if any of the above is note worthy but if I am going to
be doing more PHP work, maybe I can contribute by providing a
"no-hassle" windows build.

--
Hector Santos

Elizabeth M Smith wrote:

Great! Got two positives on this, so I'll work on this. Now, if I can
only figure out the Windows Build. What a mess!! :-)

Actually building for windows is easy - it's the dependencies that are
hard ;) check out the wiki for build help

Yes, I had to go get else where libxml, iconv, and soemthing else (I
think it was bindlib_win32). I wasn't quite sure if the instructions
assumed cygwin makefile prepareness or the VS *.DSP/DSW files were
independent of this. Various projects had conflicting include and lib
paths.

But after working all that out, I am at this final linkage error where I
am don't know what else I can I can do beyond the changes already done
to the project build, and searching/collecting all the other dependencies.

linking...
Creating library ..\Release_TS/php5ts.lib and object
..\Release_TS/php5ts.exp
LINK : warning LNK4049: locally defined symbol "_php_dom_create_object"
imported
pcre_compile.obj : error LNK2001: unresolved external symbol
__pcre_is_newline
pcre_exec.obj : error LNK2001: unresolved external symbol __pcre_is_newline
pcre_exec.obj : error LNK2001: unresolved external symbol __pcre_was_newline
tokenizer.obj : error LNK2001: unresolved external symbol
_tokenizer_register_constants
tokenizer.obj : error LNK2001: unresolved external symbol
_get_token_type_name
spl_iterators.obj : error LNK2001: unresolved external symbol _php_pcre_exec
php_pcre.obj : error LNK2001: unresolved external symbol _php_pcre_exec
php_pcre.obj : error LNK2001: unresolved external symbol _php_pcre_version
php_pcre.obj : error LNK2001: unresolved external symbol _php_pcre_study
php_pcre.obj : error LNK2001: unresolved external symbol _php_pcre_compile
php_pcre.obj : error LNK2001: unresolved external symbol
_php_pcre_maketables
php_pcre.obj : error LNK2001: unresolved external symbol _php_pcre_info
php_pcre.obj : error LNK2001: unresolved external symbol _php_pcre_free
php_pcre.obj : error LNK2001: unresolved external symbol
_php_pcre_get_substring_list
php_pcre.obj : error LNK2001: unresolved external symbol _php_pcre_fullinfo
libxml.obj : error LNK2001: unresolved external symbol _xmlDllMain
libxml2_a.lib(xpath.obj) : error LNK2001: unresolved external symbol __ftol2
libxml2_a.lib(xmlschemastypes.obj) : error LNK2001: unresolved external
symbol __ftol2
libxml2_a.lib(xpointer.obj) : error LNK2001: unresolved external symbol
__ftol2
..\Release_TS\php5ts.dll : fatal error LNK1120: 15 unresolved externals
Error executing link.exe.

php5ts.dll - 20 error(s), 1 warning(s)

pcrec_newline.c is not included int the project PREC source listing.
Adding it gives me a compiler error about LINK_SIZE not being set.

Adding this file to the project, adding #include "config.h" to it, gets
past this link resolution, but now it seems that I am going beyond what
was expected in the project build setup/provided for a successful build

I must not be doing something right.

--
Hector Santos

18 years ago by Hector Santos — view source — reply

unread

Folks,

Well, I got this extension_dir logic work completed based on my PHP
5.2.5 CVS copy of PHP. The feature allows your to set the extension_dir
for multiple paths. This is what I had so far in PHP.INI-DIST/RECOMMENDED.

;---------------------------------------------------------------------
; Directory locations (paths) in which the loadable extensions (modules)
; reside. To add multiple paths, separate paths using ":" (UNIX) for
; ";" (Windows) character. Examples:
;
; UNIX: extension_dir = "/path1:/path2"
; Windows: extension_dir = "\path1;\path2"
;
; Note: Explicit FQFN (Fully Qualified File Name) extension loading
;
: Extensions with explicit FQFN can be used to skip the
; extension search in the extension_dir path(s).
; i.e. extension = c:\serverapp\bin\php_wildcat.dll
;
;---------------------------------------------------------------------
extension_dir = "./ext"

The source code change was done on the ext\standard\dl.c file.

I was about to create the patches for the current PHP52, PHP53 and PHP6
snapshots when I noticed there was a change in PHP53 that was done that
allows for explicit FQFN extension= loading.

<side beef> I don't know if this was a result of someone lurking the list and decided to go ahead and do this after reading the related recent thread for the multi-path extension_dir proposal, which is fine, but if they did go about this after seeing the thread, a simple courtesy to post a note of their intention would of been appreciated. Things like this waste people's time. </side beef>

In any case, to see if there was any other stuff related to this, I
checked the bug database and found two related past feature request
related to this:

Bug # 22587 (Mar 2003) extension_path feature
Bug # 41310 (May 2007) make extension_dir optional and use absolute
paths in "extension = ..."

#22587 is pretty much what I am satisfying.

#41310 was interesting so I wanted to see if this was possible now.

Using my 5.2.5 release installation (which would be the same logic as
5.2.6), I tested the following PHP.INI option:

extension_dir="./ext"
extension_dir="../../php_wildcat.dll"

and of course, the source code logic show this as well.

But the PHP53 FQFN change now breaks this.

The PHP53 change allow for extension= module loading if the filename has
a directory separator, but not supported for temporary loading via a PHP
script DL() function.

extension=c:\path\php_extension.dll   <== works under PHP53 only
dl("c:\path\php_extension.dll")       <== never supported.

I personally think PHP53 change is more correct, but that depends on
your point of view. Should the filename loading be off the ROOT path
for the PROCESS or off the extension_dir path was what the 5.2 logic.

It also depends on what the file name is:

FQFN means a complete path (not relative)

There could be a change where if the file name has relative folder
reference (../) then it could use the extension_dir as the root as it
was supported in PHP52. If its FQFN, then its a explicit load.

In all, this is what I think:

PHP53 breaks PHP52 logic. Although "more correct", its breaks
working code so we need to do something there.
Consider using a new extension_path to override extension_dir
thereby keeping extension_dir PHP52 intact and only apply the
multiple path search to the new extension_path, if defined.
Continue with the current patch I am doing with extension_dir
and if a extension= has a relative path, apply this only to
the FIRST path defined in extension_dir. For example:

extension_dir="./ext;c:/wildcat;c:/other"

extension=php_zip.dll
extension=php_wildcat.dll
extension=../php_extension2.dll
extension=c:\somewhere\php_extension3.dll

php_zip.dll has no folder information, so its found its stock ./ext folder.

php_wildcat.dll has no folder information, its not in ./ext so the
additional paths are checked and its found in c:/wildcat

php_extension2.dll has a relative location, so to continue with PHP52
expectations, it will only use the first path "./ext" as its root.

php_extension3.dll has a FQFN so its explicitly loaded with the FQFN.

Comment? What path do you think its the best way?

Again, although PHP53 change logic seems to be more correct, IMO, that
is would be so if PHP was new and there was no working code out there.
But as it was done now, it does break the PHP52 logic.

--
Hector Santos

18 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

Let me simply ask, do you think there is technical merit (worth while)
to create a patch which offers multi-directory DLL loading support for
the PHP.INI extension_dir= option?

extension is an one-time configuration directive. Since it allows full
path now, how hard would it be to get it right with full path?
Multiple paths may contain some dangerous pitfalls - like, what happen
if extension is in multiple paths, and in some it's not compatible
(wrong version/debug/ts)? What if you have some old version lying around
in fifth path, and you had new version in first path, but somehow
permissions got mangled and it's not readable, so wrong version is
loaded? Etc., etc. - it seems to have potential for many unpleasant
moments.

Reduce extension DLL (non-PHP related) dependency issues,

How? I'd say, if you have extension A using foo.dll, and extension B
using foo.dll, and they live in different directories, don't you now
have to maintain two copies of foo.dll instead of one?

Better support for PHP integration with Application Servers, and

Here I'd like to hear more - how it helps PHP and Application Servers?

Better support for security isolation, sand-boxing applications

I'm not sure how giving multiple places to put security-sensitive stuff
(extension has access to everything) improves sandboxing, could you explain?

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Hector Santos — view source — reply

unread

Stanislav Malyshev wrote:

Hi!

Let me simply ask, do you think there is technical merit (worth while)
to create a patch which offers multi-directory DLL loading support for
the PHP.INI extension_dir= option?

extension is an one-time configuration directive. Since it allows full
path now, how hard would it be to get it right with full path?

In PHP52, it allows only relative paths:

 extension_dir="./ext"
 extension=../special/php_specialext.dll

Attempting to clear extension_dir does not work in an attempt to use a
FQFN (fully qualified file name).

Example, for FQFN extension

 extension=c:/php/special/php_specialext.dll

None of the following will works:

 extension_dir=""
 extension_dir=
 ;extension_dir=

PHP53 was updated to override the extension_dir= location IFF there is a
directory separator in the extension= file name.

Multiple paths may contain some dangerous pitfalls - like, what happen
if extension is in multiple paths, and in some it's not compatible
(wrong version/debug/ts)? What if you have some old version lying around
in fifth path, and you had new version in first path, but somehow
permissions got mangled and it's not readable, so wrong version is
loaded? Etc., etc. - it seems to have potential for many unpleasant
moments.

Possible. But this is partly the reason why I think it applies, as I
will note below.

Reduce extension DLL (non-PHP related) dependency issues,

How? I'd say, if you have extension A using foo.dll, and extension B
using foo.dll, and they live in different directories, don't you now
have to maintain two copies of foo.dll instead of one?

But if you are single sourcing foo.dll, why would you want to have
multiple copies floating around? Thats partially the point there, more
importantly non-php related foo.dll is in one location outside of PHP.

Consider foo.dll to be a "system.dll" where only 1 version is expected,
"DLL From Hell" issues.

Better support for PHP integration with Application Servers, and

Here I'd like to hear more - how it helps PHP and Application Servers?

I'm a bit surprise you have to ask. :-)

Better support for security isolation, sand-boxing applications

I'm not sure how giving multiple places to put security-sensitive stuff
(extension has access to everything) improves sandboxing, could you
explain?

Today, if an application server wish to implement PHP, it will need to
add its PHP extensions into the single extension_dir location.

For an application server that traditionally does not desire for its
DLLs to be floating outside its controlled environment, PHP does not
play well here.

Our package is a long time integrated RPC client/server framework and,
we keep everything under one secured folder. No need for PATHS. No need
to copy dlls. The primary reason is to control versions issues and
customer auto updates into one known location - isolation.

With increase customer usage of PHP and 3rd party developer demand for
direct PHP support, for which we currently only provide generic
CGI/script mapping support, we began to write an extension
to expose the 150+ server API to the PHP language and added PHP to our
SDK suite of language support; C/C++, Java, VB, VFP, Delphi, .NET and
now PHP.

Immediately we found isolation issues in regard

- PHP library/classes,
- DLL dependencies issues.

The include_path resolves the script issues, but we don't have the same
flexibility with DLLs.

Our server is a RPC client/server system and each RPC client
requires our DLL interface files, including the new PHP extension we
wrote (a total of 3 of them) which are basically wrappers to our RPC
client dll API interface.

The unreleased package includes many PHP examples to illustrate how PHP
can work with our system and we found we have to either:

 a) copy our DLLS into PHP "extension_dir" folders,

 b) copy them to a windows PATHed folder,

 c) add a DELAY_LOADING concept to the PHP extensions which
    allow the extension's dll_main() process_attach logic
    to prepare finding its server dependencies.

The latter is how we currently have it working now, but not something we
really wanted to do because of the method it uses.

Since the above extension= full path idea does not work, we would left
(pressured) to look at the possibility of altering PHP itself. Hence
why I am here.

We also expect to add direct embedded/sapi support and this will 100%
require PHP to work around our centralized server focus, not an embedded
language as the central focus.

I think the same will hold true in the application server growth market
where PHP needs to fit into better, and not the other way around.

Thus far, I can provide a quick summary review of two items where I
think PHP can be improved:

multi-path extension_dir support
PER application multi-ini include support. Scattered material seem
to suggest this is possible, I have not seen how.

Think of an application server being "PHP Ready" with a PHP
configuration file that is already available, always distributed.

If a customer wants to install PHP, all it needs to do is add a line
such as:

appserver_ini="c:\wcat\wcphp.ini"

or have a new INI folder concept:

appserver_ini_dir="./ini"

where applications that place their specific INI and PHP will reads
these INI files.

The ini will have the overriding PHP requirements, for example, this is
the WCPHP.INI we add to the PHP.INI during installation for an existing
PHP installation. You can imagine the complexity in augmenting an
integration with possibly existing other system setups, i.e, adding to
the include_path= rather then replacing it, etc.

;----------------------------------------------------------
; wcPHP PHP.INI configuration file.
; minimum setup. see complete php-recommended.ini for
; more options
;----------------------------------------------------------

[PHP]

doc_root =
cgi.force_redirect = 0
cgi.fix_pathinfo=1

include_path =".;c:\wcat\php\code"
extension_dir =".\ext;c:\wcat"

extension=php_pdo.dll
extension=php_pdo_sqlite.dll

;----------------------------------------------------------
; PHP Wildcat! Extension
;----------------------------------------------------------

[wildcat]

allow_call_time_pass_reference = On

extension=php_wildcat.dll
extension=php_wscgate.dll
extension=php_wcdoor32.dll

; Wildcat.Server defined the server computer name to connect to
; Leave it blank to connect to the current server.
; Wildcat.AutoConnect flag allows to auto connnection and
; reestablishing the current user connect.

wildcat.server = ""
wildcat.autoconnect = 0

;----------------------------------------------------------
; wcShareNet Configuration
;----------------------------------------------------------

[wcsharenet]

wcsharenet.pdo.drv = "sqlite"
wcsharenet.pdo.dbf ="c:/wcat/wcShareNet/wcShareNet.db"
wcsharenet.pdo.dsn = ""
wcsharenet.pdo.uid = ""
wcsharenet.pdo.pwd = ""

--
Hector Santos, CTO
Santronics Software, Inc.

18 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

In PHP52, it allows only relative paths:

Right, but 5.2 is stable version so I don't see new features going
there. Thus I think it's better to discuss 5.3 for new stuff, unless
it's something so critical that it must be in 5.2.

But if you are single sourcing foo.dll, why would you want to have
multiple copies floating around? Thats partially the point there, more
importantly non-php related foo.dll is in one location outside of PHP.

I don't need multiple copies. But I may want to keep it in the same
directory the extension is - otherwise I'd have to add the directory to
windows path, which add overhead to install. By keeping all the stuff in
the same directory, it'd work out of the box.

Today, if an application server wish to implement PHP, it will need to
add its PHP extensions into the single extension_dir location.

Either that or use full paths in php.ini, depending on how the server is
structured.

For an application server that traditionally does not desire for its
DLLs to be floating outside its controlled environment, PHP does not
play well here.

Why? Just put all the stuff into that extension directory, if you talk
about Windows. On Unix, .so resolution rules won't help here, but having
extension path is not going to change anything.

The include_path resolves the script issues, but we don't have the same
flexibility with DLLs.

I'm not sure what do you mean here. If you mean that PHP extensions use
external DLLs, then you have two cases:

DLL is used only by PHP extension, nothing else uses it. Resolution:
put it in the same directory PHP extensions are.
DLL is used by other stuff (external programs, etc.), not only PHP.
Resolution: put it into separate library directory and add the directory
in system PATH.

In both cases, I don't see how path for extensions is helping you,
unless all your application lives in the same directory and for some
reason it's not possible to either add it to the path or use full pathes
in php.ini extension= directives (but is possible in extension_dir
directive).

a) copy our DLLS into PHP "extension_dir" folders,
b) copy them to a windows PATHed folder,

If it's external use DLLs, b) is the right way to go. It is regardless
of the extension - if multiple parts of the application use same DLL,
and they may reside in different directories, PATH is only way I can
think of that makes it work.

PER application multi-ini include support. Scattered material seem
to suggest this is possible, I have not seen how.

You can do it in 5.3 with "user ini files", but it's not documented yet,
unfortunately. Hopefully, it will be soon.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Hector Santos — view source — reply

unread

Stanislav Malyshev wrote:

a) copy our DLLS into PHP "extension_dir" folders,
b) copy them to a windows PATHed folder,
If it's external use DLLs, b) is the right way to go. It is regardless
of the extension - if multiple parts of the application use same DLL,
and they may reside in different directories, PATH is only way I can
think of that makes it work.

Its the only way to augment PHP.

I seriously doubt we are not going to change a 12 year design,
operations and support policy of not requiring customers the need to use
a PATH statement just to implement 3rd party solutions. It just not
going to happen. PHP is not the central piece of the server framework.

If the current change to PHP53 is kept, which breaks PHP52, then we only
have the choice of using a FQFN, which is fine, but that further means
different versions of the PHP.INI setup.

So if you think the multi-path extension_dir= change isn't going to be
accepted to PHP53, I might as well stop right here.

PS: I must say that I find it incredible that "breaking code" seems to
be the modus operandi around here. I think the team should be more
considerate of such issues and especially high-end corporate
implementation needs if it wishes to be more friendly and cooperative as
PHP moves on.

--
Hector Santos, CTO
Santronics Software, Inc.

18 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

If the current change to PHP53 is kept, which breaks PHP52, then we only

Here I must have missed something - which use case worked in 5.2 and not
in 5.3? If we can make it work with 5.3 - we definitely should do it.

So if you think the multi-path extension_dir= change isn't going to be
accepted to PHP53, I might as well stop right here.

I don't know - it depends how broad is the need for it and how other
developers perceive it.

PS: I must say that I find it incredible that "breaking code" seems to
be the modus operandi around here. I think the team should be more

It is not. Of course, nobody here is omniscient, so it may happen on
occasion that we do changes that may break some setups. Then the person
whose code is broken writes to the list or submits a bug and complains -
so&so worked before and doesn't work now. Then we see if the breakage
was intentional (which happens sometimes - PHP is evolving and things
that looked like good idea 5 years ago may not look so good now) or by
mistake, and in the latter case we fix it. However nobody here does
changes just for the heck of it.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by sean finney — view source — reply

unread

hiya,

sorry to jump in a little late here,

On Tuesday 13 May 2008 09:03:08 pm Stanislav Malyshev wrote:

So if you think the multi-path extension_dir= change isn't going to be
accepted to PHP53, I might as well stop right here.

I don't know - it depends how broad is the need for it and how other
developers perceive it.

just to throw in my 0.02 $LC_MONETARY, it would be really useful to have
something like this in debian and other php-packaging distributions out
there.

consider the scenario where a user installs via the package management system
the php core plus extensions a, b, and c. they later want to install
extension d (which is not packaged) via pecl, and update/override extension
c.

currently what happens is pecl (there's a similar situation with pear btw)
installs to the same location as the packaged files, creating a rather
schizophrenic environment where you can't be sure what came from a package
and what was locally installed. and further, the next time extension c's
package is upgraded, the local changes will be lost.

now if there were a multi-extension-dir functionality available, we could do
something like saying "first check /usr/local/blah, and if that fails,
check /usr/blah", where the latter is for the debian stuff. then pecl could
be set to default to the /usr/local directory, eliminating the problem. fwiw
something quite similar is done by perl--i believe it provides 3 directories
actually: a "perl" directory, a "vendor" directory, and a "site" directory,
but it's the same concept.

anyway, hope to see something like this down the line!

sean

18 years ago by Hector Santos — view source — reply

unread

sean finney wrote:

On Tuesday 13 May 2008 09:03:08 pm Stanislav Malyshev wrote:

I don't know - it depends how broad is the need for it and how other
developers perceive it.

just to throw in my 0.02 $LC_MONETARY, it would be really useful to have
something like this in debian and other php-packaging distributions out
there.

consider the scenario where a user installs via the package management system
the php core plus extensions a, b, and c. they later want to install
extension d (which is not packaged) via pecl, and update/override extension
c.

....

anyway, hope to see something like this down the line!

Thanks for your input Sean.

I have the change to ext\standard\dl.c working very nicely for PHP 5.2.
I spent more time finally getting the building of PHP5TS.DLL under
windows with the goal of reproducing an official release image (same
exports, imports, built-in extensions, ect) so it would be a plug and
play feature for anyone using PHP 5.2. But I guess this will only by
provided as a patch for PHP 5.2 since as I understand it, there would be
no more releases under PHP 5.2 (unless a critical/security bug was
found).

I am now working on getting the new PHP 5.3 building process setup with
its new pecl2 libraries, etc so once thats done, I'll patch dl.c for PHP
5.3.

BTW, the technical outline semantics for this is:

Secure dynamically modules (loaded via script)
against filenames with paths.
Allow explicit loading of persistent FQFN modules
(but no relative path, no ".." in filename) or when
the extension_dir is empty.

Note: The problem here I don't see how you can create an
empty extension_dir via the PHP.INI. PHP seems to
default implicitly to "C:\PHP5" string (literally) in
the official builds. A blank, extension_dir="", does
not work.

If blank, it should do a WIN32 API call to
```
GetModuleFileName(NULL,szPhpFileName, NULL)
```
to get file location of the PHP EXE process, rather then use
hard coded "C:\PHP5".
Finally, parse the multiple paths, if any, attempt to
load the parsed_path + filename.

The logic keeps with PHP 5.2 and the current PHP 5.3 change that allows
for an explicit load if the filename contains slashes. However, my
change does not allow it if there are relative parts ("..") in the file
name. For (low) security reasons, relative paths should only be off an
explicitly extension_dir="non_blank" definition as prepared by the local
operator so there are no security surprises.

If fact, I could see a new option:

extension_allow_relative_loads = No   <-- new default behavior

But it might be an overkill to add this.

--
Hector Santos, CTO
Santronics Software, Inc.

Extention_Dir

pragma comment(lib, "delayimp.lib")

pragma comment(linker, "/delayload:wcsrv2.dll")

pragma comment(linker, "/delayload:door32.dll")

pragma comment(lib, "delayimp.lib")

pragma comment(linker, "/delayload:wcsrv2.dll")

pragma comment(linker, "/delayload:door32.dll")

I'm not sure how giving multiple places to put security-sensitive stuff (extension has access to everything) improves sandboxing, could you explain?

You can do it in 5.3 with "user ini files", but it's not documented yet, unfortunately. Hopefully, it will be soon.

I'm not sure how giving multiple places to put security-sensitive stuff
(extension has access to everything) improves sandboxing, could you explain?

You can do it in 5.3 with "user ini files", but it's not documented yet,
unfortunately. Hopefully, it will be soon.