Hi,
Let me make the problem clear:
The application I am working on is ncverilog.exe.
When I do "wine {ABSOLUTE_PATH}/ncverilog.exe", it gives the help for
ncverilog correctly.
ncverilog.exe starts other executables:
a)ncvlog.exe
b)ncelab.exe
c)ncsim.exe
Each of the above modules, I tried running independently by giving the
absolute path (wine {ABSOLUTE_PATH}/ncvlog.exe) and they work fine.
The problem is that installed files are on a server and are nfs exported as
read only files.
Also each of the executables ncvlog.exe etc generate lot of other files for
the next executables namely ncelab.exe(inputs to this are the files
generated by the previous executable) etc.
When a user does an nfs mount to get the appropriate installed files from
the nfs server, the
binaries and libraries are read only. This way if we go the installed
directory and do a
"wine ncverilog.exe something.v", this fails since the intermediate file
generation is not possible since it is exported read only. One way of
avoiding this is to have links to the executables in some other directory
and run "wine ncverilog.exe" from there. I had tried this before and this
works.
What I tried was to first run this executable in windows using the cygwin
shell. The "PATH" was the only environment variable that was set. And I
think that is enough in that case. So my actual question should have been :
"How does the windows equivalent of the PATH translate to wine's search PATH
for the executable"
And finally sorry for not naming the executables, the reason was that these
are all tools which hardware engineers normally use and I thought that the
names in general would not be of any significance, without realising that if
I would have given the names, later some time, problem of some other
hardware engineer might be solved easily.
Thank you,
Deepesh
-----Original Message-----
From: Holly Bostick [mailto:motub@xxxxxxxxx]
Sent: Sunday, June 05, 2005 4:05 PM
To: wine-users@xxxxxxxxxx
Cc: D Deepesh
Subject: Re: Problem in the path for executables...
D Deepesh schreef:
> Hi,
>
> I have a windows executable which I am trying to run in Linux using wine.
> When I execute the command :
>
> wine {ABSOLUTE_PATH}/file1.exe,
>
> file1.exe runs many other executables internally, like file2.exe,
file3.exe
> and file4.exe.
>
> Now when file1.exe is trying to run the other executables, it is not able
to
> get the path of the executables. I have the "PATH" enironment variable set
> correctly. But I do not think this is the problem.
>
> I enabled the WINEDEBUG so that I see all the wine warning and error
> messages. From that I could deduce that the executables file2.exe,
file3.exe
> and file4.exe were being searched in the current working directory.
>
> Please guide me on how to tackle this situation.
>
> Is there any entry in the windows registry which is set when the software
is
> installed on the windows system and some such equivalent is missing in
wine
> configuration settings in linux.
>
> Thank you,
> Deepesh
>
>
>
Hello, Deepesh,
The first thing that seems a good idea is to try running the program
from the installation directory rather than from some random current
working directory. The program you are trying to run would be far from
the first that vastly prefers being run like this
cd /program_installation_directory
wine program.exe
than like this
wine /program_installation_directory/program.exe
There are enough programs that run poorly or not at all in the latter
case, but run perfectly fine when run in the former manner, that it's
worth assuming that the program should be run from its installation
directory rather than by absolute path as a general rule.
If you're trying to run programs from a shortcut or panel entry, it's
quite easy to write a short bash script to ensure this:
#!/bin/bash
cd program_installation_directory
wine program.exe
name it program_start.sh, make it executable, and then link the shortcut
to this script rather than the absolute path. I've got several such
scripts myself for this very reason.
This may solve your problem without further ado. If it does not,
however, we can move to my second point:
Is there some secret code I am unaware of that makes people reluctant to
flatly state the name of the program they are trying to run? I feel like
there must be concerns that some native-Linux-application-use secret
police are monitoring the list or something, since you are again far
from the first who has constructed an elaborate hypothetical to describe
the behaviour of some program rather than just saying, "Program X
(Photoshop, Dreamweaver MX, Half-Life, whatever) does this."
I just don't understand it. As this is the wine-users list, we already
expect you to be attempting to run non-native programs, since that's all
Wine runs. So I can't see the harm in saying what the program is;
certainly nothing that would cause so many users to behave as if they
were doing something so shameful by attempting to run a Windows
application in the first place that they can't even whisper the name of
the application they're having problems with. If there *were*
native-Linux-application-use secret police-- which there are not-- we'd
already be busted anyway :-) , and in any case, it's your computer; you
can run what you want. That's the very reason Wine exists... so you can
run what you want, native or non-native alike.
Being specific would enable both us and you to easily determine if this
is a known problem with that particular program, or a known problem with
the class or group of programs within which your application falls.
Because Windows applications are not standardized, Wine does not (and
probably won't ever) work so well that a description of the performance
(or lack of performance) for a hypothetical "program.exe" is a suitable
replacement for concrete data regarding a specific application such as
"PowerPoint.exe".
Your question about the Registry is an example of this. How can we
possibly know if there's a difference between the native Registry
entries for this program and the Wine Registry entries for this program
without knowing what the program is (and thereby knowing, hopefully,
what Registry entries it creates under both native and non-native
conditions)?
So if running your "mystery program" :-) from the installation directory
rather than via an absolute path does not help, please provide more
details about the program and any error messages when it fails (if you
are not running the application from a terminal, please do so for the
purposes of this experiment so that you can see any error messages
produced by the console).
Hope this helps,
Holly
_______________________________________________
wine-users mailing list
wine-users@xxxxxxxxxx
http://www.winehq.org/mailman/listinfo/wine-users
