Can PAR create an alternate Windows package?

Started by obetz, April 03, 2019, 12:14:51 PM

Previous topic - Next topic

obetz

Hi,

the PAR packed exiftool extracts the perl environment somewhere in the temp directory, which is often considered suspicious by virus scanners and can be even prohibited by system policies.

Is the PAR packer able to make a package to be put in some arbitrary location instead of "temp"?

Instead of creating the directory automatically on the first call of exiftool, the user could then unzip the files to a suitable place and run exiftool from there.

Oliver

Phil Harvey

Hi Oliver,

You should be able to set the PAR_GLOBAL_TEMP environment variable to specify where the unpacked files go.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

obetz

Hi Phil,

the parallel thread "Software restriction policies" mentioning PAR_GLOBAL_TEMP first gave me the idea (and the "stub" thread for using an already installed Perl).

Will a permanent PAR_GLOBAL_TEMP setting cause problems if there is more than one PAR packed Perl application, all using the same directory?

Or when I start (by accident) an application containing a different (e.g. older) version of exiftool?

Oliver

Phil Harvey

Multiple PAR packages may use the same directory without any problems.  This includes running different versions of exiftool at the same time.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

obetz

Hi Phil,

thanks for the clarification, then PAR_GLOBAL_TEMP is the way to go for me.

Oliver

obetz

(using PAR_GLOBAL_TEMP to keep exiftool out of the %temp% directory)

Quote from: Phil Harvey on April 04, 2019, 07:01:40 AM
Multiple PAR packages may use the same directory without any problems.  This includes running different versions of exiftool at the same time.

trying different versions of exiftool, I found that libraries are not updated if PAR_GLOBAL_TEMP is set.

As far as I see, the libraries from the initially used exiftool version are not overwritten even if I run a newer version of exiftool afterwards.

Exiftool -ver then emits a warning like "[Warning: Library version is 11.26]"

Probably it is necessary to delete the contents of the directory specified by PAR_GLOBAL_TEMP if a new version of exiftool is used.

Can I expect old versions of exiftool to work with newer libraries?

A version mix sometimes can't be avoided since some applications come with (rely on) a specific version of exiftool.

Oliver

Phil Harvey

Hi Oliver,

I am surprised because PAR should be creating directories like "cache-exiftool-11.39" within the temp directory, so the libraries for each version of ExifTool are separate.  This is certainly the behaviour if PAR_GLOBAL_TEMP is not set.  If setting this environment variable puts the files for all versions in the same directory, then that is bad, and I would suggest finding another solution.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

obetz

Quote from: Phil Harvey on May 06, 2019, 04:21:39 PM
I am surprised because PAR should be creating directories like "cache-exiftool-11.39" within the temp directory, so the libraries for each version of ExifTool are separate.  This is certainly the behaviour if PAR_GLOBAL_TEMP is not set.  If setting this environment variable puts the files for all versions in the same directory, then that is bad, and I would suggest finding another solution.

Then we're back to square one.

I would love to see a solution without the "unpacking magic". IMO it's not needed to hide the files from the users and make them believe that ExifTool ist just a monolithic executable.

The current Windows file is close since it contains (nearly?) everything to run exiftool. I'm only missing a way to run ExifTool directly from the unpacked location.

I asked in the par mailing list and will report back here what I found.

Oliver

Phil Harvey

Hi Oliver,

Quote from: obetz on May 08, 2019, 02:52:22 AM
I would love to see a solution without the "unpacking magic".

There already exists this solution.  Just install Perl yourself and use the pure Perl version of ExifTool (the full Image-ExifTool distribution).   Then you can run exiftool as "perl exiftool ...", or rename "exiftool" to "exiftool.pl" and run as "exiftool.pl ..." (to do this you must check the option to make .pl files executable when you install ActivePerl).

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

obetz

Hi Phil,

Quote from: Phil Harvey on May 08, 2019, 07:07:54 AM
There already exists this solution.  Just install Perl yourself and use the pure Perl version of ExifTool

pp does a great job resolving all dependencies and putting only the needed files together, including the Perl interpreter. So it is tempting to use it as a "lightweight" alternative to a full Perl installation.

Which Perl do you currently use to build ExifTool.exe?

Oliver

Phil Harvey

...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

obetz

Quote from: Phil Harvey on May 08, 2019, 09:28:50 PM
I use ActivePerl.

I installed 32 bit Activestate Perl 5.24 (in a VM) and copied only it's 132KiB perl.exe to the directory where I unpacked exiftool 11.35 on a PC without Perl.

There I could run perl.exe -Iinc/lib 79c3cb44.pl -ver successfully (79c3cb44.pl is exiftool.pl renamed by pp).

I didn't investigate this further, but likely the only thing missing in a pp created achive is "perl.exe".

What's the benefit?

  • I don't need to install Perl
  • I don't need to "make" ExifTool
  • The installation is rather compact (ExifTool unpacks to less than 1000 files, roughly 24MB
  • I'm in control where the Exiftool runtime is unpacked (and executed)

I remember there was a "ExifTool stub" to call exiftool with perl.exe, this might be an useful addition. I will have a look at it.

BTW: Roderich Schupp wrote "Use of PAR_GLOBAL_TEMP is discouraged" when I asked about the problems. And I don't want to cite his answer to my questions about using the pp generated files without the "auto unpacking magic".

Oliver