- wine-gitlab - winehq.org

Re: [PATCH v2 0/1] MR1064: wbemprox: Add HypervisorPresent property to win32_ComputerSystem. - approved
by Alexandre Julliard (＠julliard) 14 Oct '22

14 Oct '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1064

1 0

Re: [PATCH v2 0/1] MR1053: include: Add LV_COLUMN[AW]. - approved
by Alexandre Julliard (＠julliard) 14 Oct '22

14 Oct '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1053

1 0

Re: [PATCH v2 0/1] MR1056: win32u: Asynchronously send the WM_DISPLAYCHANGE to the desktop window. - approved
by Alexandre Julliard (＠julliard) 14 Oct '22

14 Oct '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1056

1 0

Re: [PATCH v2 0/1] MR1058: po: Update Finnish translation. - approved
by Alexandre Julliard (＠julliard) 14 Oct '22

14 Oct '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1058

1 0

[PATCH 0/5] MR1068: combase: CoMsgWaitForMultipleHandles
by Kevin Puetz (＠puetzk) 14 Oct '22

14 Oct '22

Some preliminary cleanups (split off from !969) - extend an existing `wine_todo` test to show that DDE messages cause spurious calls to IMessageFilter::MessagePending (the same as RPC ones) I have no current ideas for fixing this, just demonstrating the behavior (before refactoring the code in ways that won't change this) - extract a helper `com_filter_messagepending` for the interactions between `CoWaitForMultipleHandles` and IMessageFilter::MessagePending - Pull the remaining use of `PeekMessageW` into the existing `com_peek_message` helper - one behavior fix, to make `RPC_E_CALL_CANCELED` actually work -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1068

3 6

Re: [PATCH v5 0/5] MR944: win32u: Make desktop resize logic asynchronous.
by Alexandre Julliard (＠julliard) 14 Oct '22

14 Oct '22

On Fri Oct 14 12:45:38 2022 +0000, Rémi Bernon wrote: > I'm having a hard time reproducing it, is this with some specific tests? > The first commit indeed changes some behavior, where it was only > repositioning the current process windows before and is now > repositioning all windows from the desktop thread. > I suspect that it could be about the message being sent to the desktop, > which is now waiting for all windows to reposition by broadcasting a > message itself. If they aren't actively processing messages, it could > probably lock up. > I created https://gitlab.winehq.org/wine/wine/-/merge_requests/1056 to > address that issue, but I cannot confirm if it fixes anything. Other > than that I experienced some random and seldom crashes running > d3d9:device for instance, but I'm not sure to see how it's related. I reproduce it by running the full tests, `make testclean test -k` usually hangs somewhere in the d3d tests. !1056 seems to help. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/944#note_10781

1 0

[PATCH 0/1] MR1069: dxva2/tests: Add another render target format to fix a test failure.
by Nikolay Sivov (＠nsivov) 14 Oct '22

14 Oct '22

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1069

2 1

[PATCH 0/3] MR1067: jscript: Bind function 'thisArg' and JSON.parse improvements.
by Gabriel Ivăncescu (＠insn) 14 Oct '22

14 Oct '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1067

4 8

[PATCH 0/2] MR1059: winegstreamer: Implement AAC decoder MFT.
by Rémi Bernon (＠rbernon) 14 Oct '22

14 Oct '22

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47084 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1059

4 4

[PATCH 0/1] MR1043: wined3d: Use the supplied context in wined3d_device_context_blt().
by Henri Verbeet (＠hverbeet) 14 Oct '22

14 Oct '22

Applications calling wined3d_device_context_resolve_sub_resource() on a deferred context would instead get this scheduled on the immediate context. Worse, because the original call was intended for a deferred context, we'd do this without taking the mutex required for immediate contexts, potentially corrupting the command stream. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1043

4 3

[PATCH 0/1] MR1042: wined3d: Handle VKD3D_SHADER_RESOURCE_DATA_MIXED in wined3d_data_type_from_vkd3d().
by Henri Verbeet (＠hverbeet) 14 Oct '22

14 Oct '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1042

4 3

[PATCH 0/5] MR1032: comctl32: preparation for HPROPSHEETPAGE structure layout changes
by Piotr Caban (＠piotr) 14 Oct '22

14 Oct '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1032

5 8

[PATCH 0/4] MR30: hlsl: Texture and UAV loads.
by Zebediah Figura (＠zfigura) 14 Oct '22

14 Oct '22

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/30

5 7

[PATCH v9 0/4] MR23: shell32: Sanitize Program Manager icon and group names
by Alex Henrie (＠alexhenrie) 14 Oct '22

14 Oct '22

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52506 Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> -- v9: shell32: Sanitize Program Manager icon and group names. shell32: Introduce combine_path helper for DDE. shell32: Use standard C functions for memory allocation in dde.c. shell32: Move strndupW to dde.c. https://gitlab.winehq.org/wine/wine/-/merge_requests/23

4 7

Re: [PATCH v2 0/10] MR969: combase: CoMsgWaitForMultipleHandles message pump.
by Kevin Puetz (＠puetzk) 14 Oct '22

14 Oct '22

On Fri Oct 14 13:58:34 2022 +0000, Kevin Puetz wrote: > Looked at it some more and since I (already) gave up on trying to fix > the todo_wine about spurious calls to MessagePending, extracting that > much to a helper shouldn't be so bad. It was my (abandoned) theory about > how PeekMessage/QueueStatus should interact to suppress those unwanted > calls that made things so tangled together - and the didn't make the > conformance tests work any better, and it had nothing to do with the > actual application I was working on, so it got dropped. > The existing behavior (which this MR leaves alone) just needs an early > exit to return RPC_E_CALL_CANCELED. So I'll extract that helper too; > fixing IMessageFilter todo will probably have to revisit this, but we > can just preserve the status quo (and make things more readable) for > now. No need to borrow trouble from the future when I'm out of ideas and > not trying to tackle that anymore. Ok, opened !1068 to start with, with just some of the simpler changes that didn't involve the timeout/pumping behavior. This PR is now rebased on top of that, but marked draft and will can sit until we that first part landed so it gets smaller. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/969#note_10760

1 0

[PATCH 0/5] MR29: vkd3d-shader/hlsl: Support complex implicit casts, complex explicit casts and complex broadcasts. (PART 1/2)
by Francisco Casas (＠fcasas) 14 Oct '22

14 Oct '22

Hello, this is the first part of a patch series to support: * Complex broadcasts. * Complex implicit casts between component-wise equal types. * Complex explicit casts between component-wise compatible types. This first part of the series includes mostly tests. Following patches in: https://gitlab.winehq.org/fcasas/vkd3d/-/commits/complex_broadcasts_2/ This supersedes !16 . -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/29

4 7

[PATCH 0/1] MR1066: nsi: Update struct nsi_tcp_conn_dynamic for Windows 11.
by Huw Davies (＠huw) 14 Oct '22

14 Oct '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1066

3 2

[PATCH 0/1] MR1061: wbemprox: Add HyperVisorPresent property to win32_ComputerSystem.
by Louis Lenders (＠xe) 14 Oct '22

14 Oct '22

Native Access 2 queries for this property -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1061

5 5

[PATCH 0/1] MR1063: wbemprox: Add HypervisorPresent property to win32_ComputerSystem.
by Louis Lenders (＠xe) 14 Oct '22

14 Oct '22

Native Access 2 queries for this property -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1063

4 4

[PATCH 0/5] MR1035: oleaut32/tests: Use IMallocSpy to test VariantClear(VT_RECORD).
by Kevin Puetz (＠puetzk) 14 Oct '22

14 Oct '22

Salvage tests and fix a leak found in another review: see https://gitlab.winehq.org/wine/wine/-/merge_requests/897#note_9175 points 1 and 2. 3. is why !897 was reverted. This does not contain the (incorrect) changes to VariantCopyInd, but instead fixes the leak identified in VariantClear (VT_RECORD needs to free pvRecord), and the wrong allocator being used in VariantCopy (it should have been IMalloc, rather than `HeapAlloc`, as shown by the fact IMallocSpy observes these allocations). This also cleans up some dubious behavior by the test IRecordInfoImpl, which was modifying a VARIANT that it did not own or receive as an argument in the middle of VariantClear. This was likely undefined behavior, and in any case concealed the heap leak. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1035

4 10

Re: [PATCH v2 0/1] MR1065: ntdll: Add CFI unwind info to __wine_syscall_dispatcher (x86_64)
by Rémi Bernon (＠rbernon) 14 Oct '22

14 Oct '22

BTW, if the issue is only that the CFA is supposed to stay constant within a CFI procedure, would it work if we were splitting the dispatcher with some jumps / call / fake CFI procedures, at the points where we need to change its register? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10742

1 0

Re: [PATCH v2 0/1] MR1065: ntdll: Add CFI unwind info to __wine_syscall_dispatcher (x86_64)
by Rémi Bernon (＠rbernon) 14 Oct '22

14 Oct '22

> I guess the biggest issue with that change is, however, that it actually goes against what the DWARF spec. says about the CFA: >> Typically, the CFA is defined to be the value of the stack pointer at the call site in the previous frame (which may be different from its value on entry to the current frame). > > In particular, your change was unfortunately not working with our version of (libunwindstack)\[https://github.com/google/orbit/tree/main/third_party/libu… and LLDB (unfortunately not yet upstream). Yes, that's what I've been told (maybe even *you* did). > I am actually interested, does your change manage to unwind completely through the dispatcher and through the complete windows stack, as shown here? With GDB and with the two other changes I mentioned, it fully works yes. I'm a bit surprised that you don't need the flags push/pop change, as I believe it corrupts the return address on the stack, but maybe the unwinder has other ways to get it back. Now the other part where unwinding doesn't work well is with the other side of syscalls, with KiUserCallbackDispatcher callbacks. Massaging a bit the frame pointers before entering it I'm able to stitch the stack trace to the frame before entering the syscall but I'm then losing the stack within the syscall. I guess we'd probably need some assembly there too to add adequate CFI info if we want to get that right too. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10741

1 0

Re: [PATCH v2 0/1] MR1065: ntdll: Add CFI unwind info to __wine_syscall_dispatcher (x86_64)
by Florian Kübler (＠florian-kuebler) 14 Oct '22

14 Oct '22

>FWIW I'm achieving similar results in GDB with https://gitlab.winehq.org/rbernon/wine/-/commit/bf615abeb0c206e40678cec0583…. >As I've been told it's incorrect I didn't try upstreaming it further, but as far as I'm concerned GDB is fully happy with it, and combined with https://gitlab.winehq.org/rbernon/wine/-/commit/9e900267f6eacb8511e18ff2fc1… and https://gitlab.winehq.org/rbernon/wine/-/commit/e21cf3f7702837557f9cc221b20… it can unwind through the syscall dispatcher just fine. >Imho, this variant with the many macros is likely going to be considered as too complex for the small benefit (it's really only for the convenience of debugging Wine itself with a Unix debugger, which I completely agree, *is* useful, though mostly for developers). ---- Hey, I saw your change and would also have hoped that this actually works, as it is obviously much more elegant not fallback to the .cfi_escape primitives. I guess the biggest issue with that change is, however, that it actually goes against what the DWARF spec. says about the CFA: >Typically, the CFA is defined to be the value of the stack pointer at the call site in the previous frame (which may be different from its value on entry to the current frame). In particular, your change was unfortunately not working with our version of (libunwindstack)[https://github.com/google/orbit/tree/main/third_party/libun… and LLDB (unfortunately not yet upstream). I am actually interested, does your change manage to unwind completely through the dispatcher and through the complete windows stack, as shown here? ![mixed_callstack_unwinding](https://werat.dev/blog/how-wine-works-101/6.png) A note about the macros: I agree, they look horrible at the fist glance, but there are really just for readability. When you ignore those for a second, you actually only need to grasp the `__ASM_CFI_DW_OP_bregN` and `__ASM_CFI_DW_OP_deref` instructions, to get the computation of the registers and the CFA. Regarding the usefulness of that change, this is clearly for devs (not only wine directly, but e.g. also DXVK or similars). Also it is not only for debuggers, but also for profiling, to actually find performance problems in the syscalls. As the whole code here, is already very low level, I think this is actually also pretty helpful for people maintaining the syscall dispatcher, as you can, as said in the commit message, actually step through each instruction of the dispatcher with a debugger. So I really think it is worth the effort. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10740

1 0

Re: [PATCH v2 0/1] MR1065: ntdll: Add CFI unwind info to __wine_syscall_dispatcher (x86_64)
by Kevin Puetz (＠puetzk) 14 Oct '22

14 Oct '22

I haven't reviewed the actual changes here yet (and I'm not that knowledgeable on CFI either), but I would like to vote that this would be a huge quality-of-life improvement for us. When your app is also winelib (since it has dependencies on both win32 and other system ELF libraries), we almost exclusively end up debugging with a unix debugger, and the fact that backtraces almost always fail at `__wine_syscall_dispatcher` is a big pain. Using `gdb record` so we can rewind to see where the call came from helps, but can't help if all you have is a coredump. So this is would be greatly appreciated. Enough so that I had actually written myself a task to try and teach myself enough about DWARF well enough to try writing it :-) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10738

1 0

Re: [PATCH v2 0/1] MR1065: ntdll: Add CFI unwind info to __wine_syscall_dispatcher (x86_64)
by Rémi Bernon (＠rbernon) 14 Oct '22

14 Oct '22

FWIW I'm achieving similar results in GDB with https://gitlab.winehq.org/rbernon/wine/-/commit/bf615abeb0c206e40678cec0583…. As I've been told it's incorrect I didn't try upstreaming it further, but as far as I'm concerned GDB is fully happy with it, and combined with https://gitlab.winehq.org/rbernon/wine/-/commit/9e900267f6eacb8511e18ff2fc1… and https://gitlab.winehq.org/rbernon/wine/-/commit/e21cf3f7702837557f9cc221b20… it can unwind through the syscall dispatcher just fine. Imho, this variant with the many macros is likely going to be considered as too complex for the small benefit (it's really only for the convenience of debugging Wine itself with a Unix debugger, which I completely agree, *is* useful, though mostly for developers). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10733

1 0

2025

2024

2023

2022

wine-gitlab