Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37569
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain isdg.net designates 208.247.131.9 as permitted sender)
Message-ID: <4824EEAA.3080901@isdg.net>
Date: Fri, 09 May 2008 20:39:06 -0400
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To:  internals@lists.php.net
References: <4824219D.3070806@isdg.net>
In-Reply-To: <4824219D.3070806@isdg.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Extension_Dir: Proposal to offer multi-directory DLL loading
From: hsantos@isdg.net (Hector Santos)

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:

   1) Reduce extension DLL (non-PHP related) dependency issues,
   2) Better support for PHP integration with Application Servers, and
   3) 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
>