[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: process's name
From:       Andreas Mohr <a.mohr () mailto ! de>
Date:       2000-07-31 17:45:44
[Download RAW message or body]

On Tue, Jul 25, 2000 at 10:56:25PM +0400, Stas Sergeev wrote:
> Alexandre Julliard ?????:
> > Thanks for the trace, I see what the problem is now. Could you please
> > try this patch?
> > 
> > Index: loader/task.c
> Yes, this patch works perfectly (only together with the first one!).
> The problem is solved, thanks.

Hmm...
I think I have a problem that is quite related to this stuff...

SiSoft Sandra is a quite big system diag utility.
When launching "wine sandra.exe" in
/wine/Program Files/SiSoftware/SiSoft Sandra 2000 Standard
, sandra.exe does:
Call kernel32.728: WinExec(408d6944 "C:\\Program Files\\SiSoftware\\SiSoft Sandra \
2000 Standard\\san16.exe -",00000001) ret=00452670 fs=008f \
trace:module:CreateProcessA app '(null)' cmdline 'C:\Program Files\SiSoftware\SiSoft \
Sandra 2000 Standard\san16.exe -' , which fails (can't execute san16.exe).
At first I thought that the '-' at the end was the problem.
But it's much more.
I get:
trace:task:TASK_Create module='wine' cmdline='Files\SiSoftware\SiSoft Sandra 2000 \
Standard\san16.exe" -' task=017f The first problem here is (or rather was) that this \
TRACE() output has already been fixed by me:
    TRACE("module='%s' cmdline='%.*s' task=%04x\n", name, pTask->pdb.cmdLine[0], \
pTask->pdb.cmdLine+1, hTask ); Previously it's been
    TRACE("module='%s' cmdline='%.*s' task=%04x\n", name, *cmdLine, cmdLine+1, hTask \
); , which is wrong as we did cmdline++; before in order to get rid of the module
name in the cmdline.

The second problem here is of course the module name "wine", which seems to
be caused by an always problematic (as already indicated at length
in this thread):
      /* Copy the module name */

    GetModuleName16( pModule->self, name, sizeof(name) );
in TASK_Create().
And the third (!) problem is that the directory doesn't get evaluated as
it should (the spaces are hitting us hard again).
This has to be caught by a similar approach as in
loader/module.c/get_file_name() for getting the executable, I think.

How to solve the whole mess ?

I really can't believe what I see.
I.e. three bugs in that code !!

san16.exe is a win16 binary, of course.
Newest CVS, of course.

Andreas Mohr


[prev in list] [next in list] [prev in thread] [next in thread]