IB2017 has asked for the wisdom of the Perl Monks concerning the following question:

When I pack a Tk script into an .exe in Windows 10 using Strawberryperl 5.28 and I run it, I can see in task manager that TWO instances of my application are running. They have the same name but different PID and different memory usage: A) is very small; B) is bigger. Why this? I noticed this because I was trying to kill my application from outside Perl (to perform an update which requires my application to be killed), and I could kill it. I noticed that the external updater kills only A), not B). The GUI still is shown and seems to work perfectly, even without A). I need to manually kill B) to kill (both) instances. Now my questions:

Is this normal?

It is possible prevent it (when I packed with PerlApp I had only once instance)?

Replies are listed 'Best First'.
Re: PAR pp Windows 2 instances
by Marshall (Canon) on Feb 04, 2019 at 05:18 UTC
    Its been awhile since I generated an exe with GUI on Windows - the last major release was on XP. The default was a command line task that shows STDOUT/STDERR and then a task for the GUI itself (much bigger).

    With PerlApp, there was an option to eliminate this extra task that when maximized shows command line output. I guess that you are using pp? I suspect that there is a similar "launch option". If there is not, then it is possible to write some Perl code to launch your app as a "detached process", meaning that there is no command line. From my previous testing this is about 1/2 page of Perl. Look for a compile option in pp. From my memory on WinXP, killing the command line task also killed the GUI. Windows is a complicated beast - I have no idea why that doesn't work on Win10.

    Update:
    I was trying to kill my application from outside Perl (to perform an update which requires my application to be killed)
    I can't even imagine intentionally doing such a thing. My gosh you are describing something that would be a program crash! I mean as a user if I'm using the GUI and then all of a sudden "poof", the program dies, I'd be pretty upset!! Internally within the main application code, a "kill" command from the OS will likely cause some data loss.

    I have tested Perl signal handlers under Windows - I don't remember exactly how, but there has got to be some better way for your update process to work. Issuing a "kill" at a random moment during user GUI interaction is "BAD, VERY BAD".

    Update:
    If you don't want the command line task, something similar to this should work. I got this from one of my Perl books and I remember testing something close to this in the past. This code does appear in a copyrighted book, but it is so short that I think "fair use" applies because it just shows how to use Win32::Process::Create(). 

    #!/usr/bin/perl -w
# loader - starts Perl scripts without the annoying DOS window
use strict;
use Win32;
use Win32::Process;

# Create the process object.

Win32::Process::Create($Win32::Process::Create::ProcessObj,
    'C:/perl5/bin/perl.exe',            # Whereabouts of Perl
    'perl realprogram',                 #
    0,                                  # Don't inherit.
    DETACHED_PROCESS,                   #
    ".") or                             # current dir.
die print_error(); #or perhaps, just die "some error msg";
#consider using the START command in a Windows batch file

sub print_error() {
    return Win32::FormatMessage( Win32::GetLastError() );
}

    [download]
[reply]
[d/l]

      Thank you for pointing me to the Console issue (I use the -g option to prevent the Console, but I need to look in this matter). As far as the process killing is concerned: well, it sounds bad as I formulated it, but it is not. It is an update process guided by the user by means of a wizard. The user is prompted that the application will be closed before updating (the operation is necessary as the .exe needs to be replaced by the updater).

[reply]
        I don't know about pp and the -g option, but I'm sure that other folks here do know about that. I don't know why there would be 2 PID's unless some kind of console is running? In my previous GUI's using PerlApp, there was only one process if I didn't allow a command line window.

        This does prompt me into thinking about more PerlApp testing... As far as I know, you cannot buy an Active State license for Perl App anymore? This used to be part of their "Perl Dev Kit". I have a legacy license and I am able to maintain that license as long as my yearly payments don't lapse. To my knowledge, Active State does not sell licenses for anything to "small shops" anymore. First payment starts at $1,500? This used to be a $100 one time fee.

        Back in the day, computer hardware was very expensive. My boss got me the $750 for full Active State licensing including the Komodo dev environment. But I could not get the $3K worth of hardware to run it! At the end of the day, I used the $100 Perl Dev Kit and most of our money was plain wasted because the hardware to run the dev environment S/W was so damn expensive. I'm sure that has changed nowadays.

[reply]
Re: PAR pp Windows 2 instances
by swl (Prior) on Feb 04, 2019 at 23:05 UTC

    I don't know if it is possible to suppress it. I think the call to the executable calls the packed perl script as a new process, so there are two related processes.

    It is also independent of Tk. This packed one liner also has four associated processes on my Windows 10 machine, 2 x a.exe, 1 x Console Window Host and 1 x Windows Command Processor:

    pp -e "while (1) {$n = 1}"
a.exe

    [download]
[reply]
[d/l]
Re: PAR pp Windows 2 instances
by Anonymous Monk on Feb 04, 2019 at 13:05 UTC
    Its normal this is faq
[reply]
[reply]

Back to Seekers of Perl Wisdom