Behaviour of GetModuleFileName
Warren_Baird at cimmetry.com
Warren_Baird at cimmetry.com
Tue May 21 14:01:27 CDT 2002
> 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...
>
I thought that long/short paths in this context referred to whether the path was
hashed to fit in 8.3 (short) or not (long)... I didn't think it had to do with
whether the full path or only the filename was returned.
> 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...
If by 'builtin' you mean compiled with winelib (as opposed to native modules) -
Then the answer is that I'm not sure - I"m working on Sparc-solaris, so I'm
*only* dealing with winelib compiled modules. I don't know how it behaves with
native modules... The issue is that an incorrect string is stored in the
module header by the call to __wine_dll_register, so I guess it is likely that
the problem only exists with winelib compiled libraries...
> > 1. 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.
Ok - I'll look into it a bit more and see how much effort it would be to fix
wine to work with this...
Thanks!
Warren
More information about the wine-devel
mailing list