Lionel Ulmer wrote:
On Thu, Oct 27, 2005 at 04:17:17PM -0500, Alex Villacís Lasso wrote:
The page says that you have a patch that fixes something. Is that the
issue about the executable path name, or the one about the game refusing
to go past the splash screen, or the one about the mouse cursor?
It's only fixing the mouse cursor issue.
Lionel
This is a patch to fix the primary bug on DungeonKeeper. I am surprised
this bug was overlooked up to 0.9, since this is such a basic
characteristic of Windows.
The basic problem is that Wine is passing the argv[] array unmodified
(except for the removal of the 'wine' reference itself) to the PE
process. This means that, unless the user writes a DOS-style path at
wine invocation, the PE process receives an UNIX-style relative path as
its argv[0]. This differs from standard behavior in MS-DOS and Windows,
where the argv[0] of the process contains a fully qualified DOS-style
path (such as C:\WINDOWS\FOO.EXE) regardless of the method used to run
the executable. DungeonKeeper relies on this characteristic of
MS-DOS/Windows and crashes when it sees the UNIX-style path.
This patch will also be sent to wine-patches, as a fix for one of the
issues of bug 3542.
Note that the patch, as it stands, only fixes PE executables. Winelib
applications continue to receive an UNIX-style path. I don't really know
whether this is the right thing to do, but winelib apps surely know that
they are running in an Unix environment, so they know how to deal with
an Unix-style argv[0]. However, this poses the question of how to write
a test for this bug, since all tests are winelib applications.
BTW, could you please post the mouse-cursor issue patch? I also have a
Japanese RPG for which the mouse cursor gets stuck at the center of the
window, and I think that problem and the one in DungeonKeeper might be
one and the same.
Changelog:
* Force a copy of the fully-qualified DOS-style executable path into
argv[0] of the current PE process.
--- wine-0.9-cvs/dlls/kernel/process.c 2005-10-10 09:54:21.000000000 -0500
+++ wine-0.9-cvs-patch/dlls/kernel/process.c 2005-10-29 12:05:46.000000000 -0500
@@ -1066,7 +1066,26 @@
case BINARY_PE_EXE:
TRACE( "starting Win32 binary %s\n", debugstr_w(main_exe_name) );
if ((peb->ImageBaseAddress = load_pe_exe( main_exe_name, main_exe_file )))
+ {
+ /* Some Windows app rely on the fact that Windows (and MS-DOS) *always*
+ supply a fully qualified path to the executable file in argv[0].
+ That is, if program foo.exe is invoked as:
+ C:\WINDOWS> foo.exe
+ Process foo.exe expects to see:
+ argv[0] == "C:\WINDOWS\FOO.EXE"
+ Some programs rely on this, and fail in unexpected ways if they
+ see an UNIX-style relative path as their argv[0]. So the following
+ code replaces the program's argv[0] with a string to the fully-
+ qualified, DOS-style path.
+ */
+ int required_length;
+
+ required_length = WideCharToMultiByte( CP_UNIXCP, 0, main_exe_name, -1, NULL, 0, NULL, NULL );
+ __wine_main_argv[0] = RtlAllocateHeap( GetProcessHeap(), 0, required_length);
+ WideCharToMultiByte( CP_UNIXCP, 0, main_exe_name, -1, __wine_main_argv[0], required_length, NULL, NULL );
+
goto found;
+ }
MESSAGE( "wine: could not load %s as Win32 binary\n", debugstr_w(main_exe_name) );
ExitProcess(1);
case BINARY_PE_DLL:
