Proposal: make the format set and the external plugin loading configurable at build time (three small PRs) #97

I use FreeImageRe in a Windows application which reads and writes only five formats (BMP, GIF, PCX, PNG and JPEG). The application is subject to the EU Cyber Resilience Act, which means that I have to keep a software bill of materials, assess every published vulnerability against what I ship, and minimise the attack surface. Thank you for maintaining the library, it made this possible at all.

Three things get in the way, and I have a small pull request for each. The default build is unchanged in all of them.

1. About twenty plugins cannot be removed. The FREEIMAGE_WITH_LIB* options remove a dependency together with its plugin, but BMP, CUT, DDS, GIF, HDR, ICO, IFF, JNG, KOALA, MNG, PCD, PCX, PFM, PICT, PNM, PSD, RAS, SGI, TARGA, WBMP, XBM and XPM are always compiled and registered. Applications that auto-detect the format of a user-supplied file expose the parsers of all of them. Every CVE report against an unneeded plugin also has to be assessed, even if the code could simply be left out. Runtime switching with FreeImage_SetPluginEnabled does not remove the code from the binary.
PR: FREEIMAGE_WITH_PLUGIN_<NAME> options, default ON.

2. External *.fip plugins are loaded in DllMain. On Windows, DllMain calls FreeImage_Initialise(FALSE), which loads every *.fip found next to the executable and in plugins\. The application cannot prevent this, because it runs before any application code. The function also calls SetCurrentDirectoryW and LoadLibrary under the loader lock. On x64 and ARM64 the lookup of the entry point _Init@8 (the x86 stdcall decoration) cannot succeed, so the feature does not work there: the file is loaded, its DllMain runs, and it is unloaded again. For applications which restrict the code they load, this is only a risk.
PR: FREEIMAGE_WITH_EXTERNAL_PLUGINS, default ON. To be clear about scope: this PR only makes the loader optional; it does not fix the _Init@8 lookup. With the option ON (the default) the x64/ARM64 behaviour is unchanged. If you would like the _Init@8 lookup fixed as well (an arch-aware entry-point name), I can prepare that as a separate PR — I left it out here because it changes the external-plugin entry-point contract and I cannot test it, as I ship no *.fip plugins.

3. The DLL has no version resource. Installers, SBOM generators and scanners cannot read its version, and a file without a version never replaces an older one with a version in Windows Installer patches.
PR: a generated VERSIONINFO with FREEIMAGE_VERSION_TWEAK and FREEIMAGE_SPECIAL_BUILD.

Pull requests:

• Add FREEIMAGE_WITH_PLUGIN_<NAME> options for built-in plugins #98 — FREEIMAGE_WITH_PLUGIN_<NAME> options, default ON
• Add FREEIMAGE_WITH_EXTERNAL_PLUGINS option #99 — FREEIMAGE_WITH_EXTERNAL_PLUGINS, default ON
• Add a version resource to FreeImage.dll #100 — generated VERSIONINFO resource for FreeImage.dll

If you prefer a different design (for example another option naming, one option with a list of plugins, or removing the external plugin loader completely), I am happy to rework the PRs.