Stas Sergeev <[EMAIL PROTECTED]> writes:
> >No; there can be several 16-bit tasks running inside the same process,
> >so we cannot simply use the first task name as the process name. The
> OK, thanks for the explanation. But anyway, why argv[0]?
When Wine runs 16Bit programs, its own module name is its program
name, which kind of makes sense. However it might be problematic to
use a UNIX filename here, when other apps query the process name...
> >real bug is that GetModuleFileName16 should never be called without a
> >current 16-bit task. Could you try this patch instead?
> Of course I can. Unfortunately it doesn't work:(
The problem seems to be, that when Wine starts a new 16Bit task, it
loads the implicit linked libraries of the executable in the context
of the parent task (which is wine itself in this case). As a result,
GetModuleFileName16() will always give wrong results.
A possible solution would be, to call NE_InitProcess() from
TASK_CallToStart(), this function is executed in the context of the
child task. I just don't know, how to get the error codes of
NE_InitProcess() back to LoadModule16() without using a global
variable. Maybe you can have a look at this patch?
(There are also some cosmetic changes in the patch).
Greetings,
Peter
patchfile
--
Peter Ganten
[EMAIL PROTECTED]
