Jukka Heinonen jhei@iki.fi writes:
MSDN documentation on Win32 version of LoadModule states that path should not be stripped but I'm not sure how Win16 version is supposed to work. It probably uses different search order if path is not present, anyway.
Yes, Win16 is somewhat different, the module path is stripped and only the base name is used when looking for an existing module. But of course we should only strip the full path after the file has been opened... this should fix it:
Index: dlls/kernel/ne_module.c =================================================================== RCS file: /home/winehq/opt/cvs-commit/wine/dlls/kernel/ne_module.c,v retrieving revision 1.5 diff -u -p -r1.5 ne_module.c --- dlls/kernel/ne_module.c 27 Aug 2003 03:16:56 -0000 1.5 +++ dlls/kernel/ne_module.c 30 Aug 2003 18:37:13 -0000 @@ -1162,22 +1162,23 @@ static HINSTANCE16 MODULE_LoadModule16( enum loadorder_type loadorder[LOADORDER_NTYPES]; int i; const char *filetype = ""; - const char *ptr; + const char *ptr, *basename;
/* strip path information */
- if (libname[0] && libname[1] == ':') libname += 2; /* strip drive specification */ - if ((ptr = strrchr( libname, '\' ))) libname = ptr + 1; - if ((ptr = strrchr( libname, '/' ))) libname = ptr + 1; + basename = libname; + if (basename[0] && basename[1] == ':') basename += 2; /* strip drive specification */ + if ((ptr = strrchr( basename, '\' ))) basename = ptr + 1; + if ((ptr = strrchr( basename, '/' ))) basename = ptr + 1;
- if (is_builtin_present(libname)) + if (is_builtin_present(basename)) { - TRACE( "forcing loadorder to builtin for %s\n", debugstr_a(libname) ); + TRACE( "forcing loadorder to builtin for %s\n", debugstr_a(basename) ); /* force builtin loadorder since the dll is already in memory */ loadorder[0] = LOADORDER_BI; loadorder[1] = LOADORDER_INVALID; } - else MODULE_GetLoadOrder(loadorder, libname, FALSE); + else MODULE_GetLoadOrder(loadorder, basename, FALSE);
for(i = 0; i < LOADORDER_NTYPES; i++) {