Daemonizing wine (fix for issue #15462)

Alexandre Julliard julliard at winehq.org
Wed Nov 27 02:46:54 CST 2013


Micha Nelissen <micha at neli.hopto.org> writes:

> On 26-11-13 19:29, Alexandre Julliard wrote:
>>> The patch creates a daemon.err logfile in the wine server dir
>>> (/tmp/.wine-XXX/YYY/), where the output of wineserver.exe,
>>> services.exe, and all other background processes go.
>>
>> I don't think that's a good idea. In the debugging case, you want all
>> the traces to go to the same place, and when displaying errors, no user
>> is ever going to see them in that file. Not to mention that the log file
>> is going to grow endlessly.
>
> Ok, do you have a counter proposal? Maybe use syslog, except if some
> debug flag is set? (but then how does this debug flag get into
> kernel32 etc?)
>
> Note that the current situation is also a bit strange, because the
> stderr of e.g. wineserver is directed to the first process it was
> started by. So... AFAICS, if process A and process B start, and B
> causes an error in wineserver (or services.exe or...) then the error
> is output on the stderr of process A.

You can always start the wineserver separately if you want to send its
output somewhere else. I don't think there's a need for an elaborate
mechanism for this.

>>> I've removed the inheritance of stdin/stdout/stderr in
>>> server/process.c (that took some time to find!) because in windows,
>>> either you set bInheritHandles to true with CreateProcess and you
>>> inherit stdin etc too, or you set it false, and you get nothing. So
>>> this patch should also increase winapi compatibility.
>>
>> This should be a separate patch, with test cases.
>
> Where can I look for testcases? Should it be in kernel32/tests/process.c?

Probably.

-- 
Alexandre Julliard
julliard at winehq.org



More information about the wine-devel mailing list