Re: Behaviour of GetModuleFileName

> 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