SHELL/CREATEPROCESS and WIN2000-server

[Fred Oxenby]

This is an odd behavior of SHELL and CreateProcess.
ShellExecute works as expected.
Mr Edwin Knoppert reported something similar in July 2000.
Background:
On a WIN2000 E-Server, I am trying to run a Consoleapp (PDPR.EXE) or run
a .cmd-file (witch in turn start PDPR.EXE) from inside a PowerBasic application.
'-------
SHELL returns an Errorcode <> 0 (Unfort. I did not record it)
(ERR-variable <> 0 that is)
'-------
CreateProcess return %NULL
(Process not created)
'-------
ShellExecute runs the EXE (retcode >32) and PDPR.EXE is able to report an errorcode
(runs the executable)
'-------
This is not a problem with the code, as all three variants are run without problem
on a equally configured E-server.
'-------
The reason for PDPR.EXE to fail is that it cannot establish a TCP-connection with
a "print-server" application running on the same E-server, in my opinion a legal
reason for failing.....
'-------
There has been a lot of posting about problem with SHELL an 16-bit programs.
PDPR.EXE is a 32 bit Windows console-app.



------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se



[This message has been edited by Fred Oxenby (edited July 24, 2001).]

[Lance Edmonds]

Fred, what is the question? Ideally, you need to see what error code was returned by SHELL in thius circumstance.

When CreateProcess() failed, what did GetLastError() return?


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Fred Oxenby]

My questuon is the basic one:
Many posyings about failing "Shell" and "CreateProcess" when
starting 16-bir applications.
Are there a similar experiance with starting 32-bit apps?
--
R&D is aware of the problem....(?)


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Lance Edmonds]

I'm not aware of any confirmed issues with PowerBASIC launching 32-bit applications with SHELL.

The issue with launching certain types of 16-bit applications with SHELL is due to a quirk with the way CreateProcess uses it's supplied parameters for certain types of 16-bit applications (from memory, these were VB16 apps).

Can you give any more specific's of the error code you encountered with SHELL? Also, what about GetLastError() when you called CreateProcess) directly?

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Fred Oxenby]

Shell returns "75"
Get last error with Shell returns 0
----
But the E-server is 500 miles away and "Owner" started the required
NT-service, and problem went away..
Project will not permit troubleshooting on this issue until
late august...


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Lance Edmonds]

Ok, but what about GetLastError with CreateProcess? That will probably provide the crucial clue as to why

Note that after SHELL executes, the GetLastError() API result may have been cleared by internal operations. To test whether an API error code was passed back, you would need to use ERRAPI after the SHELL.

This is why I mentioned GetLastError in conjunction with CreateProcess.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Semen Matusovski]

Fred --
try to Shell in format AppDir_ShortPath + ExeName even in case, when 32-bit and dos-app are in the same directory.


------------------
E-MAIL: [email protected]

[Eric Pearson]

> AppDir_ShortPath

Good point. I have it in my notes that "MSDN says CreateProcess does not like long file names". If I can find the actual MSDN page I will post it here.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited July 25, 2001).]

[Tom Hanlin]

There's no problem with using long filespecs with CreateProcess, as long as you
quote them properly. Using unquoted filespecs that contain spaces may cause unusual
results due to Windows' somewhat bizarre approach to parsing.

------------------
Tom Hanlin
PowerBASIC Staff

[Semen Matusovski]

tom -
take a look

------------------
e-mail: [email protected]

[Tom Hanlin]

I believe that's a completely different issue. Due to a "quirk" in some Windows
versions, you may need to pass the program name and parameters to CreateProcess
differently depending on whether the target program is 16-bit or 32-bit code (!).
SHELL doesn't handle this automatically, at least in the current implementation.
As far as I know, there are no issues with long filespecs as such. If you have
found otherwise, please show an example.

------------------
Tom Hanlin
PowerBASIC Staff

[Fred Oxenby]

I am aware of the "LongFileName" quirk in Shell and Create-process
Before using this functions you have to call "PathQuoteSpaces" in Shlwapi.dll
to ensure that file paths are enclosed by double-quotes if it contain spaces.
This is standard procedure in my programming style.
'------------
I have been able to identify the "main NT-seviceNotStarted-problem"
I have a cluster of E-servers
1) Primary server (500 miles away)
2) Secondary servers (one in house for testing/development)
Depending on where your program is executed the program I mentioned, PDPR.EXE,
behaves differently.
If executed on a secondary server, PDPR is communicating with a local daemon witch
in turn relays the communication to the primary daemon. Thus PDPR will not fail
on secondary, if service is not started on primary.
But my "failing code" were executed on the primary server, PDPR communicating with
primary daemon, who was not there answering the phone....
'-------
In both cases (I think) PDPR process should start and run.
Shell did not start PDPR
CreateProcess did not start PDPR
ShellExecute did in fact start PDPR, who was able to report the "daemon-error"
'-------
I will try to force the problem onto my in house secondary server.
'-------
Thank you all!


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se