Shell to Console Hangs in Console

[Craig Slane]

I've got a program launch executable compiled with PBWin7.04 that shells to a PBCC5.01 console application with the following syntax:

SHELL nbLoc$+"nbOwner.exe",0

It works without fail in Vista and Win2000 but I get very erratic behavior on Xp with the console hanging about every second time. I've tried synchronous and a synchronous methods and I've tried ShellExecute, too, with no improvement. I get more consistent results by shelling to a little utility called SH.EXE. And so far, upon bootup I can always shell successfully at least once, maybe twice, before things hang. I should add that when the console app is called directly, there is no problem.

I'm quite perplexed at this point. I need the objectivity of someone else who might see something I'm missing.

[Edwin Knoppert]

For quick result you may take a look at start.exe.
Afaik it has options to wait.

[Craig Slane]

All the stuff I'm seeing on start.exe is related to Spyware. You must be referring to something else.

[Edwin Knoppert]

Sorry, can't find it.
Imo there should be a command for this.
Maybe a brain failure... again.

?

[Michael Mattias]

C:\DOS>Start  [/W] exename.exe params

Just change your command line to include start with appropriate params.

'Start' SHOULD be here, too:
Command-line reference A-Z




MCM

[colin glenn]

Or another way to put this, START is an internal command, (like DIR) to the command processor.

Typing START /? in a command prompt window will reveal all the gory details on using this function.

If you do find START.EXE then you have the spyware.

[Michael Mattias]

>If you do find START.EXE then you have the spyware

Perhaps.

I've had child programs hang on all kinds of reasons, eg, conflict with a standard handle, conflict on a disk file, security issues.

"Acting flaky" usually does not occur, however... either it works or it don't. But I think it a tad premature to make a definitive diagnosis, doctor.

MCM

[colin glenn]

Good point, amend that to "If you find START.EXE in your windows folder, you may want to scan it and figure out why it's there eating a built in command from the command shell."

Well, not just the windows folder, anywhere, ...

[Craig Slane]

The Xp machine I'm troubled with is at my workplace. But two of the users of my product have complained about the same problem. They both have Xp Pro, as do I. I'll try the START /? command see what comes up. Meanwhile, I found a wrapper function on here to use createProcess() and will try that instead of shell to see if I get positive results. Maybe a dreaded trip back to the office tonight ....

[Edwin Knoppert]

*maybe* if your calling app creates te console??

AllocConsole()
Shell "My.bat"
FreeConsole()

--

http://www.powerbasic.com/support/forums/Forum4/HTML/011161.html

[Craig Slane]

A very interesting turn of events (for me, anyway) tonight when I did some testing at work. First, it didn't really matter that I used createProcess(). I still have the problem. So, second, I opened task manager, clicked the Processes tab and then right clicked my PBWin app. I selected Set Affinity and saw that the program was allowed on CPU 0 and CPU 1. I unchecked CPU 0 and SUCCESS! I then checked CPU 0 and unchecked CPU 1. SUCCESS! The child process will start without a problem so long as only 1 of the CPU options is checked on the parent process.

Wow - what does this mean? Could this have something to do with register variables?

[Cliff Nichols]

a tad premature to make a definitive diagnosis, doctor.

Paging Dr. Howard, Dr. Fine, Dr. Howard!

"Wooot...WoooT Woooot...Nyuck, Nyuck, Nyuck, Nyuck"

"Why Cointently"

(Sorry could not help myself)

Truthfully though, I am not sure why you would have an app start a console (typically they close momentarily after), and make your program look like what I typically see as a poorly written install???

The actual "Hangmans noose" however could easily be because of an Anti-Spyware program (such as "Spybot S&D")....I would use "SysInternals Process Viewer" to watch if other processes are attaching themselves to your app and just not letting go???

[Michael Mattias]

>(Sorry could not help myself

The help you need surely is professional in nature. But you might get by with pharmaceutical.

[Craig Slane]

Not that I have to defend my programming choices, but suffice to say that the console (main) application is a console application with graphics (and very large). The Windows app is small and used for the purposes of checking in at my server, verify that users have the current build (without which the application may show incorrect data), handling automatic updates and so on. And, the look is actually very professional.

[Cliff Nichols]

Sorry Craig,
I did not mean to sound crass, just a bit of levity.

Mostly when I see programs that mix GUI with a command window, it is usually some sort of Installer, or unzip tool that makes it look odd that I have a GUI with buttons and whatnot, but the programmer could not take the time to show status in the same gui rather than open a DOS window that goes away before you can see what the status is????

In your case the application suits both a GUI and a Command Window (I just could not see it, because of my exposure to what I normally see as poor use of technology, but thats just me)

There may be other ways of doing it, but that is up to the application and the programmer as to which way may be best.



I still hold true to using "SysInternals - Process Viewer" just to see if something is hooking your program and holding it open though.

And if not the case, maybe some loop or other cause in the command window is causing it to "Hang"????

[Craig Slane]

Thanks Cliff nice to read your piece this morning. Someday (music starting...) my console app will be taken to a Windows GUI but it's a daunting task that I've been putting off, so your criticism does have some merit after all.

Back to the problem at-hand, can anyone imagine a reason that the SHELL would work ONLY when 1 of the 2 CPU's are checked (see post above) but not both? I'm still hoping for an answer here, and whether I can adjust my code somehow for a workaround.

[colin glenn]

The shell is to a console program which checks for updates on a remote machine using TCP protocols? Perhaps if it's because it's launching on a different processor, that "side" of XP has to confer with the "other side" to get the permissions for the parent to apply to the shelled program?

Get system internals process explorer and set it to ultra fast updating and watch where all your CPU usage goes.

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

[Craig Slane]

Both the shelling program and the program shelled (the console) use TCP calls. I've downloaded and installed the software you recommended. Interesting data, and useful overall, so thanks. However, I'm not sure that it helps with my problem exactly. I'll load it on my Xp Pro machine and have a close look though. Thanks, again.