Re: Running a DOS program using Microsoft Command Shell



Hi,

Thanks...but...the application in question is smpdk.exe (not the smpdbk91
which is just the archive CONTAINING the application in question).

Sorry for the confusion. I provided the whole package in case some of the
gurus can glean any hints in the documentation...which is mostly just very
complicated Math formulas, very little about the software itsef.

Just to clarify again. First, install the app. Next try the proposed
script. After installing the application, you can verifty that AppActivate
returns true for either "cmd.exe" or "smpdbk.exe"...the MAIN POINT being (you
guessed right)...AFTER we verify that AppActivate is returning TRUE, it is
simply immune to any SendKeys.

Specifically, this does not work, (for example)...

$wsh.AppActivate("smpdbk.exe"); $wsh.AppActivate("{ENTER}");

HOWEVER, if running in command line MANUALLY this works fine.

There-in lies the "bug" or "enhancement request" or "new feature needed" in
MSH/WSH.

Again, use smpdbk.exe WITHIN smpdbk91.exe, please...

Big THANKS for yor time.

"/\\/\\o\\/\\/" wrote:

I did download the Application,
It works for me, I think You used the "wrong" window title so the App
does not get activated:

..\smpdbk91.exe
$wsh.AppActivate("Self-Extracting Archive, Rick's Planet Archive
Manager");$wsh.SendKeys("{ESC}")

tho be sure it is activated :

if ($wsh.AppActivate("Self-Extracting Archive, Rick's Planet Archive
Manager")) {$wsh.SendKeys("{ESC}")} else {"Failed to activate"}

Hope this helps.

greetings /\/\o\/\/

netdawg wrote:
Alex:

Right...faulting the application is actually missing the whole point of this
post. The question I am trying to solve this weekend is what is the best way
to deal with such a situation using windows scripting. I KNOW applications
can be designed better than this. Put things into perspective, this program
was probably written in late 80s, early 90s. My guess is 1991. I am trying
to get a hold of the author, a retired scientist (he is still alive!). Will
look thru documentation, as well, little more carefully this time. But I
STILL INSIST that there should some way of controlling this without looking
for anything else...in fact I have a bet...that this would be a piece of
cake...now I am going to look real dumb!


William: In this program, the ESC key can only be pressed on console, which
is TOTALLY maximized i.e. enlarges the CMD/COMMAND to fill the entire screen
a la DOS with some old resolution.


If you REALLY would like to accept "Mission Impossible", ... all files
needed are available by public FTP:

ftp://ftp.pdc.org/pub/smpdbk/

Run self-extracting file first smpdbk91.exe...the program is "smpdbk.exe"
and the input file (redirect) is run.txt. Obviously, this input file is
missing the ESC character, since I don'y know how to feed ESC in this
fashion. The INPUT.TXT file is actually called WAI.TXT in this FTP.

Please note that:

(1) When run manually (using input params one-by-one in run.txt), the
program should work fine.
(2) When using redirect, the program freezes at the last step and need to
use Task Manager to kill it (output will only be partially done).
(3) When instructed from shell script, the progam simply ignores all SendKeys.

Hope this helps design something at MSFT or enlighten me on the best way to
handle this if it is possible at all...

Thanks!

.