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
>  



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php