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

And old question, I know, and one with a lot of possible answers. But even after searching the archives and reading past discussions, I still need a little guidance.

I have over recent years written a number of small Perl utilities that get called from a massive (commercial) Windows program to accomplish various functions. When called, they of course open a DOS window, do their thing, and close it, usually only a couple of seconds at a time.

This was never a problem, but now suddenly it has become an issue. I tried simply changing the windows associations to call wperl.exe instead of Perl.exe.

That worked beautifully.

Well, almost.

It seems many of these little programs have a line of the form:

open(EP,"$DOSProg arguments|");

Some logic here interprets the data returned by DOSProg.

This runs a MSDOS program that does it's thing and returns data to my Perl script. When running under Wperl, the DOS window still pops up when this DOS app is called. This DOS program is a special purpose utility that would be difficult to re-create purely in Perl.

I am trying to figure out an elegant way to hide this secondary DOS window without requiring massive changes to all the places these scripts are called, etc. I want to find a low-work, low-risk solution to hiding the secondary DOS window.

I originally thought that since the wperl interpreter is running the Perl script in a hidden process, that any process it starts would be likewise. But I guess it isn't so. A shame as simply changing associations makes for an easily reversible hack for troubleshooting purposes.

Any suggestions?

Thanks,

Nat

Replies are listed 'Best First'.
Re: Hiding the DOS window..
by sgifford (Prior) on Feb 20, 2005 at 03:47 UTC
[reply]
      Incidentally IIRC AS Perl distro comes with a (perl - what else?) program that basically just changes the value of a bit in the header of a binary executable and makes it execute without the creation of a console window, which is precisely what is used to make wperl.exe out of perl.exe.
[reply]
      That seems to work perfectly! Thanks.
[reply]
Re: Hiding the DOS window..
by Popcorn Dave (Abbot) on Feb 20, 2005 at 03:28 UTC
    I use this to launch a stock tracking program. You'll get the DOS window briefly. This is in the Perl Cookbook, but it's missing one line in the book so their example doesn't work.

    From the Perl Cookbook: 

    # 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:/perl/bin/perl.exe',            # Whereabouts of Perl
    'perl <your program here>',         #
    0,                                  # Don't inherit.
    DETACHED_PROCESS,                   #
    ".") or                             # current dir.
die print_error();

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

$Win32::Process::Create::ProcessObj -> Resume();

    [download]
    Useless trivia: In the 2004 Las Vegas phone book there are approximately 28 pages of ads for massage, but almost 200 for lawyers.
[reply]
[d/l]
Re: Hiding the DOS window..
by PodMaster (Abbot) on Feb 20, 2005 at 03:50 UTC
    Whatever $DOSProg is, perl.exe (a console application) has little or no control over it. wperl.exe (a windows application) has the same amount of control. What makes console applications special is that they won't open a new console window if invoked through the command interpreter (cmd.exe or command.com). So the only way to hide this other window is depends on 
    cmd.exe /?
command.com /?

    [download]
    and your ability to modify $DOSProg (exetype, exe_update), or your knowledge of the Win32 API, neither of which have much to do with perl.

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]
[d/l]
[select]
More on Hiding DOS Windows
by wa4otj (Beadle) on Feb 20, 2005 at 06:18 UTC
    Thanks to the person who suggested EXETYPE as the solution to my problem. That solved the problem perfectly.

    But in testing, I discovered a new wrinkle.

    I set Window's associations so that the extension .pl is matched to wperl, it calls wperl.exe and runs the script. If I set it to associate Perl.exe, it also runs perfectly, but with the dos box. So far so good.

    If I call the wperl interpreter from Win2k's DOS commandline, it all works perfectly. But when the big commercial program makes the exact same call using it's "run program" operation, the commandline parameters are lost. But when I set the associations back to perl.exe, the commandline parameters are passed properly. Yet when called from the DOS commandline, the cmdline params are passed properly both to perl and wperl.

    Any ideas why?

    Thanks, Nat

[reply]

      Is there a slight difference in how the registry associations are set up in the two cases, e.g., in what is quoted and what isn't? It's been a couple of years since I used Windows enough to mess with registry assocations, so the details are fuzzy in my mind, but ISTR that sometimes little easy-to-miss things like whether the %1 was inside the same quotes as the filepath or a separate set of quotes could make a big difference. Also you don't mention what happens if you double-click a .pl file in explorer.exe; that might help diagnose whether the problem has more to do with the association itself (more likely) or the way the big commercial program is handling it (also possible).

      "In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68
[reply]
        The "big commercial program" (BCP) masks how it handles it, so I don't know exactly what it is doing. BUT, if I set up the call as "Run Program" "\Perl\bin\wperl.exe" with parameters of "Perlscript.pl" "Parameters", it works perfectly. If instead, I make it "Run Program" "Perlscript.pl" "Parameters" the parameters are lost when file associations are set to call wperl for .pl extensions, whereas if the associations are set for perl.exe, the parameters are not lost.

        It may be that I will have to change every call to the first format. That might be acceptable, but it will mean a lot of work going thru the massive data set and locating every place a Perl script has been inserted. I don't even mind the work, it's the mistakes I will make doing it, plus the fact that when reviewing the data for troubleshooting purposes BCP hides the actual parameters. Thus I cannot easily tell at any point what Perl script is being invoked if I make these changes. Annoying.

        Looking at the registry, I don't really see any difference in how they are set up. To change the associations I just right-click on a .pl file and select open with... Choose program... and select Perl.exe or Wperl.exe. It seems pretty transparant, but I am tripping over this silly little anomaly.

        Thanks for the help. Any additional suggestions are most welcome.

        Nat

[reply]
      If I were you, I would re-install ActivePerl.-

      Then, just create a batch file to call wperl, like this... 

      @echo off
REM [callwperl.bat] Just call wperl with the params
c:\perl\bin\wperl %*

      [download]

      ... And call it with the params instead of the other thing.

      You shouldn't be changing those messy extensions without knowing. It should be done through the 'folders extensions' and then at the .pl extension add "%1" next to wperl.exe. 

      .{\('v')/}
 _`(___)' __________________________
      Wherever I lay my KNOPPIX disk, a new FREE LINUX nation could be established.
[reply]
[d/l]

Back to Seekers of Perl Wisdom