-
Jehan authored
... Windows installation of GIMP. Our default installer installs 32-bit version of the various DLLs in 32/bin/ (under the installation prefix). Currently this additional folder is simply added in the PATH, so it works most of the time. Unfortunately the PATH is searched last for DLLs, and in particular, it is searched after system directories. So it means that if any misbehaved application is installing DLLs in system dirs (and in particular incompatible/older versions of the same DLLs a GIMP plug-in uses), it breaks the 32-bit plug-in. SetDllDirectoryW() bypasses this order and the set folder is searched in between the binary directory and the system dirs. We were already setting this for our main bin/ directory, which was good for 64-bit plug-ins, but this was not protecting 32-bit plug-ins. Now our code to run plug-ins check the bitness of the executable before running it, and updates the DLL folder accordingly. The alternative 32-bit folder can be overridden by the configure option --with-win32-32bit-dll-folder (default: 32/bin/). This option can only be set when building for 64-bit Windows obviously. Alternatively we could have put copies of 32-bit DLLs in a subfolder with each 32-bit plug-in, but this is at best a terrible workaround, as we would duplicate DLLs for every such case. And this would not have protected third-party plug-ins which wish to use some of our DLLs. Last alternative is to use AddDllDirectory(), but it works since Windows 7 with a given update only. And our current official support is any Windows since Windows 7. So we don't want to use this right now (also I'm not sure it would actually be much better than current implementation, and it seems to have a bit more limitations than SetDllDirectoryW(), though I have not tested). (cherry picked from commit 91c139f4)
624edf90