Exactly how do you call the external batch file?

Could you post a minimal, working example? Maybe it has the same behaviour even without using Tk? Try that and post that minimal (but complete in the sense of "you can run it") code as example.

Since there are quite a lot of ways to call an external program or batch file on window, at this point we can't even take a guess on the exact nature of the problem.

BREW /very/strong/coffee HTTP/1.1
Host: goodmorning.example.com

418 I'm a teapot

Here a code snippet without using Tk.

use strict;
use warnings;

use Capture::Tiny qw(:all);
use Cwd;
use Data::Dumper;

# BUG or unknown feature in pp:  dll files are not extracted
# Workaround:
# --> renamed dll files in "./PDIMLink" to txt files
# --> at start dll files are renamed back to dll
my $dll_path = "$ENV{'PAR_TEMP'}/inc/PDIMlink/host/x86-win32";
rename("$dll_path/bin/cygwin1.txt", "$dll_path/bin/cygwin1.dll");
rename("$dll_path/bin/tcl.txt", "$dll_path/bin/tcl.dll");
rename("$dll_path/lib/cpluslib.txt","$dll_path/lib/cpluslib.dll");

open( my $fh1, ">", "V:/log1.txt" );
print $fh1 Dumper(\%ENV);
close( $fh1 );

my ($stdout, $stderr, @result);
($stdout, $stderr, @result) = capture
{
    my $cwd = getcwd;
    chdir("$ENV{'PAR_TEMP'}/inc/PDIMlink");
    `pdim_link.bat "1.elf"`;        
    chdir($cwd);
};

open( my $fh2, ">", "V:/log2.txt" );        
print $fh2 "STDOUT: $stdout\n";
print $fh2 "STDERR: $stderr\n";
print $fh2 "Result: @result\n";
print $fh2 "$ENV{'PAR_TEMP'}/inc/PDIMlink\n";
print $fh2 Dumper(\%ENV);
close( $fh2 );
[download]

But it is exactly the same behaviour as in the Tk version ( see http://www.perlmonks.org/?node_id=943505). So I know the problem has nothing to do with Tk.

What do you suggest for a way to find the error?

post code, not nothing

You are right. Code helps more. So I wrote a small script which can reproduce the behaviour.

use strict;
use warnings;

use Tk;
use Capture::Tiny qw(:all);
use Cwd;
use Data::Dumper;

# BUG or unknown feature in pp:  dll files are not extracted
# Workaround:
# --> renamed dll files in "./PDIMLink" to txt files
# --> at start dll files are renamed back to dll
my $dll_path = "$ENV{'PAR_TEMP'}/inc/PDIMlink/host/x86-win32";
rename("$dll_path/bin/cygwin1.txt", "$dll_path/bin/cygwin1.dll");
rename("$dll_path/bin/tcl.txt", "$dll_path/bin/tcl.dll");
rename("$dll_path/lib/cpluslib.txt","$dll_path/lib/cpluslib.dll");

my $mw = MainWindow->new;
$mw->geometry("220x150+100+120");
$mw->title("Test - PP with --gui option");

$mw->Button(
    -text => "Start",
    -command =>
    sub
    {
        my ($stdout, $stderr, @result);

        open( my $fh1, ">", "V:/log1.txt" );
        print $fh1 Dumper(\%ENV);
        close( $fh1 );
        
        ($stdout, $stderr, @result) = capture
        {
            my $cwd = getcwd;
            chdir("$ENV{'PAR_TEMP'}/inc/PDIMlink");
            `pdim_link.bat "1.elf"`;        
            chdir($cwd);
        };

        # this file is NOT created if --gui option is active
        open( my $fh2, ">", "V:/log2.txt" );        
        print $fh2 "STDOUT: $stdout\n";
        print $fh2 "STDERR: $stderr\n";
        print $fh2 "Result: @result\n";
        print $fh2 "$ENV{'PAR_TEMP'}/inc/PDIMlink\n";
        print $fh2 Dumper(\%ENV);
        close( $fh2 );
    }
    )->pack;

MainLoop;
[download]

The "pdim_link.bat" file I'm not allowed to publish. But I'll try to reproduce the same behaviour with a bat file which I can publish to you.

Now to the code: If I pack it with the --gui option, i.e. pp --gui -a "./PDIMlink" -o test.exe test.pl then "pdim_link.bat" does NOT work and the file "log2.txt" is NOT created.

If I pack the code without the --gui option, i.e. pp -a "./PDIMlink" -o test.exe test.pl then both files (log1.txt and log2.txt) are created and "pdim_link.bat" works as expected.

The file "log1.txt" which contains the Dump of the environment variables is not different (apart from the cryptical path e.g. .../cache-94cdd0fc50fcdc36d7cd4972d0f2afa676e0b848/.. ) with or without using the gui option.

BUG or unknown feature in pp: dll files are not extracted

-a is for data, -l is for dlls

... cygwin1.dll ...

mingw perl uses

$ perl -V:sh
sh='/bin/sh';
[download]

IIRC cygwin uses the same thing (but its been a long while since I cygwin)

win32 perl uses

$ perl -V:sh
sh='cmd /x /c';
[download]

So once you pack with par/pp into an .exe, it can't find /bin/sh, because it doesn't exist (the .exe doesn't know about the cygwin enviroment/$PATH etc, its a win32 program), or /bin/sh doesn't know how to call a .batch file

In short, avoid the shell, or call the right shell

I haven't the time to post a working example , but I you should be able to gain some wisdom by reading these

`STRING`

Re: Problem in creating exe using PAR module, Re^2: Packaging Perl Programs (is) Painful, Re: Building a Mojolicious app with PAR::Packer

Re: Pack multiple scripts in executables with one shared core dll

Re: system() implementation on Windows (again), Re^3: system() implementation on Windows (again)

http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/everyone-quotes-arguments-the-wrong-way.aspx# Everyone quotes command line arguments the wrong way

What happens if you run the --gui packed executable from a cmd.exe ?

Dump %ENV and compare...

I have seen system calls failing due to C:/WINDOWS/SYSTEM32 missing in %PATH% on some Win installations. (Tk app packed with pp using --gui option)

Thank you for your advice. I dumped %ENV, but there was no significant difference with or without the gui option.

For details see http://www.perlmonks.org/?node_id=943505