Micha Nelissen micha@neli.hopto.org writes:
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.
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.
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.
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?
Thanks, Micha
Micha Nelissen micha@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.
On 27-11-13 09:46, Alexandre Julliard wrote:
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 don't know wine very well, but there is also wineboot, and I've also seen services.exe being started, and Run and RunServices from the registry, so it's about more than only wineserver.
Micha Nelissen micha@neli.hopto.org writes:
On 27-11-13 09:46, Alexandre Julliard wrote:
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 don't know wine very well, but there is also wineboot, and I've also seen services.exe being started, and Run and RunServices from the registry, so it's about more than only wineserver.
Sure, you just have to run some wine binary first, like winepath, to start all system processes with the stderr you want. That's easy to do with a simple shell alias.
The point is that getting diagnostics on stderr is a valuable tool for figuring out problems, and we cannot sacrifice that for the very uncommon case of running a script with redirected stderr. So any solution to this issue has to preserve the display of errors on stderr by default.
-
Alexandre Julliard -
Micha Nelissen