On WOW64, Nt calls expect a 64-bit IO_STATUS_BLOCK with .Pointer pointing to the 32-bit IOSB. When Nt calls are made from the unix side we need to initialize the pointer to NULL to, at least, discard the IOSB results and avoid invalid writes.
There's the same problem in wineandroid.drv `android_ioctl`, but it is more complicated. The IOSB result is actually read, so instead of a NULL pointer it will need to point to a 32-bit IOSB, and to check whether the process is WOW64 or not when reading the result.
It's more complicated and I preferred to not make the change. Note that anything that needs the IOSB result from the unix side will face the same problem, and it would maybe be nice to have a general solution.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2333
Revert "server: Don't invalidate the newly exposed child region on the parent if it doesn't clip children."
This reverts commit 33617af8145b6fadfe41d48968a728ff57b3064b.
Apparently, the aforementioned commit might cause the expose region to
be incorrectly computed when a window transitions from invisible state
to visible state.
The commit also had caused regression in the following apps:
- Wine regedit.exe (bug 54268)
- Dn-FamiTracker (bug 52903)
- Unity Assets Bundle Extractor (same cause behind bug 52903)
It appears that the commit catalyzes discovery of hidden bugs in Wine's
window repaint logic. It's also possible that the algorithm for
computing the expose region is incomplete.
For these reasons, revert this commit for now.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54268
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52903
--
v2: Revert "server: Don't invalidate the newly exposed child region on the parent if it doesn't clip children."
https://gitlab.winehq.org/wine/wine/-/merge_requests/2342
This fixes various problems I've run into while trying to use Fusion 360 in wine.
- stacking issues in unmanaged mode
- I also attempted to apply the same fix for managed mode, but it looks difficult to do this in a way that plays well with window managers; I think it's best left up to them to keep override_redirect windows at the top of the stack)
- when the window manager sets our state to withdrawn, tell the window that it's been minimized, since the semantics are very similar
- the last one is a hack because I don't really know what to do about it, when clicking on the floating popups, they gain focus, which causes wine to incorrectly make them managed and that breaks everything
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2343
Today, test_TxGetNaturalSize() creates a pop-up window with a fixed size
(extent) of 100 x 100. The test function then proceeds to compute the
natural size of rich edit control that fits the sample text
"TestSomeText" and compare it to the RECT calculated by DrawText.
It appears that this test fails if the text width exceeds the width of
the test window's client area. In this case, DrawText() with
DT_WORDBREAK breaks the text into the two lines due to text wrapping;
however, Rich Edit's ITextServices::TxGetNaturalSize implementation does
not seem to perform text wrapping on overflow. This results in extent
mismatch.
In conclusion, the test may fail if the rendered width of the sample
text "TestSomeText" is larger than what the test expects. This depends
on the current font used for DEFAULT_GUI_FONT.
Fix this by omitting the DT_WORDBREAK flag for the DrawText() call in
_check_txgetnaturalsize().
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54637
--
v2: riched20/tests: Don't specify DT_WORDBREAK in _check_txgetnaturalsize().
https://gitlab.winehq.org/wine/wine/-/merge_requests/2335
Today, test_TxGetNaturalSize() creates a pop-up window with a fixed size
(extent) of 100 x 100. The test function then proceeds to compute the
natural size of rich edit control that fits the sample text
"TestSomeText" and compare it to the RECT calculated by DrawText.
It appears that this test fails if the text width exceeds the width of
the test window's client area. In this case, DrawText() with
DT_WORDBREAK breaks the text into the two lines due to text wrapping;
however, Rich Edit's ITextServices::TxGetNaturalSize implementation does
not seem to perform text wrapping on overflow. This results in extent
mismatch.
In conclusion, the test may fail if the rendered width of the sample
text "TestSomeText" is larger than what the test expects. This depends
on the current font used for DEFAULT_GUI_FONT.
Fix this by omitting the DT_WORDBREAK flag for the DrawText() call in
_check_txgetnaturalsize().
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54637
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2335