The graphics driver information is stored as a property in the desktop window. When the server
get_desktop_window handler simply returns a window handle when the window station is invisible,
the window handle doesn't have the graphics driver property, which is set in desktop_window_proc()
when handling WM_NCCREATE. Removing the invisible window station check allows an invisible explorer
desktop window to be created and with the required property.
In order to implement FILE_DISPOSITION_POSIX_SEMANTICS, it will be necessary
to add additional flags to closed_fd. In preparation for this, the unlink
member variable has been replaced with disp_flags which directly reflects the
flags defined in the FILE_DISPOSITION_INFORMATION_EX structure.
Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>
The FILE_DELETE_ON_CLOSE can be used with the FILE_DISPOSITION_ON_CLOSE flag
of FileDispositionInformationEx.
Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>
When applying a new cursor clipping rect, or to the previous foreground
thread when foreground changes, to notify it of the cursor clipping rect
being reset.
Code is duplicated in ntdll.dll (for 32bit only and old Wow configuration)
and wow64.dll for new Wow64 configurations.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
This patch addresses an issue in Second Life and potentially other
multi-threaded applications which process WM_KEYDOWN in one thread
and then verify that the key is "still down" with GetAsyncKeyState
from another thread. Wine uses a per-thread key cache, resulting
in inconsistent views of key status. Caches are now invalidated
when an input event is injected by the driver or via SendInput.
Because of padding at the end of the struct, sizeof(*view) is greater
than offsetof(struct memory_view, name[0]). Change the allocation to
overallocate slightly instead of underallocating slightly.
Let conhost handle ctrl-\ instead of Unix tty, and pretend it's a
ctrl-pause/break key stroke. This allows CUI application in processed
input mode not to close upon ctrl-\.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54141
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Note: this patch should be extended by adding insertion
of the CTRL_BREAK_EVENT into processes' crtl handler
(as it's done for CTRL_C_EVENT).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Skip redrawing the composited child window when the window rect and
visible region stays the same, since we're taking the union of the old
and new visible regions.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53153
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
foobar2000.exe's UPnP Media Renderer component (foo_out_upnp.dll)
expects that, if a select() call completes successfully with a non-empty
writefds set, any immediately following send() call on a socket in the
writefds set never fails with WSAEWOULDBLOCK.
On Wine, the Winsock select() and send() implementations both call the
Unix poll(2) under the hood to test if I/O is possible on the socket.
As it turns out, it's entirely possible that Linux poll() may yield
POLLOUT on the first call (by select) but *not* the second (by send),
even if no send() call has been made in the meanwhile.
On Linux (as of v5.19), a connected (ESTABLISHED) TCP socket that has
not been shut down indicates (E)POLLOUT only if the ratio of
sk_wmem_queued (the amount of bytes queued in the send buffer) to
sk_sndbuf (the size of send buffer size itself, which can be retrieved
via SO_SNDBUF) is below a certain threshold. Therefore, a falling edge
in POLLOUT can be triggered due to a number of reasons:
1. TCP fragmentation. Once a TCP packet is split out from a larger
sk_buff, it incurs extra bookkeeping overhead (e.g. sk_buff header)
that is counted in sk_wmem_queued alongside application data.
See also: tcp_fragment(), tso_fragment() (Linux 5.19).
2. Control packets (e.g. MTU probing). Such packets share the same
buffer with application-initiated packets, and thus counted in
sk_wmem_queued.
See also: sk_wmem_queued_add() callers (Linux 5.19).
3. Memory pressure. This causes sk_sndbuf to shrink.
See also: sk_stream_moderate_sndbuf() callers (Linux 5.19).
Fix this by always attempting synchronous I/O first if req->force_async
is unset and the nonblocking flag is set.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53486
In multiple cases errors may be reported only once by the host socket
implementation, but should persist for Windows sockets. These cases are
currently not handled by poll_socket().
poll_socket() also does not include logic for filtering out events when asyncs
are queued or alerted on the relevant socket.
Hence, instead of duplicating more logic, remove the logic already duplicated,
and just call sock_poll_event(), so that there is one central place where events
are translated.
Mark the currently active poll async with a special "pending" field so that
poll_socket() does not attempt to complete it before all sockets are checked.
This reverts commit 24b64534e5.
We no longer perform any blocking waits on the client side, so shutdown() is no
longer necessary.
Moreover, shutting down is not always correct. Under some conditions, closing a
TCP socket should trigger RST without FIN (namely, when SO_LINGER is on but has
a zero timeout). By reverting this commit we match Windows behaviour in this
respect.
Also, replace the token user with the token owner for the default DACL
as well. Wine currently selects domain_users_sid as the token owner, so
use that. This is required to pass the advapi32:security test which
expects the security descriptor owner SID to be referenced in the DACL
as well.
.NET 6's HTTP/Socket code queries this. Winsock allows getsockname
on the AcceptEx AcceptSocket, but only if SO_UPDATE_ACCEPT_CONTEXT
is set.
Signed-off-by: David Curtiss <david.curtiss@ni.com>
Otherwise socket error may be cleared in poll_socket causing ioctl SO_ERROR calls to return no error.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51433
Signed-off-by: Piotr Caban <piotr@codeweavers.com>
We will always call set_fd_events() again in sock_reselect().
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Asyncs which are alerted but not "waiting" may still fill the pipe, and we
shouldn't signal AFD_POLL_WRITE in that case.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Asyncs which are alerted but not "waiting" may still consume all data, and we
shouldn't signal AFD_POLL_READ or AFD_POLL_OOB in that case.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is validated by tests introduced in
59beffb46c etc. This commit alone doesn't fix said
tests, because:
* on this poll, we will alert the waiting async;
* when reselecting, we will still request POLLIN, because the AFD_POLL_READ
request is still active,
* when POLLIN is subsequently signaled, we do not remove it in
sock_dispatch_asyncs(), because we check async_waiting(), not async_queued().
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The 'status' field of send_socket_request is always either
STATUS_PENDING or STATUS_DEVICE_NOT_READY, and the 'total' field is
always zero.
Replace the 'status' field with 'force_async' boolean field, and get rid
of the 'total' field entirely.
Also, clean up the send_socket handler code a bit.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If the type of the socket is SOCK_DGRAM, it shall always be bound to an
address if we ever attempt to send datagrams through the socket, whether
the attempt succeeds or not.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Make send_socket alert the async immediately if poll() call detects that
there are incoming data in the socket, bypassing the wineserver's main
polling loop.
For sock_transmit, we always mark the async as pending and set the IOSB
(unless async allocation has failed).
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This allows the initial I/O to be performed after the send_socket
handler is called.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This also makes async_handoff() behaviour more consistent with
async_set_result() for handling I/O failures.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Today, async_set_completion_callback() is used to register a function
that is called when the async I/O is completed. It is assumed that the
async will eventually be queued when such callback is registered.
However, this incurs extra complexity in future code that needs the
completion logic to be invoked even if the async is never actually
queued (e.g. when the I/O failed synchronously before async_handoff).
Generalise async completion callback by calling it in async_handoff()
when the I/O status indicates failure.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The client can set mark_pending to indicate that the full-blown I/O
completion mechanism shall be triggered (asynchronous completion) even
if the status indicates failure.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Shift the resposibility of setting initial status from
set_async_direct_result request handler to async_set_result().
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Commit 15483b1a12 (server: Allow calling async_handoff() with status
code STATUS_ALERTED., 2022-02-10) introduced the set_async_direct_result
handler which calls async_set_initial_status().
However, the async_set_initial_status() call does nothing since
async->terminated is set, leaving the async in a confusing state
(unknown_status = 1 but pending/completed).
So far, this issue is unlikely to have been a problem in practice for
the following reasons:
1. async_set_initial_status() would have unset unknown_status, but it
remains set instead. This is usually not a problem, since
unknown_status is usually ever read by code paths effectively
unreachable for non-device (e.g. socket) asyncs.
It would still potentially allow set_async_direct_result to be called
multiple times, but it wouldn't actually happen in practice unless
something goes wrong.
2. async_set_initial_status() would have set initial_status; however,
it is left with the default value STATUS_PENDING. If the actual
status is something other than that, the handler closes the wait
handle and async_satisfied (the only real consumer of initial_status)
would never be called anyway.
For reasons above, this issue is not effectively observable or testable.
Nonetheless, the current code does leave the async object in an
inconsistent state.
Fix this by removing the !async->terminated check in
async_set_initial_status().
Also, remove assert( async->unknown_status ). The client can now
trigger the assert() by calling set_async_direct_result on a device
async, thereby causing async_set_initial_status() to be called twice.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The 'status' field of recv_socket_request is always either
STATUS_PENDING or STATUS_DEVICE_NOT_READY, and the 'total' field is
always zero.
Replace the 'status' field with 'force_async' boolean field, and get rid
of the 'total' field entirely.
Also, clean up the recv_socket handler code a bit.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Make recv_socket alert the async immediately if poll() call detects that
there are incoming data in the socket, bypassing the wineserver's main
polling loop.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If the server detects that an I/O request could be completed immediately
(e.g. the socket to read from already has incoming data), it can now
return STATUS_ALERTED to allow opportunistic synchronous I/O. The Unix
side will then attempt to perform I/O in nonblocking mode and report
back the I/O status to the server via the new server request
"set_async_direct_result". If the operation returns e.g. EAGAIN
or EWOULDBLOCK, the client can opt to either abandon the request (by
specifying an error status) or poll for it in the server as usual (by
waiting on the wait handle).
Without such mechanism in place, the client cannot safely perform
immediately satiable I/O operations synchronously, since it can
potentially conflict with other pending I/O operations that have already
been queued.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fixes a regression introduced by
5c009c17b3.
For IPV6 socket already bound with bind() with IPV6_V6ONLY set to 0
the address returned by getsockname() may change after it is connected
to a IPV4 peer (e. g., from :: to ::ffff:192.0.2.128).
The effect of blamed commit is that before that Unix getsockname()
was called for each ws2_32 getsockname() and after the commit the
socket name is cached at bind and connect.
Signed-off-by: Paul Gofman <pgofman@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
So that the client allocates a larger receive buffer when needed and not
trigger the assert below when setting the reply message data.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Ideally we should be using sock_get_poll_events() and sock_poll_event() instead,
but that seems like an overly risky change for this late in code freeze.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51442
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Otherwise, async_waiting() returns 0, leading the socket object to
believe that the previous async request has not yet been acknowledged.
This results in I/O hang for subsequent reads (until shutdown).
Also, async_destroy() calls async_reselect() only after removing the
async request from the queue. Make async_set_result() consistent with
this behaviour.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52332
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We especially may want to support x86 on ARM, where long double is not an 80-bit
type.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some PE executables (like mingw's gdb port) just do something like:
- WaitForSingleObject(GetStdHandle(STD_INPUT_HANDLE), INFINITE) and hang
for ever (the read operations are done *after* the wait operation
succeeds)
(of course, the real wait operation is more complex, but the problematic
part boils down to that)
This hangs for ever because conhost's main input thread hasn't been started
yet.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Today, Wine uses NtQueryInformationProcess/ProcessDebugPort to detect
whether the current process is being debugged. If it is, the process
issues a breakpoint to yield control to the debugger.
Some debuggers (e.g. latest CDB) appear to create debug handles with
restricted DACL, which causes querying debug port to fail with
STATUS_ACCESS_DENIED. This results in the debuggee erroneously
skipping the initial breakpoint.
Fix this by not requiring DEBUG_ALL_ACCESS when opening the debug port
object. Instead, use MAXIMUM_ALLOWED for the access mask.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52184
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>