try following locations for wineserver directory:
- `${XDG_RUNTIME_DIR}/wine`
- `/run/user/${uid}/wine`
- `${TMPDIR}/wine` - only if `${TMPDIR}` is owned by user
- `${TMPDIR}/.wine-${uid}`
- `/tmp/.wine-${uid}`
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=39013
Signed-off-by: Konstantin Demin <rockdrilla(a)gmail.com>
--
v4: server: Try isolate wineserver directory.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3381
try following locations for wineserver directory:
- `${XDG_RUNTIME_DIR}/wine`
- `/run/user/${uid}/wine`
- `${TMPDIR}/wine` - only if `${TMPDIR}` is owned by user
- `${TMPDIR}/.wine-${uid}`
- `/tmp/.wine-${uid}`
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=39013
Signed-off-by: Konstantin Demin <rockdrilla(a)gmail.com>
--
v3: server: Try isolate wineserver directory.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3381
The read and pread syscalls are permitted to return fewer bytes than requested (unlike the fread libc call which will only perform a short read on error or EOF). This is most likely to occur when binaries are located on slower filesystems (e.g. NFS or 9pfs)
ffab9d9 is a relatively recent regression here, but a lot of the code appears to be much older (e.g. the read call in 341b7dc)
In this MR I've focused on ntdll, but I see a lot of similar mishandling of the pread return value in `server/`. I will raise a bug as I don't intend to create a follow up MR at this time.
--
v2: ntdll: Correctly handle pread short reads
https://gitlab.winehq.org/wine/wine/-/merge_requests/3390
The read and pread syscalls are permitted to return fewer bytes than requested (unlike the fread libc call which will only perform a short read on error or EOF). This is most likely to occur when binaries are located on slower filesystems (e.g. NFS or 9pfs)
ffab9d9 is a relatively recent regression here, but a lot of the code appears to be much older (e.g. the read call in 341b7dc)
In this MR I've focused on ntdll, but I see a lot of similar mishandling of the pread return value in `server/`. I will raise a bug as I don't intend to create a follow up MR at this time.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3390
try following locations for wineserver directory:
- `${XDG_RUNTIME_DIR}/wine`
- `/run/user/${uid}/wine`
- `${TMPDIR}/wine` - only if `${TMPDIR}` is owned by user
- `${TMPDIR}/.wine-${uid}`
- `/tmp/.wine-${uid}`
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=39013
Signed-off-by: Konstantin Demin <rockdrilla(a)gmail.com>
--
v2: server: Avoid wineserver directory race.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3381
On Wed Jul 19 19:55:17 2023 +0000, Davide Beatrici wrote:
> The function declaration. For that reason I believe it's not worth
> removing the comment, as it's only going to increase the amount of
> changes in the commit/MR.
!3380
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3260#note_39797
I suspect the intent of this test was to verify that httpapi really doesn't bind
to that port. That HttpAddUrlToUrlGroup() fails implies this, but paranoia in a
case like this is rarely unwarranted.
However, this test cannot reliably succeed; some other operating system
component may open a TCP port in the meantime, and it appears that on Windows 10
this does in fact happen.
Since the goal of the test is just extra paranoia, I don't think it's worth
keeping.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55127
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3378
@jacek sorry I somehow missed your comment on the other MR
I'm not sure I like the patch as is...
- I wonder if kernelbase.CtrlRoutine should only be called for CUI programs... MSDN doc is as usual imprecise (it speaks about all descendants, and all descendants attached to the same console)
- quick test show that a GUI process isn't killed by GenerateConsoleCtrlEvent
+ tested parent + console, cp_flags=0 and pgid = parent's pgid
+ tested parent + console, cp_flags=detached + new group, pgid = child.id
=> it doesn't fully anwser whether CtrlRoutine is called or not for GUI
- it assumes pgid are inherited for gui (but we don't have proper tests AFAICT)
moreover it means that we'd want two different behaviors when receiving SIGINT (whether it's a genuine unix signal or one sent by the server if we follow the tests result above)
perhaps, the solution would be in the default_ctrl_handler to only terminate the program if attached to a console, or in the program group of a unix console
remark: Wine unix console is the sole case where launching a GUI program from command line doesn't return immediately to prompt (native & builtin cmd implementation only wait on CUI programs completion). But that's conform to unix behavior.
note: I'm not even sure tweeking with setsid whould be useful as anyway the unix console is in raw mode, so only conhost regenerates the signals
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3312#note_39749
CFI directives allow the context stored on the stack by raise_func_trampoline
to be used to unwind to any exception handlers as required when dispatching
an exception. As the dispatcher may change its input context in e.g.
BTCpuResetToConsistentState and these changes also need to be used when
unwinding make sure to pass this copy of the context to
KiUserExceptionDispatcher as opposed to the copy initially stored on the stack,
which is not taken into account when unwinding.
--
v2: ntdll: Avoid storing a second ctx copy in the aarch64 raise trampoline
ntdll: Add aarch64 DWARF register definitions.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3365
What about my suggestion from !3290? Something like the attached [patch](/uploads/86c669e3c725b4f009338e80379552f4/patch.diff) should make it work, but we'd probably need some adjustments to `setsid` heuristics as well.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3312#note_39734
rebased in order to get rid of error of compilation on mac
failure on amstream is still present: looks like a generic issue when exiting gstreamer in 32bit (can repro locally without that MR applied)
@julliard need to do something else?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3312#note_39733
CFI directives allow the context stored on the stack by raise_func_trampoline
to be used to unwind to any exception handlers as required when dispatching
an exception. As the dispatcher may change its input context in e.g.
BTCpuResetToConsistentState and these changes also need to be used when
unwinding make sure to pass this copy of the context to
KiUserExceptionDispatcher as opposed to the copy initially stored on the stack,
which is not taken into account when unwinding.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3365