Behaviour of GetModuleFileName

So it looks to me like GetModuleFileName is always returning *only* the filename
of the module, not the full path.   MSDN says:

lpFilename
     [out] Pointer to a buffer that receives the path and file name of the
     specified module.

And I've come across some windows code that relies on this behaviour....  I've
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.

I have two questions:

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?

2.  I've attached the patch I'm using at the bottom of this message - can
anyone think of a cleaner way of doing this?

Thanks!

Warren

-------------------------------------------------------------

--- spec32.c   Thu Apr 11 11:53:35 2002
+++ spec32.c.full_path   Thu Apr 11 11:51:53 2002
@@ -751,12 +751,28 @@
     fprintf( outfile, "#endif /* defined(__GNUC__) */\n\n" );

fprintf( outfile,
+               "#include <dlfcn.h>\n"
+               "#include <link.h>\n"
              "void __wine_spec_%s_init(void)\n"
              "{\n"
              "    extern void __wine_dll_register( const struct
image_nt_headers *, const char * );\n"
              "    extern void *__wine_dbg_register( char * const *, int );\n"
-             "    __wine_dll_register( &nt_header, "%s" );\n",
-             DLLName, DLLFileName );
+               "    char buffer[4096];\n"
+               "    Link_map *p;\n"
+               "    if (dlinfo(RTLD_SELF,RTLD_DI_LINKMAP,&p)) {\n"
+               "      strcpy(buffer,"%s");\n"
+               "    } else {\n"
+               "        strncpy(buffer,p->l_name,sizeof(buffer));\n"
+               "        char *tag = strrchr(buffer,'/');\n"
+               "        if (tag) {\n"
+               "            tag +=1;\n"
+               "            strcpy(tag,"%s");\n"
+               "        }\n"
+               "        \n"
+               "    }\n"
+               "\n"
+             "    __wine_dll_register( &nt_header, buffer );\n",
+             DLLName, DLLName, DLLFileName,DLLName );
     if (nr_debug)
         fprintf( outfile, "    debug_registration = __wine_dbg_register(
debug_channels, %d );\n",
                  nr_debug );

[Andreas Mohr]

On Tue, May 21, 2002 at 10:45:14AM -0400, [e-mail] 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.

[Alexandre Julliard]

[e-mail] writes:
> - 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?

Builtin dlls don't have a full path because there is no associated
file that we could point to (at least as seen from Windows). If this
breaks your app it can be changed, but I'm not sure it will really fix
anything. What does the app do with the filename?
> - I've attached the patch I'm using at the bottom of this message - can
>
> anyone think of a cleaner way of doing this?

You should not need to change the spec file at all. If you need a full
name you should prefix the name with the windows system directory at
load time.