wine users - Aug 2004 - batch file fails, individual programs in it run

I posted to the list a day or two ago about a problem that I thought was
related to a new kernel

(http://www.winehq.org/hypermail/wine-users/2004/08/0178.html)

As it turns out, I've discovered that I *can* run programs in Wine as
a non-privileged user; what fails for me is calling those same programs
from a batch file.

To summarize what I've found:

Suppose that 'foo.exe' is the complete text of foo.bat, and make it
world-readable.

'wine foo.exe' works both for root and for others.
'wine start.exe foo.bat' works for root but fails for others.

The errors look like this:

fixme:exec:ShellExecuteExW32 flags ignored: 0x00000500
fixme:exec:SHELL_ExecuteW Strange error set by CreateProcess: 203
fixme:exec:SHELL_ExecuteW Strange error set by CreateProcess: 203
Application could not be started, or no application associated with the specifi
ed file.
ShellExecuteEx failed: Environment variable not found

Additionally, 'wine start.exe' with no arguments works fine for all
users---it
prints the help for start.exe. So there's no problem running start.exe;
it's
the ShellExecuteEx call in it that's failing.

This worked (for me, at least) in 20040505, and hasn't in any release since.

Can you do cvs regression testing?
If not, can you send me a copy of foo.exe and foo.bat, if the licence allows it?

Ivan.

> Just to clarify, am I supposed to be zeroing
> in on the last date for which the version of Wine in CVS doesn't choke
on
> my batch file, and from there determining which modification caused the
> problem?
Yes, a log of all chenges in wine is here
http://www.winehq.com/hypermail/wine-cvs/
> int main() { return 0; }
did you compile it with mingw?
> and foo.bat was created like this: echo 'foo.exe' >foo.bat
have you tried
echo wine foo.exe > foo.bat ?

Ivan.

On Tue, 24 Aug 2004 19:31:08 -0500, you wrote:
> I posted to the list a day or two ago about a problem that I thought was
> related to a new kernel
> 
> (http://www.winehq.org/hypermail/wine-users/2004/08/0178.html)
> 
> As it turns out, I've discovered that I *can* run programs in Wine as
> a non-privileged user; what fails for me is calling those same programs
> from a batch file.
> 
> To summarize what I've found:
> 
> Suppose that 'foo.exe' is the complete text of foo.bat, and make it
> world-readable.
> 
> 'wine foo.exe' works both for root and for others.
> 'wine start.exe foo.bat' works for root but fails for others.
> 
> The errors look like this:
> 
> fixme:exec:ShellExecuteExW32 flags ignored: 0x00000500
> fixme:exec:SHELL_ExecuteW Strange error set by CreateProcess: 203
> fixme:exec:SHELL_ExecuteW Strange error set by CreateProcess: 203
> Application could not be started, or no application associated with the
specifi
> ed file.
> ShellExecuteEx failed: Environment variable not found
> 
> Additionally, 'wine start.exe' with no arguments works fine for all
users---it
> prints the help for start.exe. So there's no problem running start.exe;
it's
> the ShellExecuteEx call in it that's failing.
> 
> This worked (for me, at least) in 20040505, and hasn't in any release
since.
For running batch files wine gets the command interpreter form the
environment variable COMSPEC. Wine comes with wcmd. Try:

COMSPEC=/usr/local/bin/wcmd wine start foo.bat

(adjust the path if needed)

or user wcmd directly:

wcmd /c foo.bat

I am not sure whether having to specify COMSPEC is a feature or a bug.
Perhaps it is related to the other configuration changes that
"happened"
lately.

Rein.
-- 
Rein Klazes
rklazes@xs4all.nl

Thus spake Rein Klazes:
[snip]
> 
> For running batch files wine gets the command interpreter form the
> environment variable COMSPEC. Wine comes with wcmd. Try:
> 
> COMSPEC=/usr/local/bin/wcmd wine start foo.bat
> 
> (adjust the path if needed)
> 
> or user wcmd directly:
> 
> wcmd /c foo.bat
> 
> I am not sure whether having to specify COMSPEC is a feature or a bug.
> Perhaps it is related to the other configuration changes that
"happened"
> lately.
> 
> Rein.
> -- 
> Rein Klazes
> rklazes@xs4all.nl
Setting COMSPEC makes this work. That solves the problem for me. Woo! 

Apparently COMSPEC became compulsory for this between the 20040505 and the 
20040615 builds, as I started to see the problem behavior after upgrading 
to the latter.

Thanks so much!

-- 
J.