Since we're checking the child window clipping rules it is possible
that a toplevel window also has an onscreen client window, for instance
if the window wasn't created with WS_CLIPCHILDREN. The last window to
present between the parent and its children should be visible.
GDI blits always happen over the toplevel window, and we need to use
IncludeInferiors to make sure it goes through any onscreen client window
that is otherwise hiding the toplevel pixels.
It should be safe to use that flag wrt other child windows, as we also
set the clipping region to exclude the area that should be obscured by
any sibling.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57661
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7141
--
v3: server: When renaming, only fstat the source once.
server: Remove source when renaming to a hardlink of itself.
kernel32/tests: Test renaming a file into a hardlink of itself.
kernel32/tests: Use FindClose instead of CloseHandle when closing
https://gitlab.winehq.org/wine/wine/-/merge_requests/6855
When the window manager moves windows offscreen, the Win32 config is
explicitly kept out of sync. We need to handle that case when the Win32
config changes, to avoid forcefully moving the windows back on screen.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57652
Since 895ca2eda64f506b936999cdd8f14e224eef6a7f the window position might
be out of sync between Win32 and X if the X window manager has moved it
offscreen.
Then b936f7426e33508538f48f7d20e7d7cb47cc1f32 ignored size and position
changes, trying to avoid triggering requests that would force the X
window position to match the Win32 state.
However, the X visible rect might change on window style adjustments,
and not from a application-requested size change, and we need to request
these changes to the X server.
The SWP flags should be handled in win32u already and the window rect
position and size should not have changed if SWP_NOSIZE | SWP_NOMOVE
were set by the application.
What we need to do is to mind that the X window position might be out
of sync, and adjust the request to take the eventual offscreen position
into account.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7140
If `<arch>_CFLAGS`/`<arch>_LDFLAGS` are passed to configure they are ignored and replaced with the default flags. This prefers the user-provided flags if any, and falls back to `CROSSCFLAGS` / `CROSSLDLAGS` then to the default flags.
--
v2: configure: Use per-architecture cross flags if they are provided.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7139
On Sun Jan 12 20:25:27 2025 +0000, Nikolay Sivov wrote:
> Do we need this intersection check at all?
I believe we do. The code in `media_engine_transfer_d3d11` performs a `CopySubresourceRegion` directly to the application supplied texture, which only supports copy; it doesn't support any stretch. So `media_engine_transfer_d3d11` is used as an optimisation for when the application supplied texture has the same (or larger) dimensions as the output sample from the MF pipeline.
This check ensures we fallback when stretching is required. The fallback writes to a media engine supplied texture, that is then applied to a quad that can be stretched (before being written to the application texture).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7124#note_91816
For example, when GPU 1 has adapter 1 and GPU 2 has adapter 2, without this fix, the `adapter`
variable in the for loop is always zero when forming GDI display names \\.\DISPLAY* because these
two adapters are on different GPUs. Thus "\\.\DISPLAY1" is incorrectly passed to xrandr14_get_id()
for the second adapter and eventually gets the wrong current display mode for the second adapter.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57610
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7136
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57610
This is a simple workaround to fix the regression. The issue seems to be residing in inconsistent values returned by XRandR, and arguably a host driver bug, but it probably could be better fixed by enumerating the XRandR tree only on startup and when it is updated, but this would be a much larger change.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7126
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57610
This attempt to fix a regression which is caused by XRandR enumerated output/crtc changing during the display device initial enumeration.
The user setup uses an external display and somehow XRandR enumerates the first (non-primary) monitor and its mode without being able to find a primary output/crtc (and uses that first monitor position as primary as fallback). Then, when the second (primary) monitor and its modes are enumerated it actually finds it and uses its as it should. This results in both monitor modes being positioned at 0x0, which breaks various things later on.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7110
Function gets called with Magic == 0xdead, which causes the test to
use the 64-bit path, which results in this buffer overflow.
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7134
Jinoh Kang (@iamahuman) commented about server/thread.c:
> + {
> + struct wait_completion_packet *packet;
> +
> + LIST_FOR_EACH_ENTRY( packet, &obj->wait_completion_packet_queue, struct wait_completion_packet, entry )
> + {
> + list_remove( &packet->entry );
> + release_object( packet->target );
> + packet->in_object_packet_queue = 0;
> + packet->target = NULL;
> +
> + add_completion( packet->completion, packet->ckey, packet->cvalue, packet->status,
> + packet->information, packet );
> + packet->in_completion_queue = 1;
> + }
> + }
> +
General advice: you should try not to leak implementation details of certain object (wait completion packet) into other types of objects.
For example, if this piece of code is still to be preserved, you should move this into a helper completion.c, declare as extern in object.h (or file.h), and call that.
That way, you don't have to define the entire `struct wait_completion_packet` in a shared header file. If this were factored into a helper, a simple forward declaration would have sufficed in the `file.h` side.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6911#note_91785
Use the irql assigned by IoAcquireCancelSpinLock, not the
(yet-to-be-assigned) irp->CancelIrql.
This is for readability. No semantic change is expected with unmodified
ntoskrnl.exe/hal.dll.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7129
Use the irql assigned by IoAcquireCancelSpinLock, not the
(yet-to-be-assigned) irp->CancelIrql.
This is for readability. Since IoReleaseCancelSpinLock() ignores the
IRQL argument anyway, no semantic change is expected with unmodified
ntoskrnl.exe/hal.dll.
--
v2: ntoskrnl.exe: Fix IRQL mismatch between cancel spin lock acquire and release.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7129
On Sat Dec 21 08:41:22 2024 +0000, Anton Baskanov wrote:
> The correct way to fix this is to implement a custom allocator like it
> is done in the native AMDirectDrawStream. This will allow changing the
> format on the fly without stopping the stream. But it of course requires
> much more work, including adding format change support to decoders.
Thanks for the feedback! I started reading about dynamic format changing and dynamic reconnecting from your comment, so now I have a better idea on how to continue with this. :-)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7057#note_91771
The new job is only triggered when a developer manually starts it.
Before run, it initially appears as a "skipped" job when the pipeline
starts.
--
v3: tools: Add manual-run job for new-style wow64.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7108
Any time CanConvert returns FALSE for the output parameter,
also return an appropriate failing result code.
This also adds tests for CanConvert.
--
v3: windowscodecs: Make values returned from CanConvert consistent
https://gitlab.winehq.org/wine/wine/-/merge_requests/7091
No reviews required.\
This is just to get the test results as seen by gitlab.\
MR will be cancelled afterwards.
--
v5: secur32/tests: Update expected results for the new test.winehq.org server.
wininet/tests: Update certificate for the new test.winehq.org server.
dnsapi/tests: Update DNS names for the new test.winehq.org server.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7098
This fixes the hang mentioned in https://bugs.winehq.org/show_bug.cgi?id=57632 introduced by e6b8e9ee20937f12dbf19145a9f2ca1ca3364da3. That bug also mentions the radio being silent, that's unrelated to the hang should probably be a separate bug.
--
v2: quartz/dsoundrender: Restart the render thread when clearing EOS in dsound_render_sink_end_flush().
https://gitlab.winehq.org/wine/wine/-/merge_requests/7122
--
v3: crypt32: Favour CERT_CHAIN_POLICY_IGNORE_WRONG_USAGE_FLAG in verify_ssl_policy().
crypt32: Only mind end certificate when checking revocation status in verify_ssl_policy().
crypt32: Favour CERT_CHAIN_POLICY_IGNORE_END_REV_UNKNOWN_FLAG in verify_ssl_policy().
crypt32: Check CERT_TRUST_REVOCATION_STATUS_UNKNOWN instead of CERT_TRUST_IS_OFFLINE_REVOCATION in verify_ssl_policy().
crypt32: Fix some error codes in verify_ssl_policy().
crypt32/tests: Add more tests for VerifyCertChainPolicy().
https://gitlab.winehq.org/wine/wine/-/merge_requests/7117
--
v2: crypt32: Favour CERT_CHAIN_POLICY_IGNORE_WRONG_USAGE_FLAG in verify_ssl_policy().
crypt32: Only mind end certificate when checking revocation status in verify_ssl_policy().
crypt32: Favour CERT_CHAIN_POLICY_IGNORE_END_REV_UNKNOWN_FLAG in verify_ssl_policy().
crypt32: Check CERT_TRUST_REVOCATION_STATUS_UNKNOWN instead of CERT_TRUST_IS_OFFLINE_REVOCATION in verify_ssl_policy().
crypt32: Fix some error codes in verify_ssl_policy().
crypt32/tests: Add more tests for VerifyCertChainPolicy().
https://gitlab.winehq.org/wine/wine/-/merge_requests/7117
International Rally Championship executes cli on startup and sti on
exit, this currently crashes as an exception is thrown and isn't handled
by the game.
The ntdll:exception tests show that an exception is thrown on x86_64,
i386 and WOW64 mode, however the game also runs fine when executed in a
Windows 10 64bit VM (with 640x480 16bpp compatibility mode). It crashes
when run in a Windows 8 32bit VM, so possibly something WOW64 related
swallows the exception.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57381
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7113
No reviews required.\
This is just to get the test results as seen by gitlab.\
MR will be cancelled afterwards.
--
v4: winhttp: Always return result at once if available in WinHttpReadData().
winhttp: Always return result at once if available in WinHttpQueryDataAvailable().
user32/tests: Fix some sysparams results on recent Windows.
user32/tests: Fix cursoricon tests on recent Windows versions.
urlmon/tests: Skip test if ftp connection fails.
crypt32/tests: Fix a test failure.
wininet: Parse multi-token Connection strings for Keep-Alive.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7098
On Wed Jan 8 18:15:02 2025 +0000, Francis De Brabandere wrote:
> @jacek split up and don't think any of the test failures is related.
> What's up with all these flaky tests anyway?
Yeah, our CI is not perfect. No need to worry if they are not related to your changes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7049#note_91661
Any time CanConvert returns FALSE for the output parameter,
also return an appropriate failing result code.
This also adds tests for CanConvert.
--
v2: windowscodecs: Make values returned from CanConvert consistent
https://gitlab.winehq.org/wine/wine/-/merge_requests/7091
No reviews required.\
This is just to get the test results as seen by gitlab.\
MR will be cancelled afterwards.
--
v3: wininet/tests: Update issuer check for winehq.org certificate.
user32/tests: Add flaky_wine to some SetActiveWindow tests.
urlmon/tests: Expect "Upgrade, Keep-Alive" connection string.
urlmon/tests: Fix a test that fails after WineHQ updates.
secur32/tests: Mark some test results as broken on old Windows versions.
imm32/tests: Add todo_himc to some ImmTranslateMessage expected calls.
dnsapi/tests: Update tests for winehq.org DNS changes.
gitlab: Do not run the build script on each commit.
gitlab: Remove make -j options.
gitlab: Update configuration for the new Mac runner.
gitlab: Add 'build' tag on Linux build jobs.
secur32/tests: Update the tests to expect HTTP/2 headers.
secur32/tests: Update count for new winehq.org certificate.
secur32/tests: Switch to TLS 1.2 for connections to test.winehq.org.
secur32: Handle GNUTLS_MAC_AEAD.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7098
work is still in progress.
todo:
- ensure that all affected sources (i.e. C sources with any kind of assembly) are listed in either way for all architectures
- test Wine built with LTO
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7111
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57076
I don't know if this is how native does it, but it makes intuitive sense to me that if we have a glyph in the requested font, we should use it, and this fixes the bug in question. This should avoid the possibility of regression in cases where font linking isn't needed. There is a possibility of regression in corner cases handled better by the earlier version of font linking.
--
v3: gdiplus: Use font linking only for missing glyphs.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7054
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57076
I don't know if this is how native does it, but it makes intuitive sense to me that if we have a glyph in the requested font, we should use it, and this fixes the bug in question. This should avoid the possibility of regression in cases where font linking isn't needed. There is a possibility of regression in corner cases handled better by the earlier version of font linking.
--
v2: gdiplus: Use font linking only for missing glyphs.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7054
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57076
I don't know if this is how native does it, but it makes intuitive sense to me that if we have a glyph in the requested font, we should use it, and this fixes the bug in question. This should avoid the possibility of regression in cases where font linking isn't needed. There is a possibility of regression in corner cases handled better by the earlier version of font linking.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7054
After the change to move the sync_gl_drawable call outside the win_data mutex in 54d82ed4, the X11 client rect used for determining whether we need to composite/clip the drawable can be out of sync with the win32 side. This would result in offscreening when unnecessary and vice-versa.
--
v3: winex11: Use the win32 client rect in needs_client_window_clipping.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7106