As metioned above, fork is emulated under Win32(using threads). So both branches of the fork are threads within the same process. When you then exec your command, the entire process is replaced by the exec'd command, which isn't very useful.

To avoid that problem, skip fork completely (just forking and doing nothing is enough to crash Tk;), and use system 1, 'wish temp.tcl'; to run the command asynchronously.

That works, but doesn't give you the opportunity to retrieve the return code from the command if that is important to you. If you need that, you can use threads::async, to run system synchronously in a thread, but asynchronously from the Tk thread.

The following snippet will run the command from the edit field via system in a thread, retrieve the return code and post it to the tk screen. The progress bar is there to show that the tk interface doesn't stall. Indeed, you can click 'Doit' several times and multiple copies of the command will run concurrently:

#! perl -slw
use strict;
use threads qw[ async ];
use Tk;
use Tk::ProgressBar;
use Tk::ROText;

my $cmd = 'perl -le" print for 1 .. 10; sleep 10; exit 123"';
my $mw = MainWindow->new;

my $pb = $mw->ProgressBar()->pack();

my $txt = $mw->ROText(
    -width => 3,
    -height => 1,
)->pack( -side => 'left' );

my $edit = $mw->Entry(
    -width => 80,
    -textvariable => \$cmd
)->pack( -side => 'left' );

my $btn  = $mw->Button(
    -text => 'Doit',
    -command => sub{
        async{
            system $cmd;
            $txt->Contents( $? >> 8 );
        };
    }
)->pack( -side => 'left' );

my $progress = 0;
my $repeat = $mw->repeat(
    100 => sub{
        $progress = 0 if ++$progress == 100;
        $pb->value( $progress );
    }
);

MainLoop;
[download]

When you terminate the tk window, you will see the following errors displayed:

Use of uninitialized value in hash element at c:/Perl/site/lib/Tk/Trac
+e.pm line 181.
Attempt to free non-existent shared string 'Modified' during global de
+struction.
[download]

The first I have no idea about but is probably related to the second.

The second is a consequence of using tk and threads together, but it only occurs when the app is terminating anyway and does not appear from my scant tests to indicate anything that would prevent the app from running correctly and completing successfully.