Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Close phpGH-16718: GH-Add SAPI module folder to DLL search path
On Windows, it is customary to put dependency DLLs in the main PHP folder, i.e. right besides php.exe. If the SAPI is implemented as .exe, dependency lookup works fine, since DLLs are always searched in the folder of the .exe. However, for Webserver modules, this usually does not work, since the Webserver's executable likely resides in a different folder. While there are obviously solutions to this, the Windows error messages if a module can't be loaded are confusing, so users and even popular AMP distributions often choose to put the DLLs in the folder of the Webserver (e.g. right besides httpd.exe). That can easily cause more confusion later, when users update to a newer PHP version, which requires more recent dependencies. Thus, to simplify setup and to bring the behavior more in line with CLI and CGI SAPIs, we add the SAPI module folder to the DLL search path. We keep that simple, and do not cater to long paths, and silently don't change the DLL search order in case of unexpected failures. Since we are using `SetDllDirectory()` for all SAPIs, that effectively also prevents DLLs being looked up in the current folder, what might break some scripts, but can also avoid confusion regarding ZTS builds, where the current directory of the process is not necessarily what is reported by `getcwd()`. It is also a small security measure, even stronger than safe DLL search mode[1]. Note that this certainly does not solve all problems related to DLL lookup, e.g. that the application folder is still searched first, and that already loaded DLLs will not be searched and loaded again. But it appears to be a sensible improvement, and hopefully prevents others to put DLLs in folders where they don't belong, in the future. [1] <https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order>
- Loading branch information