Currently, if a probe fails, it will print the line number of the [test]
block the probe is in, not the line number of the probe itself. This
makes it somewhat difficult to debug.
This commit makes it print the line number of the probe as well.
CC @zfigura
--
v2: tests: Print the line number of the probe when a test fails.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/499
Moving most systray code out of winex11, and removing the need for a custom export in winemac. Maybe winemac could use that new interface as well but I didn't want to mess with it too much.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4540
This is the third (and last) part of the Wayland driver Vulkan subseries:
1. Implement `vkQueuePresentKHR` and support reporting `VK_ERROR_OUT_OF_DATE_KHR` and `VK_ERROR_SURFACE_LOST_KHR`.
2. Misc. enhancements/fixes to ensure the subsurface containing the vulkan rendering is displayed properly.
3. Implement a couple of remaining Vulkan functions.
With this MR you can start enjoying some of your games with the Wayland driver (either directly with Vulkan or with a D3D->Vulkan translation). Please note, however, that we don't currently support what's needed for mouselook (you will currently get erratic view movement), so most first-person 3D games are not playable yet.
Thanks!
--
v2: winewayland.drv: Implement vkGetPhysicalDevicePresentRectanglesKHR.
winewayland.drv: Implement vkGetDeviceGroupSurfacePresentModesKHR.
winewayland.drv: Apply client subsurface position on creation.
winewayland.drv: Ensure Vulkan parent surface is mapped with proper size.
winewayland.drv: Detect and report vkQueuePresentKHR errors.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522
Fixes periodic crashes in PowerPoint 365
--
v11: d2d1: Acquire lock before attempt to draw to device context
d2d1: Add test for singlethreaded draw
d2d1: Add test for multithreaded draw
https://gitlab.winehq.org/wine/wine/-/merge_requests/4452
This allows initializing locale from Mac locale identifiers like
'zh-Hans-US'. The current implementation recognizes it as 'zh-US'
which isn't a valid locale identifier for Windows.
This patch will try again with the 'lang-script' identifier after
get_win_locale() fails with the 'lang-region' identifier.
--
v5: ntdll: Try harder to fallback to neutral locales.
ntdll: Initialize locale from Mac language identifiers with script name.
ntdll: Use different variable names for Mac locales.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4357
GCC 13 thinks that there is a use-after-free here and warns about it. We
actually don't need to check the return value of realloc here at all
because shrinking an allocation is guaranteed to succeed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4530
When running wineserver under valgrind there is a bunch of uninitialised bytes warnings when sending the req_get_mapping_info reply.
This warning can easily be reproduced by running `valgrind wineserver -f` and then `winecfg`.
Tested using self compiled wine.
Reason is the `pe_image_info_t` struct having bitfields:
```
unsigned char contains_code : 1;
unsigned char wine_builtin : 1;
unsigned char wine_fakedll : 1;
```
The last 5 bits are never initialized. This MR fixes this by zeroing the entire struct before it is filled.
I hope "issues" like this are allowed to be fixed so valgrind has less false positives.
Valgrind message for reference:
```
==628662== 716 errors in context 3 of 3:
==628662== Syscall param writev(vector[1]) points to uninitialised byte(s)
==628662== at 0x49C3A87: writev (writev.c:26)
==628662== by 0x14C2F3: send_reply (request.c:268)
==628662== by 0x14C50F: call_req_handler (request.c:316)
==628662== by 0x14C5D2: read_request (request.c:339)
==628662== by 0x158F52: thread_poll_event (thread.c:388)
==628662== by 0x120FC9: fd_poll_event (fd.c:505)
==628662== by 0x1212A6: main_loop_epoll (fd.c:599)
==628662== by 0x121882: main_loop (fd.c:955)
==628662== by 0x12CBE0: main (main.c:238)
==628662== Address 0x53ec56e is 62 bytes inside a block of size 88 alloc'd
==628662== at 0x48416D4: malloc (vg_replace_malloc.c:431)
==628662== by 0x1348D0: mem_alloc (object.c:119)
==628662== by 0x14BEB9: set_reply_data_size (request.c:160)
==628662== by 0x1301C1: req_get_mapping_info (mapping.c:1291)
==628662== by 0x14C494: call_req_handler (request.c:305)
==628662== by 0x14C5D2: read_request (request.c:339)
==628662== by 0x158F52: thread_poll_event (thread.c:388)
==628662== by 0x120FC9: fd_poll_event (fd.c:505)
==628662== by 0x1212A6: main_loop_epoll (fd.c:599)
==628662== by 0x121882: main_loop (fd.c:955)
==628662== by 0x12CBE0: main (main.c:238)
==628662== Uninitialised value was created by a client request
==628662== at 0x134873: mark_block_uninitialized (object.c:110)
==628662== by 0x1348EA: mem_alloc (object.c:120)
==628662== by 0x134B87: alloc_object (object.c:199)
==628662== by 0x134F92: create_named_object (object.c:337)
==628662== by 0x12F12B: create_mapping (mapping.c:939)
==628662== by 0x12FFE9: req_create_mapping (mapping.c:1250)
==628662== by 0x14C494: call_req_handler (request.c:305)
==628662== by 0x14C5D2: read_request (request.c:339)
==628662== by 0x158F52: thread_poll_event (thread.c:388)
==628662== by 0x120FC9: fd_poll_event (fd.c:505)
==628662== by 0x1212A6: main_loop_epoll (fd.c:599)
==628662== by 0x121882: main_loop (fd.c:955)
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4414
Visual Studio's native tool command prompt uses rare for loop variables: %%1, %%2. This test covers this case.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55401
--
v2: * cmd: added support of FOR loop's rare var names (%%1), fixed expansion of outer var loop name inside inner loop
cmd: added support of for loop's rare var names (%%1), fixed expansion of outer var loop name inside inner loop
cmd: added test for rare for loop vars
https://gitlab.winehq.org/wine/wine/-/merge_requests/4504
On Mon Nov 27 20:57:03 2023 +0000, Jacek Caban wrote:
> My guess is that you wouldn't be able to reproduce that with JS. If
> that's the case, then web pages can't depend on that (otherwise we'd
> have a way to crash web browser from JS).
Do you mean crash on native? I mean it's known to be full of bugs and security exploits, to the point of becoming a meme. I could test it if I can use it from JS (actually, can't event handlers still be called after navigation on the old doc/window?), because it would be a silent "failure" or event not firing which would be insanely hard to debug otherwise, especially since you can see event handlers are registered and all. And "if it works on Windows it must be correct" that devs usually think of.
I wouldn't mind trying to test this out, even if it doesn't end up as proper wine tests, I just don't want it to be a waste of time, like it feels right now, even though I was expecting matching native behavior (and fixing potential memory hazards) to be a goal.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4380#note_54096
On Tue Nov 28 14:17:15 2023 +0000, Jacek Caban wrote:
> > As for the "hide problems in the future", I actually think the exact
> opposite. Right now, we use the document's outer_window in same way,
> except it's completely broken and can access invalid memory if the outer
> window happens to die, which would be very hard to debug (especially
> considering most apps using mshtml are bloated and slow with millions of frameworks).
> Yes, it would be nice to fix that. One fix for that is to simply reset
> the pointer to NULL. My understanding is that the actual reason we can't
> do that is iframe navigation test and we already know that the test
> works because on native, the document interface doesn't change. So what
> you do is essentially working around that problem, not fixing it.
Resetting the point to NULL is the same as using the `doc->window->base.outer_window`, which has potential for a lot more regressions (I don't mean the test). How is that better?!?
I don't know why you think this is so risky; as mentioned in the MR's message, those are the only things that would be affected, and they're all either fixed or handled (handled means same behavior as before). I spent time carefully reviewing them, I'd like that not to be a waste and just dismissed like that.
Sure I might have missed some, but it's pretty unlikely. I also tested real world apps and it seemed fine. I was hoping a review to "double check" it would provide the extra eyes on it, instead of being dismissed, even though it's correct.
Also another argument for it is that, since I suspect it will have to be fixed properly at some point, the sooner we do it, the easier it will be to review, which is now. The more complicated mshtml becomes (necessarily, to implement new features), the harder it will be to revamp this. Why not do it now?
It just seems to me that you dismiss it because of potential regressions without actually analyzing what could cause them at all, since my goal with this patch and the MR message was definitely to keep same behavior as before *except* in places where I fixed it (and mentioned in the message). *If* that's not the case everywhere I'd like to know, too, but I did carefully review it. Would you please reconsider?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4380#note_54095
This is some preparatory work for vulkan child window and other features which currently live in Proton. I think this could be upstream already, and it will make rebasing patches on top of it simpler. To get vulkan child window upstream we'd probably still need to rework it a bit and maybe try to move the wait and blit to `vkQueuePresent` somehow.
The idea here is also that although Vulkan spec does not allow multiple active swapchains for the same window, Windows tends to allow it especially with D3D, and we also need to support the case where multiple APIs are use to draw onto the same window surface (as we implement D3D on top of GL/Vk for instance).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4533
On Tue Nov 28 11:16:55 2023 +0000, Haoyang Chen wrote:
> Hi,this patch introduces new problems in locales where UNICODE is used.
> Because str single byte \0 does not necessarily terminate the string,
> and thus a stack overflow occurs. And I am using a chinese local set.
> I still found it to be -1 in Windows.
I don't understand the comment. Please create a bug so we can move the discussion there.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4415#note_54074
Hi,this patch introduces new problems in locales where UNICODE is used. Because str single byte \0 does not necessarily terminate the string, and thus a stack overflow occurs. And I am using a chinese local set.
I still found it to be -1 in Windows.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4415#note_54069
This allows initializing locale from Mac locale identifiers like
'zh-Hans-US'. The current implementation recognizes it as 'zh-US'
which isn't a valid locale identifier for Windows.
This patch will try again with the 'lang-script' identifier after
get_win_locale() fails with the 'lang-region' identifier.
--
v4: ntdll/unix: Try harder to fallback to neutral locales.
ntdll/unix: Support to initialize locale from Mac language identifiers with script name.
ntdll/unix: Use different variable names for Mac locales.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4357
--
v2: wined3d: Set d3d 1-9 textures in the state as SRVs.
d3d9: Use wined3d_texture_acquire_identity_srv().
wined3d: Introduce an API for creating an identity SRV on a texture.
wined3d: Release the view's resource after destroying the view.
wined3d: Explicitly bind 0 for a NULL SRV.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4436
Some distros arbitrary flags into clang config files without guarding it for applicable targets, which breaks cross compilation.
--
v3: winegcc: Support --no-default-config argument.
configure: Use --no-default-config option on clang when available.
configure: Fix action-if-no handling in WINE_TRY_PE_CFLAGS macro.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4492
Currently, if a probe fails, it will print the line number of the [test]
block the probe is in, not the line number of the probe itself. This
makes it somewhat difficult to debug.
This commit makes it print the line number of the probe as well.
CC @zfigura
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/499
On Mon Nov 27 20:35:08 2023 +0000, Gabriel Ivăncescu wrote:
> Yeah. As I said below, I can easily just get rid of the tests and do the
> right thing with a comment. Silently dropping events sounds like a bad
> idea to me, it will make it hard to debug if something broken ever
> depends on it. And it's not like it's more code, either, so better make
> it correct.
My guess is that you wouldn't be able to reproduce that with JS. If that's the case, then web pages can't depend on that (otherwise we'd have a way to crash web browser from JS).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4380#note_53978
> As for the "hide problems in the future", I actually think the exact opposite. Right now, we use the document's outer_window in same way, except it's completely broken and can access invalid memory if the outer window happens to die, which would be very hard to debug (especially considering most apps using mshtml are bloated and slow with millions of frameworks).
Yes, it would be nice to fix that. One fix for that is to simply reset the pointer to NULL. My understanding is that the actual reason we can't do that is iframe navigation test and we already know that the test works because on native, the document interface doesn't change. So what you do is essentially working around that problem, not fixing it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4380#note_53977
On Mon Nov 27 17:34:03 2023 +0000, Jacek Caban wrote:
> This should really use `!iface_cmp()` to make sure it's not one more
> instance of wrappers that native uses in similar places. However, trying
> to do that crashes on native, which is just one more reason to believe
> that detached documents are broken there and trying too hard to mimic it
> does not make sense. I think that you're misinterpreting some quirks
> that are not really interested in the first place. I suggest to drop
> those tests and just do the right thing: don't send any events on
> detached document, maybe even fail early on an attempt to use such storage.
Yeah. As I said below, I can easily just get rid of the tests and do the right thing with a comment. Silently dropping events sounds like a bad idea to me, it will make it hard to debug if something broken ever depends on it. And it's not like it's more code, either, so better make it correct.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4380#note_53976
And of course the gitlab subscription reply doesn't work via email…
Well that's why I wanted it before code freeze, so any possible regressions are detected now. Isn't that the point?
For storage events, yeah I can easily get rid of the test and just keep the current "correct" behavior with a comment. I'd rather keep that than silently drop events (or even if it's logged, it's not that obvious), because that's 1) incorrect and 2) it's extremely hard to debug if something broken ever depends on it. Plus, it's not like sending the events is extra code than silently dropping them, most of the patch is in the tests.
As for the "hide problems in the future", I actually think the exact opposite. Right now, we use the document's outer_window in same way, except it's completely broken and can access invalid memory if the outer window happens to die, which would be very hard to debug (especially considering most apps using mshtml are bloated and slow with millions of frameworks).
What problem would this hide? The things that *are* different than before (e.g. parentWindow), are tested so they're fixed and correct, with the others being same as before, except not randomly crashing in some cases.
Maybe it's not by itself a strong argument, but outer_window on document is now just simply broken and I'd like to fix that before the code freeze.
Another reason is that such things would also be very hard to figure out if something even depends on (lack of events especially if it's corner case like this). Considering it also fixes a broken reference from outer_window that's completely arbitrary right now, I think that's reasonable enough.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4380#note_53975