On Tue, May 21, 2002 at 10:45:14AM -0400, Warren_Baird@cimmetry.com wrote:
So it looks to me like GetModuleFileName is always returning *only* the filename of the module, not the full path. MSDN says:
Huh, and what about this ??
/*********************************************************************** * GetModuleFileNameA (KERNEL32.@) * GetModuleFileName32 (KERNEL.487) * * GetModuleFileNameA seems to *always* return the long path; * it's only GetModuleFileName16 that decides between short/long path * by checking if exe version >= 4.0. * (SDK docu doesn't mention this) */
So isn't this the case any more ? If so, then it should of course be fixed. But I'm wondering how it could have become broken then in the first place...
(that was my comment, BTW, so I readily remembered that)
And I've come across some windows code that relies on this behaviour.... I've
Of course, as it's supposed to be long.
come up with a somewhat messy patch to fix this by adding a call to dlinfo in the spec code generated by winebuild, but unfortunately there seems to be some code in wine that relies on GetModuleFileName returning only the filename. My current hack is to maintain two versions of winebuild - the one I use when building wine, and the one I use when building my code... Hardly elegant.
Hmm, or do you mean that only *builtin* modules return the file name only and not the complete path ? That'd definitely be a reason to fix something...
I have two questions:
- Would anyone object if I tried to fix wine to behave properly with
GetModuleFileName returning the full path? I haven't dug into it yet, so I don't know how much effort will be required... Is there a reasons we have the current behaviour?
Just go ahead, I guess.