Honestly though, my real focus is metadata, which is why I chose Perl for ExifTool in the first place (ie. almost no compiler/platform issues -- compare this to other metadata projects like Exiv2 which spend most of their time dealing with compilation issues).
Don't know much about Exiv2, but Perl itself
has issues with Windows and pp adds more. My motivation are the resulting Windows issues of ExifTool. It can't be that users try to run ExifTool with elevated privileges or disable the virus scanner (especially because ExifTool resides in world writable %temp%).
In this respect, Windows has been a thorn in my side, but it seems like a majority of ExifTool users run this platform so I must deal with it
That's it. And ExifTool is integrated in many great applications running (also) under Windows like IMatch, Geosetter, Affinity, FastPhotoTagger. BTW: Especially for this "integrated" use of ExifTool, the "pp-less" operation would be much cleaner!
My current status: The "unpacked" exiftool.exe currently works pretty well for me, and I'm also experimenting with Strawberry Perl.
Can you estimate the coverage of the automated tests? Or tell me what should be tested in addition to them?
From the past, I know there can be subtle differences between Perl distributions, therefore it would be good to know what the automated tests do not cover.
For example, I generally avoid "unusual" path/file names with spaces and non-ASCII characters so I did no thorough tests regarding this "minefield". But I know that other people don't care about this.
The parameter mangling in the pp bootstrapping (
boot.c -> shell_quote) might influence quoted parameters, so this should be also tested.
There are known problems with daylight saving time zones, and Cygwin handles them differently. Likely ExifTool doesn't rely on the built-in file time functions, correct?
I'm not sure whether Test::Harness::runtests() has all necessary capabilities, maybe Windows specific tests are needed (e.g. with a cmd file or even PowerShell.
Besides, runtests() seems to rely on access to "perl.exe", therefore it doesn't handle the specifics of a Windows exe with a different name.
Oliver