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...
- 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