Okay, I will revert those specific tests.
Generating the PE binaries won't be such a problem, however generating patch data that works on a generated PE is a problem. This would require writing implementations for most of mspatchc in order to properly generate patch data. I'm curious how the original author of the mspatcha implementation @cmccarthy generated the patch data
Any help with this would be very valuable and appreciated. I am trying to fix a 15 year old bug report with these changes so that people can finally install software without the need for manually installing the native Microsoft mspatcha binary.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3870#note_48358
If _NET_WM_FULLSCREEN_MONITORS is set then the property needs to be updated because it can't
be deleted by sending a _NET_WM_FULLSCREEN_MONITORS client message to the root window
according to the wm-spec version 1.5. Having the window spanning more than two monitors also
needs the property set. In other cases, _NET_WM_FULLSCREEN_MONITORS doesn't need to be set.
What's more, setting _NET_WM_FULLSCREEN_MONITORS adds a constraint on Mutter so that such a
window can't be moved to another monitor by using the Shift+Super+Up/Down/Left/Right
shortcut. So the property should be added only when necessary.
--
v2: winex11.drv: Set _NET_WM_FULLSCREEN_MONITORS only when necessary.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4063
The failed 32bit tests are the following:
```
domdoc.c:2521: Test failed: Unexpected hr 0x1.
filtergraph.c:635: Test failed: Got hr 0x40242.
filtergraph.c:571: Test failed: Got hr 0x80004005.
speech.c:1386: Test failed: Wait for block_thread failed.
```
Unrelated to the patch + they've been failing all across different MRs here.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4065#note_48346
On Wed Oct 11 11:05:32 2023 +0000, Chip Davis wrote:
> According to [docs][1], `SetBrushOrgEx()` is supposed to affect the
> *next* brush that is selected into the device context. It might be
> interesting, then, to see what happens when a brush is selected into the
> DC after calling `SetBrushOrgEx()`.
> [1]: https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-setbru…
That's not reflected by EMF recording, and will need some rendering tests. It's best to have a bug report for that so it's not forgotten.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4058#note_48338
First part of the continuation of the implementation of non-constant offset dereferences (a.k.a. relative addressing) for SM4, now that we use vsir registers in tpf.c.
As a quick recap: while parsing HLSL we are expressing derefs as paths, and then we are lowering these paths into a single offset node (which is closer to the bytecode) using the replace_deref_path_with_offset() pass, right before register allocation.
This first part of the series splits this offset node into 2 parts:
- A constant uint, which will be called hlsl_deref.offset_const.
- A non-hlsl_ir_constant offset node that will only be present when we need relative addressing, that we will end up calling hlsl_deref.offset_rel.
Both these fields will be analog to the ones used in vsir register indexes, vkd3d_shader_register_index.rel_addr and vkd3d_shader_src_param.offset respectively, which is something we need for the second part of this series.
The following patches are in my [nonconst-offsets-8-part](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/n… branch, if something is not clear in this series, it may be worth skimming through them.
Supersedes !229.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/396