New zip content format in 13.00

[jurgen]

Hi, I have a windows app, that allows downloading the (windows) exiftool from exiftool.org, and unzips the file for the user. Super simple, and convenient. Before v13.00, the content of the zip was one (10MB) exe, but with version 13, the zip contains an additional exiftool_files folder with several libs and lots of files (497 files in 117 folders, 32MB).
Is there a plan for having a single exe release as with previous versions?
Having the addition subfolders is not very portable.
Maybe I'm missing something reagrding this breaking change?

Thanks!

Edit: Never mind, I found the answer to this on another thread. Still, very invonvenient from users side, but I understand your reasoning.

[StarGeek]

The file setup changed with version 12.88, July 11, 2024. You can read the reasoning behind it on Oliver Betz Portable Perl Applications on Windows post.

Oliver also provides an installer for both 32 and 64 (new) bit versions. You might want to look into that as it is much simpler to deal with and sets up the necessary PATH env variable entries automatically.

[Phil Harvey]

The original (pre 12.88) exe contained the same files, it is just that you didn't see them -- they were automatically unzipped into a temp folder.  So it used more space or your disk because you needed to keep the large exe file containing all the other zipped files, plus it still needed the unzipped files.

- Phil

[jurgen]

Thanks for your comments!

[jurgen]

The exiftool(-k).exe file in the zip has version 1.0.5, but shouldn't this match the release version. In this case, 13.0.0?
This would allow to simply check which version is installed.

[Phil Harvey]

Use exiftool -ver to check the ExifTool version.  The exe version is the launcher version.

- Phil

[jurgen]

The -ver option is good for interactive usage, but to check the version from a calling app, exiftool needs to be run and the output captured instead of simply checking the version stamp of the tool.
From user perspective, the exe is the exiftool, and while it is a launcher, it is associated with the version of exiftool. Thats why I think it would be much better to have the exe version set to the product version (instead of the launcher version).

I still think a single exe version package would be much better from user perspective. The additional 30+MB are not a concern these days for the installation, and not having to deal with an almost 500 files folder would be appreciated too (and it takes some time to unzip the files from the windows explorer in the current 13.00 package).

The setup time with the previous single executable package was very fast, and I never noticed it being slow. I only learned about the first-time temp folder setup from this discussion.

Maybe it would be possible to have a single exe package as an alternative. I think a significant amount of users would prefer having just one file.

I really appreciate the ongoing development and thanks for reading my comments!

[Phil Harvey]

There are a number of other problems with the old .exe package, and I don't want to go back to that.  I think that the biggest problem with the new package is for people to become familiar with the new installation technique.

I see your point about the exe version number, and if I had a utility on the Mac that could change that then I could do something about it.  As it stands now I can do a full release of all ExifTool versions using a single script on my Mac, and it would take a lot of convincing for me to move away from this.

- Phil

[obetz]

I see not much benefit in updating the launcher's version information.

If you want to do it anyway:

1. I could send you Launchers with the next version numbers.

2. You could compile the launcher from source (I use gcc) for each new release. I'm not sure whether there is a cross compiler running on a Mac to compile Windows executables.

3. Resource Hacker could also set the version number, but you have to run it also in a Windows VM.

[FrankB]

I also rely on ExifTool -ver to find the version, but...

Even patching the Exe is not that difficult. You can scan for 'VERSION INFO'. or just use fixed offsets, they will only change when recompiled. As long as you dont change the length, it should work.

[obetz]

Another thought: My launcher is just a tiny component of the whole package, and other components have also their own version information.

If we make the launcher version match the ExifTool version, we don't know from which source version it has been compiled.

So one might argue that the launcher should not follow the ExifTool version but keep it's own information.

[FrankB]

So one might argue that the launcher should not follow the ExifTool version but keep it's own information.

I agree.

Edit: Or... use Product version for the Exiftool version. It now reads 'universal'

[Phil Harvey]

Thanks Frank,

I like your suggestion of setting ProductVersion to match the ExifTool version by replacing the string at a fixed offset in the exe.  I'll implement that for version 13.02

- Phil

[FrankB]

Great Phil,

Only thing that could go wrong, if the offsets change after a recompile.

(Dont have to tell you that the 32 and 64 Bits version have different offsets?)

Frank

[Phil Harvey]

Hi Frank,

I put a test in to be sure the value is "universal\0" (UCS2) before I overwrite it.  So if I forget about this down the road and update the launcher, my "publish" script will fail.

- Phil