Once again I find that I'm creating another image tool which is using a deficient SDK as its base. I then thought that I would fill those problems, by using ExifTool to run a spawned process to grab some metadata from the file. And hopefully see a way into the file deep enough to solve the original problems, since neither exactly agrees with the other in a way that's clear yet.
Unfortunately now I can 't see a simple way any longer to verify a valid existence of ExifTool with the new installation folder scheme.
..\ExifTool\exiftool-12.89_64\
Perhaps I'm missing something simple here, because I'm trying to solve a different data problem that I thought ExifTool would help me solve. But this new ExifTool installer is going to complicate its providential existence way out of where I want wish to be.
Before it was rather simple, if the EXE was in the installed directory then I thought it OK to forge ahead. But now in addition not exactly where it's going to be thanks to the vagaries of a deficient SDK, I don't know how to fully verify its existence even if I find it.
Does anyone have a SIMPLE suggestion about this that doesn't involve installing Cygwin or another arcane Windows mechanism?
Can I depend on this new folder naming scheme in some way and size?
MFCNikonImageInfo-VerifyExifTool-07.17.24.JPG
If you can run "exiftool -ver" and get back a good version number ("##.##" only, with no warnings), then that would be a good indication that the installation is OK.
- Phil
Well I'm attempting to verify the file before running it first - I don't want to confuse anyone; so I integrated a FileVersion c++ class I found at CodeProject,
CFileVersionInfo - Retrieving a File's full Version Information Resource
https://www.codeproject.com/articles/1502/cfileversioninfo-retrieving-a-file-s-full-version
that helps pop out this data from the EXE file:
CFileVersionInfo::InternalName = exiftool.exe
CFileVersionInfo::OriginalFileName = exiftool.exe
CFileVersionInfo::ProductVersion = 12.8.7.0
CFileVersionInfo::FileVersion = 12.8.7.0
Otherwise there's not much else from just the basic Windows file that I think I can easily use.
So perhaps with some clarity at some point on the subfolder naming scheme, I might be able to verify it's future fitness with what I can retrieve. I've never yet needed the latest ExifTool versions, as they always worked for me in the basic way I've employed it in the past...
Starting with version 12.88 the CFileVersionInfo won't give the ExifTool version number -- it will give the version number of the loader stub by Oliver Betz.
- Phil
I did see that, but what I think you are saying is that I'm completely out of luck now.
There are other fields available to the VS_FIXEDFILEINFO structure, for example, ProductVersion: which is currently not meaningfully populated in that new tiny sub exe. Perhaps this could be populated now for us, once its no longer considered a test version:
CFileVersionInfo::FileVersion = 1.5
CFileVersionInfo::CompanyName = OliverBetz.de
CFileVersionInfo::FileDescription = ExifTool Perl launcher
CFileVersionInfo::InternalName = ppl-exiftool
CFileVersionInfo::LegalCopyright = Oliver Betz
CFileVersionInfo::OriginalFileName = exiftool.exe
CFileVersionInfo::ProductName = Exiftool
CFileVersionInfo::ProductVersion = universal
CFileVersionInfo::Comments = Test version, use at your own risk
CFileVersionInfo::LegalTrademarks IS Not Populated.
CFileVersionInfo::PrivateBuild IS Not Populated.
CFileVersionInfo::SpecialBuild IS Not Populated.
I still think the old single Windows ExifTool.exe solves this problem handily; are there some instructions so we can put the genie back in the bottle? I've never noticed an issue with ExifTool.exe that this new change is trying to solve, so clearly I haven't been trying hard enough.
Is there clarity on this new subdirectory structure hidden in that long forum post?
Quote from: StarGeek on July 18, 2024, 06:22:07 PMLink for building the PAR packer version
pp_build_exe.args, Arguments for building stand-alone Windows executable (https://exiftool.org/forum/index.php?msg=18798)