I have some Windows code that uses GetModuleFileName in order to read some additional files at runtime that are expected at certain place relative to the executable. In Wine, GetModuleFileName doesn't work as intended, and I have trouble to track down the problem. I had to use winemaker's "wrap" option in order to work around initialization problems (C++ code). So the application, "memview.exe.so" is just a small wrapper which loads "memview.dll.so" via "LoadLibrary" and calls the dll's "WinMain". The startup script (a copy of wineapploader named "memview") determines the application's name to be "memview.exe" and thus executes "wine memview.exe". Under these circumstances, GetModulFileName yields "C:\WINDOWS\SYSTEM\memview.exe", which is not correct. If I alter the winapploader script so that wine gets called with "memview.exe.so" instead, GetModuleFileName yields "Z:\local\builts\phaeaco-20031216\src\memview\memview.exe", which is the correct path (but "memview.exe" doesn't exist). There is a second application which I built the very same way (i.e. using a small wrapper "phaeaco.exe.so" which loads the actual code contained in the DLL "phaeaco.dll.so"). This application also uses GetModuleFileName; here it always yields "C:\WINDOWS\SYSTEM\phaeaco.dll", no matter whether the application name given to wine by the wineapploader script is "phaeaco.exe" or "phaeaco.exe.so". This is a confusing picture. Could somebody point out what the expected result of GetModuleFileName is for this scenario (the full path to the dll, I guess) and how it comes about that it yields a path "C:\WINDOWS\SYSTEM\..."? I observed this with Wine-20031118, haven't tested more recent versions. Ralf -- Ralf Juengling <juenglin(a)cse.ogi.edu>
Ralf Juengling wrote:
I have some Windows code that uses GetModuleFileName in order to read some additional files at runtime that are expected at certain place relative to the executable.
In Wine, GetModuleFileName doesn't work as intended, and I have trouble to track down the problem. I had to use winemaker's "wrap" option in order to work around initialization problems (C++ code). So the application, "memview.exe.so" is just a small wrapper which loads "memview.dll.so" via "LoadLibrary" and calls the dll's "WinMain".
The startup script (a copy of wineapploader named "memview") determines the application's name to be "memview.exe" and thus executes "wine memview.exe". Under these circumstances, GetModulFileName yields "C:\WINDOWS\SYSTEM\memview.exe", which is not correct. If I alter the winapploader script so that wine gets called with "memview.exe.so" instead, GetModuleFileName yields "Z:\local\builts\phaeaco-20031216\src\memview\memview.exe", which is the correct path (but "memview.exe" doesn't exist).
There is a second application which I built the very same way (i.e. using a small wrapper "phaeaco.exe.so" which loads the actual code contained in the DLL "phaeaco.dll.so"). This application also uses GetModuleFileName; here it always yields "C:\WINDOWS\SYSTEM\phaeaco.dll", no matter whether the application name given to wine by the wineapploader script is "phaeaco.exe" or "phaeaco.exe.so".
This is a confusing picture. Could somebody point out what the expected result of GetModuleFileName is for this scenario (the full path to the dll, I guess) and how it comes about that it yields a path "C:\WINDOWS\SYSTEM\..."?
I observed this with Wine-20031118, haven't tested more recent versions.
Ralf
basically, because for builtin DLLs, the real file (foo.dll) doesn't exist (only foo.dll.so does). So, we decided to return all builtin DLLs in the system dir. Note that this only applies to builtin DLLs, native DLLs will return the correct path in GetModuleFileName. There's no easy solution to this, and could lead to even stranger results (like a module trying to peek into itself by trying to open as a file the path returned in GetModuleFileName). A+ -- Eric Pouech
Eric Pouech wrote:
basically, because for builtin DLLs, the real file (foo.dll) doesn't exist (only foo.dll.so does). So, we decided to return all builtin DLLs in the system dir. Note that this only applies to builtin DLLs, native DLLs will return the correct path in GetModuleFileName. There's no easy solution to this, and could lead to even stranger results (like a module trying to peek into itself by trying to open as a file the path returned in GetModuleFileName).
A+
Well yes ... and ... I don't get it I ask for foo.dll.so (GetModuleFileName) please give it to me. What is this problems here? I would like to look into my self. Any problems with that? Usually I Just need to know the full path of the Installation. Built in or not give me the file strait, no Ice please. if you are worried about a scenario like - hL = LoadLibrary( foo.dll ) ; - GetModuleFileName(hL) ; - // save fullpath somewhere - // Load fullpath int DllPath - LoadLibrary(DllPath) Well it works LoadLibrary() presumes nothing about names only default paths. Or what are you worried about?
Well yes ... and ...
I don't get it I ask for foo.dll.so (GetModuleFileName) please give it to me. What is this problems here? I would like to look into my self. Any problems with that? Usually I Just need to know the full path of the Installation. Built in or not give me the file strait, no Ice please. the point is that .so files get loaded thru dlopen and we don't have a nice way to get back the actual path to the unix file. That's why we pretend all builtin DLLs are loaded from c:\windows\system, even if the .so file doesn't exist in the unix equivalent of c:\windows\system.
A+ -- Eric Pouech
----- Original Message ----- From: "Eric Pouech" <pouech-eric(a)wanadoo.fr> To: "Ralf Juengling" <juenglin(a)cse.ogi.edu> Cc: <wine-devel(a)winehq.org> Sent: Tuesday, December 23, 2003 11:05 PM Subject: Re: GetModuleFileName mysteries
basically, because for builtin DLLs, the real file (foo.dll) doesn't exist (only foo.dll.so does). So, we decided to return all builtin DLLs in the system dir. Note that this only applies to builtin DLLs, native DLLs will return the correct path in GetModuleFileName. There's no easy solution to this, and could lead to even stranger results (like a module trying to peek into itself by trying to open as a file the path returned in GetModuleFileName).
You are saying that the DLLs I built are "builtin DLLs", right? So far I thought only Wine substitutes of Windows system DLLs are called "builtin DLLs"... But what is the reason for having GetModuleFileName return the system dir for "builtin DLLs"? Also, why does it behave differently for the two programs, as I reported in my initial posting; is one of the two cases exhibiting a bug? Thanks, Ralf
"Ralf Juengling" <juenglin(a)cse.ogi.edu> writes:
But what is the reason for having GetModuleFileName return the system dir for "builtin DLLs"?
Because we don't know the real path, and even if we did there is no guarantee that it is accessible from a Windows drive.
Also, why does it behave differently for the two programs, as I reported in my initial posting; is one of the two cases exhibiting a bug?
Because in one case you used a .exe.so and in the other a .dll.so, they behave slightly differently. It's not really a bug, just a side effect of the fact that you can load a .exe.so by specifying its path explicitly, which you cannot do for builtin dlls. This could be changed, but there hasn't been any real need for that yet. -- Alexandre Julliard julliard(a)winehq.com
Well there is now! Until recently 95% of the work was done on wine. WineLib was a side effect. Look what happens, if I have a "-wrap" application (C++) I need to place a link to it in WINEDLLPATH to even load. and also to all it's supporting DLLs (I know I have 36 of them). If any one is working on it, built in search should support both explicit Path loading, and executable directory. Same as native, Just that the PATH and system-folder changes to WINEDLLPATH. Once the built-in is found it's PATH should be recorded and later served on requests like GetModuleFileName and others. If no one else is doing it? It is the next thing on my list after all the current changes are submitted. And while we are at it. What is the wine policy about Built-in DLLs versions. I have encountered problems where setups where complaining about versions been "0.0.0.0" and also some other not high enough versions. Should we make a quick study about Windows versions and serve them as per WinVER reported? And Alexandre welcome back. I hope you had a good time and a well deserved rest. It was kind of gloomy around here with out you. Free Life Boaz Alexandre Julliard wrote:
"Ralf Juengling" <juenglin(a)cse.ogi.edu> writes:
But what is the reason for having GetModuleFileName return the system dir for "builtin DLLs"?
Because we don't know the real path, and even if we did there is no guarantee that it is accessible from a Windows drive.
Also, why does it behave differently for the two programs, as I reported in my initial posting; is one of the two cases exhibiting a bug?
Because in one case you used a .exe.so and in the other a .dll.so, they behave slightly differently. It's not really a bug, just a side effect of the fact that you can load a .exe.so by specifying its path explicitly, which you cannot do for builtin dlls. This could be changed, but there hasn't been any real need for that yet.
Boaz Harrosh wrote:
And while we are at it. What is the wine policy about Built-in DLLs versions. I have encountered problems where setups where complaining about versions been "0.0.0.0" and also some other not high enough versions. Should we make a quick study about Windows versions and serve them as per WinVER reported?
I think we should add version info...?
And Alexandre welcome back. I hope you had a good time and a well deserved rest. It was kind of gloomy around here with out you.
Yea....... Welcome back....... Tom, bows to your greatfull appearance.... should I say a buddhist chant now? (nom yo ho ring yo ho) or something to that effect. :) It's been a long time since buddhism........ Tom
Boaz Harrosh <boaz(a)hishome.net> writes:
Until recently 95% of the work was done on wine. WineLib was a side effect. Look what happens, if I have a "-wrap" application (C++) I need to place a link to it in WINEDLLPATH to even load. and also to all it's supporting DLLs (I know I have 36 of them). If any one is working on it, built in search should support both explicit Path loading, and executable directory. Same as native, Just that the PATH and system-folder changes to WINEDLLPATH. Once the built-in is found it's PATH should be recorded and later served on requests like GetModuleFileName and others.
It's not that easy, because system dlls have to be loaded from the system directory, so you need GetModuleFileName to return that. It's only for dlls loaded with a explicit path that you can try to return the actual path to the .so file. Also with dlls loaded directly by the Unix loader (which you probably need in C++) you don't have access to the original path at all.
And Alexandre welcome back. I hope you had a good time and a well deserved rest. It was kind of gloomy around here with out you.
Thanks; I certainly enjoyed spending two weeks without touching a computer. I should do that more often <g> -- Alexandre Julliard julliard(a)winehq.com
participants (5)
-
Alexandre Julliard -
Boaz Harrosh -
Eric Pouech -
Ralf Juengling -
Tom