It's not completely clear what exactly it was doing differently from win32u, but keeping the captions within the work area is probably fine for win32u, and de-duplicating this code is probably a good thing and makes later changes for DPI-based virtual display settings easier.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6462
## Summary
Tests for UrlFixupW and semi stub function implementaion.
## Test results
- Tests are 100% ok on my local WIN 10 pc. Wine test bot seems to be okay too.
- Wine tests on debian machine
| function type | result |
| ------ | ------ |
| stub | 0020:url: 69802 tests executed (0 marked as todo, 0 as flaky, **200** failures), 0 skipped. |
| semi stub| 0020:url: 69802 tests executed (0 marked as todo, 0 as flaky, **100** failures), 0 skipped. |
## Todos
For follow up merge request(s).
- [ ] Add more tests for priority investigation, who url scheme fix up is working on windows.
- [ ] Implement missing parts of fix up.
## Conclusion
Semi stub implementation is an improvement to the existing solution. A grep showed that wine internals do not call this function, therefore it should not introduce any new bugs. Windows applications using/relying on the function should now work better, if not they may reveal already existing bugs.
--
v6: shlwapi: fixup leading and trailing typos in UrlFixupW
shlwapi: check for colon in UrlFixupW
kernelbase: Restructure UrlFixupW()
shlwapi/tests: Add tests for UrlFixupW.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1825
After an X11 event handler queues messages to another thread, TRUE should be returned and eventually
propagated to X11DRV_ProcessEvents().
When FALSE is always returned in xrandr14_device_change_handler(), a possible hang can happen for
the desktop message queue as follows:
1. The explorer.exe calls GetMessageW() -> NtUserGetMessage() -> wait_objects() -> wait_message().
2. In wait_message(), user_driver->pProcessEvents() gets called in the desktop window thread to
handle RRNotify events and calls xrandr14_device_change_handler() -> display_mode_changed(FALSE)
-> send_message(get_desktop_window(), WM_DISPLAYCHANGE, ...) -> desktop_window_proc() ->
send_message_timeout() -> send_client_message() -> process_message() -> broadcast_message() ->
send_message_timeout() -> send_client_message() -> process_message() -> send_inter_thread_message()
-> wait_message_reply() -> a server set_queue_mask() with skip_wait being 1 -> wake_mask and
changed_mask are set to 0.
3. In wait_message(), user_driver->pProcessEvents() returns FALSE from xrandr14_device_change_handler().
So wait_message() continues to call NtWaitForMultipleObjects().
4. Now NtWaitForMultipleObjects() hangs for INFINITE timeout because wake_mask and changed_mask
for the message queue are set to 0 so the thread is not woke up.
The hang is sensitive to message ordering and only happens in this specific case so it's hard to
reproduce with tests. I believe some of the past test timeouts on TestBots can be attributed to this
bug.
--
v2: winex11.drv: Fix a possible desktop window message queue hang.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5890
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57343
This is what the Java JRE installer does:
- It calls MsiInstallProductW - this opens the msi read/write
- The msi runs installer.exe
- installer.exe tries to open the msi readonly
--
v2: msi: Make MsiInstallProductW open msi readonly
msi/tests: Add test for MsiOpenDatabaseA during MsiInstallProductA
https://gitlab.winehq.org/wine/wine/-/merge_requests/6760
These invalid formats are rejected when creating WIC render targets. Otherwise, Wine may create a WIC render target with an unsupported format and in turn, will make testing IsSupported() method difficult.
--
v3: d2d1: Test creating WIC bitmap render targets.
d2d1: Reject unsupported formats when creating WIC bitmap render targets.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1321