- wine-gitlab - winehq.org

Re: [PATCH v10 0/4] MR23: shell32: Sanitize Program Manager icon and group names - approved
by Alexandre Julliard (＠julliard) 17 Oct '22

17 Oct '22

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

1 0

Re: [PATCH v3 0/3] MR1067: jscript: Bind function 'thisArg' and JSON.parse improvements. - approved
by Alexandre Julliard (＠julliard) 17 Oct '22

17 Oct '22

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

1 0

Re: [PATCH v2 0/6] MR1071: winedump: EMF spool files support - approved
by Alexandre Julliard (＠julliard) 17 Oct '22

17 Oct '22

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

1 0

Re: [PATCH v2 0/4] MR1076: opengl32: Cleanup extension disabling override in preparation for https://gitlab.winehq.org/wine/wine/-/merge_requests/1010. - approved
by Alexandre Julliard (＠julliard) 17 Oct '22

17 Oct '22

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

1 0

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

17 Oct '22

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

1 0

Re: [PATCH v6 0/4] MR47: kernel32/tests: Add tests for CancelSynchronousIo. - approved
by Alexandre Julliard (＠julliard) 17 Oct '22

17 Oct '22

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

1 0

Re: [PATCH v2 0/2] MR1073: Fix video flickering. - approved
by Alexandre Julliard (＠julliard) 17 Oct '22

17 Oct '22

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

1 0

Re: [PATCH v7 0/1] MR1024: xmllite/writer: Null terminate duplicated strings. - approved
by Alexandre Julliard (＠julliard) 17 Oct '22

17 Oct '22

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

1 0

Re: [PATCH v4 0/6] MR29: vkd3d-shader/hlsl: Support complex implicit casts, complex explicit casts and complex broadcasts. (PART 1/2) - approved
by Alexandre Julliard (＠julliard) 17 Oct '22

17 Oct '22

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

1 0

Re: [PATCH v2 0/1] MR31: tests: Add missing backslash to restore skipped tests. - approved
by Alexandre Julliard (＠julliard) 17 Oct '22

17 Oct '22

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

1 0

Re: [PATCH v2 0/6] MR28: Support length(), int division and int absolute value. - approved
by Alexandre Julliard (＠julliard) 17 Oct '22

17 Oct '22

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

1 0

Re: [PATCH v3 0/1] MR18: include: Use __MINGW_PRINTF_FORMAT when compiling with MinGW. - approved
by Alexandre Julliard (＠julliard) 17 Oct '22

17 Oct '22

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

1 0

[PATCH v3 0/1] MR1080: msvcrt: implement missing CRT functions to fix ChessBase 14 crash
by Bartosz Kosiorek (＠gang65) 17 Oct '22

17 Oct '22

With this commit the following functions were implemented: - _mbsupr_s_l - converts multibyte string to uppercase, by using specified locale that's passed in. - _mbslwr_s_l - converts multibyte string to lowercase, by using specified locale that's passed in. - _mbctolower_l - converts multibyte uppercase character to lowercase character, by using specified locale that's passed in. - _mbctoupper_l - converts multibyte lowercase character to uppercase character, by using specified locale that's passed in. More information about these methods are available at: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strupr-s-… After applying the patch the crash of the ChessBase application was fixed. More information: https://bugs.winehq.org/show_bug.cgi?id=45273 -- v3: msvcrt: implement missing CRT functions to fix ChessBase 14 crash https://gitlab.winehq.org/wine/wine/-/merge_requests/1080

3 2

[PATCH v2 0/1] MR1080: msvcrt: implement missing CRT functions to fix ChessBase 14 crash
by Bartosz Kosiorek (＠gang65) 17 Oct '22

17 Oct '22

With this commit the following functions were implemented: - _mbsupr_s_l - converts multibyte string to uppercase, by using specified locale that's passed in. - _mbslwr_s_l - converts multibyte string to lowercase, by using specified locale that's passed in. - _mbctolower_l - converts multibyte uppercase character to lowercase character, by using specified locale that's passed in. - _mbctoupper_l - converts multibyte lowercase character to uppercase character, by using specified locale that's passed in. More information about these methods are available at: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strupr-s-… After applying the patch the crash of the ChessBase application was fixed. More information: https://bugs.winehq.org/show_bug.cgi?id=45273 -- v2: msvcrt: implement missing CRT functions to fix ChessBase 14 crash https://gitlab.winehq.org/wine/wine/-/merge_requests/1080

3 2

[PATCH 0/1] MR1080: msvcrt: implement missing CRT functions to fix ChessBase 14 crash
by Bartosz Kosiorek (＠gang65) 17 Oct '22

17 Oct '22

With this commit the following functions were implemented: - _mbsupr_s_l - converts multibyte string to uppercase, by using specified locale that's passed in. - _mbslwr_s_l - converts multibyte string to lowercase, by using specified locale that's passed in. - _mbctolower_l - converts multibyte uppercase character to lowercase character, by using specified locale that's passed in. - _mbctoupper_l - converts multibyte lowercase character to uppercase character, by using specified locale that's passed in. More information about these methods are available at: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strupr-s-… After applying the patch the crash of the ChessBase application was fixed. More information: https://bugs.winehq.org/show_bug.cgi?id=45273 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1080

3 2

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

17 Oct '22

-- v2: vkd3d-shader/hlsl: Parse UAV types. vkd3d-shader/hlsl: Parse texture index expressions. vkd3d-shader/hlsl: Cast array indices inside of add_array_load(). tests: Add a basic shader test for typed UAV loads. tests: Add a basic shader test for compute shaders. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/30

3 13

[PATCH v2 0/4] MR1052: uiautomationcore: Initial patches for multi-provider HUIANODEs.
by Connor McAdams (＠cmcadams) 17 Oct '22

17 Oct '22

-- v2: uiautomationcore: Add support for getting HWND providers to uia_node_from_lresult(). uiautomationcore: Add support for getting HWND providers to UiaNodeFromProvider(). uiautomationcore: Determine provider type for nested node providers. uiautomationcore: Add support for multiple providers on a single HUIANODE. https://gitlab.winehq.org/wine/wine/-/merge_requests/1052

4 7

[PATCH v2 0/3] MR1070: Add more tests for \Device\NamedPipe, \Device\NamedPipe\, and exotic pipe names
by Jinoh Kang (＠iamahuman) 17 Oct '22

17 Oct '22

-- v2: ntdll/tests: Add more tests for \Device\NamedPipe and \Device\NamedPipe\. ntdll/tests: Add tests for exotic pipe names. kernel32/tests: Add test for pipe name with a trailing backslash. https://gitlab.winehq.org/wine/wine/-/merge_requests/1070

3 8

[PATCH 0/4] MR1046: MfMediaEngine audio and invalid format fix.
by Bernhard Kölbl (＠besentv) 17 Oct '22

17 Oct '22

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

7 44

[PATCH v3 0/3] MR1037: win32u: Add font link for MS UI Gothic.
by Ziqing Hui (＠zhui) 17 Oct '22

17 Oct '22

See this testbot result: https://testbot.winehq.org/JobDetails.pl?Key=124827&f101=exe32.report&f118=… Source code of the test program in the tests above is attached. [font_link_reg.c](/uploads/0f18bd2ab664e5d78ee2e16ef9037e60/font_link_reg.c) The tests show the reg key value of font link on different Windows machine, -- v3: win32u: Add more linked fonts for Tahoma. win32u: Add font link for MS UI Gothic. win32u: Add mechanism for font specific system links. https://gitlab.winehq.org/wine/wine/-/merge_requests/1037

4 5

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

17 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 . -- v3: tests: Test explicit casts between types that are component-wise tests: Test implicit casts between types that are equal component-wise. vkd3d-shader/hlsl: Always go through implicit conversion in assignments. tests: Test for invalid complex broadcasts. tests: Rename structs for readability in broadcast test. tests: Set ULPs to 2 in normalize() test. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/29

4 8

[PATCH 0/1] MR31: tests: Add missing backslash to restore skipped tests.
by Francisco Casas (＠fcasas) 17 Oct '22

17 Oct '22

Tests after this missing backslash are not being executed since e9829fdc6524e455f85893445ad8a2d703f02a2e. --- Thanks Giovanni for pointing this out. I am so sorry! -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/31

5 4

[PATCH 0/6] MR28: Support length(), int division and int absolute value.
by Giovanni Mascellani (＠giomasce) 17 Oct '22

17 Oct '22

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

4 8

[PATCH v2 0/1] MR18: include: Use __MINGW_PRINTF_FORMAT when compiling with MinGW.
by Zebediah Figura (＠zfigura) 17 Oct '22

17 Oct '22

The default for MinGW is always ms_printf rather than gnu_printf, but if we are using ucrtbase or ANSI stdio, we want gnu_printf. -- v2: include: Use __MINGW_PRINTF_FORMAT when compiling with MinGW. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/18

4 5

[PATCH v3 0/2] MR1030: Add stubs and tests for GetConsoleOriginalTitleA/W
by Hugh McMaster (＠hmc) 17 Oct '22

17 Oct '22

-- v3: kernel32/tests: Add tests for GetConsoleOriginalTitleA/W() kernelbase: Add stubs for GetConsoleOriginalTitleA/W() https://gitlab.winehq.org/wine/wine/-/merge_requests/1030

3 3

[PATCH 0/1] MR1077: kernel32/tests: Remove tests comparing expected output in certain functions
by Hugh McMaster (＠hmc) 17 Oct '22

17 Oct '22

The Windows versions of [Read|Write]ConsoleOutput[Attribute|Character] appear to assign an uninitialized internal DWORD to the given pointer address before returning. As the functions fail (intentionally) in these tests, the value of the DWORD is never set, so the tests end up comparing the expected value of zero with random values. This value of this test is very limited and is best removed. Fixes https://bugs.winehq.org/show_bug.cgi?id=53686 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1077

2 1

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

17 Oct '22

Rémi Bernon (@rbernon) commented about dlls/ntdll/unix/signal_x86_64.c: > "movq %gs:0x30,%rcx\n\t" > "movq 0x328(%rcx),%rcx\n\t" /* amd64_thread_data()->syscall_frame */ > "popq 0x70(%rcx)\n\t" /* frame->rip */ > + __ASM_CFI(".cfi_adjust_cfa_offset -8\n\t") > + // $rip = frame->rip // (*(0x70($rcx))) I understand the point but I don't think we need to keep these comments. We also don't use C++-style comments. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10939

1 0

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

17 Oct '22

Rémi Bernon (@rbernon) commented about dlls/ntdll/unix/signal_x86_64.c: > + > +#define __ASM_CFI_REG_IS_AT_OFFSET2_FROM_RCX(REG, OFFSET1, OFFSET2) \ > + __ASM_CFI_REG_IS_AT_OFFSET2_FROM_BREG(REG, __ASM_CFI_DW_OP_breg2, OFFSET1, OFFSET2) > + > +#define __ASM_CFI_REG_IS_AT_OFFSET1_FROM_RCX(REG, OFFSET) \ > + __ASM_CFI_REG_IS_AT_OFFSET1_FROM_BREG(REG, __ASM_CFI_DW_OP_breg2, OFFSET) > + > +#define __ASM_CFI_CFA_IS_AT_OFFSET_FROM_RBP(OFFSET) \ > + __ASM_CFI_CFA_IS_AT_OFFSET1_FROM_BREG(__ASM_CFI_DW_OP_breg6, OFFSET) > + > +#define __ASM_CFI_CFA_IS_AT_OFFSET_FROM_RSP(OFFSET) \ > + __ASM_CFI_CFA_IS_AT_OFFSET1_FROM_BREG(__ASM_CFI_DW_OP_breg7, OFFSET) > + > +#define __ASM_CFI_CFA_IS_AT_OFFSET_FROM_RCX(OFFSET1, OFFSET2) \ > + __ASM_CFI_CFA_IS_AT_OFFSET2_FROM_BREG(__ASM_CFI_DW_OP_breg2, OFFSET1, OFFSET2) > + What about something simpler like, 1) #define the `DW_` constants above in the file instead of the enums, and 2) re-use them here in the expressions, with something like: ```c #define DW_OP_rcx DW_OP_breg2 #define DW_OP_rbp DW_OP_breg6 #define DW_OP_rsp DW_OP_breg7 #define DW_REG_rbx 0x03 #define DW_REG_rsi 0x04 #define DW_REG_rdi 0x05 #define DW_REG_rbp 0x06 #define DW_REG_rsp 0x07 #define DW_REG_r12 0x0c #define DW_REG_r13 0x0d #define DW_REG_r14 0x0e #define DW_REG_r15 0x0f #define DW_REG_rip 0x10 #define __ASM_CFI_STR(...) #__VA_ARGS__ #define __ASM_CFI_ESC(...) __ASM_CFI(".cfi_escape " __ASM_CFI_STR(__VA_ARGS__) "\n\t") #define __ASM_CFI_CFA_IS_AT(base, lo, hi) __ASM_CFI_ESC(DW_CFA_def_cfa_expression, 0x04, DW_OP_ ## base, lo, hi, DW_OP_deref) #define __ASM_CFI_REG_IS_AT(reg, base, lo, hi) __ASM_CFI_ESC(DW_CFA_expression, DW_REG_ ## reg, 0x03, DW_OP_ ## base, lo, hi) ``` And use that below as `__ASM_CFI_CFA_IS_AT(rcx,0x88,0x01)`, `__ASM_CFI_REG_IS_AT(rip,rcx,0xf0,0x00)`, etc... I think using two bytes offsets everywhere simplifies the macros, although we'll need a bit more offset mangling by hand to encode them. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10938

1 0

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

17 Oct '22

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

4 9

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

17 Oct '22

>Yes, in my case I'm mostly only interested in the case with DWARF debug info in PE files. The applications I'm working with usually don't have debug information anyway and I'm trying to get stack traces and tooling support for Wine code specifically. Okay, yeah that makes a lot of sense now. Just to note that Windows "runtime function" unwind information was almost always available when we checked. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10931

1 0

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

17 Oct '22

> > FWIW this also works with Valgrind, and you might be interested in https://gitlab.winehq.org/wine/wine/-/merge_requests/1074 too. > > That is interesting. So, but do I see correctly that this only works, if the Windows Pe/Coff files, actually have **DWARF** unwind information embedded. Which is as far as I am aware only the case for cross-compilation with mingw, right? > > I should probably add that it only does that when it has the debug info for the PE modules, this isn't currently well supported, and needs to be done somehow manually. > > Are you referring to the Windows unwind information (runtime function), or the DWARF information mentioned above? Our LLDB patch (which we hopefully upstream soon), as well as the libunwindstack implementation actually takes care of all kind of PE/Coff modules, and is able to use runtime function as well, as DWARF information. Yes, in my case I'm mostly only interested in the case with DWARF debug info in PE files. The applications I'm working with usually don't have debug information anyway and I'm trying to get stack traces and tooling support for Wine code specifically. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10930

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) 17 Oct '22

17 Oct '22

>Hmm, I need to think about that. When I said it fully works, I should maybe indicate that GDB doesn't usually display local variables for the first frame below the syscall, so maybe it's because of this even though it manages to catch up for lower frames. As far as I remember, local variables were available in all frames in our case. It should be mostly because we specify callee-save registers right away when they get stored. Also it is likely, that if the computation in not correct in the first place, that it will catch up later, as there will be new unwind information mostly specifying "register foo is saved at that position on the stack". >FWIW this also works with Valgrind, and you might be interested in https://gitlab.winehq.org/wine/wine/-/merge_requests/1074 too. That is interesting. So, but do I see correctly that this only works, if the Windows Pe/Coff files, actually have **DWARF** unwind information embedded. Which is as far as I am aware only the case for cross-compilation with mingw, right? >It's not exactly the `pushfl` but more that the dispatcher pops `rip` first, which effectively removes the return address from the stack, then `pushfl` overrides its value. It's not causing problems later because the dispatcher uses the poped `rip` value to return to the caller, but it temporarily confuses GDB stack unwinding. Maybe with your CFI instructions it's not required. Right! And that is the reason why we don't need it, as we do specify "RIP" based on syscall frame and not based on CFA, right as it gets popped. I think that's another case, where it is actually better to do the `breg` instructions, as it gives you the freedom to specify some variables based on CFA and some based on register content. >The reason I've been told, is that some DRMs are checking that the NT syscalls didn't touch the stack. I don't really know more. Oh interesting. That makes a lot of sense, and our lives so much harder... :smile: >Yes, it's already an issue for `perf` captures when you want stack traces that cross user and kernel stacks, and I don't really have any good solution for that. Having an optional working mode which would interleave kernel frames and user frames may be possible but it doesn't seem much tractable. Yep, `perf` is actually using the same `perf_event_open` syscall that we are using. So it makes sense that we are observing the same issue. The "bruteforce" way we worked around with that, is to inject into the syscall dispatcher (using a uprobe) and always collect the "user-space" stack, then for the actual samples, make both stacks available to the unwinder. This obviously comes with a big performance hit, and might corrupt your performance characteristics. However, it actually turned out to be useful to find some issues. An alternative solution, that we never ended up actually implementing would be to use a eBPF program for the sampling/stack collection. We could make it copy both stacks explicitly. Obvious the more elegant solution would be, as you mentioned, to either have a switch in Wine to only have one stack, or alternatively, make it possible in perf_event_open, to collect both stacks. It would be be not the first time that Linux kernel has special handling for wine. >I should probably add that it only does that when it has the debug info for the PE modules, this isn't currently well supported, and needs to be done somehow manually. Are you referring to the Windows unwind information (runtime function), or the DWARF information mentioned above? Our LLDB patch (which we hopefully upstream soon), as well as the libunwindstack implementation actually takes care of all kind of PE/Coff modules, and is able to use runtime function as well, as DWARF information. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10929

1 0

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

17 Oct '22

> Ah, that is good to know, thanks. Apparently gdb's unwinder works slightly different, than the used we looked at. Also, I am surprised it actually can unwind Windows PE/Coff-based frames. I should probably add that it only does that when it has the debug info for the PE modules, this isn't currently well supported, and needs to be done somehow manually. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10927

1 0

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

17 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? > > My point is, that the issue is actually not about CFA not being constant, but that CFA has a semantic that many unwinding tools/libraries rely on, i.e. that CFA is suppose to be the value of the stack pointer at the caller, right before the call. In particular, CFA is suppose to be a value that would be a valid stack pointer. > > In your change, however, CFA gets later set to be a pointer into syscall_frame. Hmm, I need to think about that. When I said it fully works, I should maybe indicate that GDB doesn't usually display local variables for the first frame below the syscall, so maybe it's because of this even though it manages to catch up for lower frames. > > With GDB and with the two other changes I mentioned, it fully works yes. > > Ah, that is good to know, thanks. Apparently gdb's unwinder works slightly different, than the used we looked at. Also, I am surprised it actually can unwind Windows PE/Coff-based frames. FWIW this also works with Valgrind, and you might be interested in https://gitlab.winehq.org/wine/wine/-/merge_requests/1074 too. > > 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. > > Interesting. I am wondering why the `pushfl` instruction corrupts the return address. If this would be the case, wouldn't that not lead to actual runtime issues when the dispatcher returns? Maybe the reason why we don't see an issue with that, is that we are actually setting the CFI rule for the return address based on `syscall_frame` right away? It's not exactly the `pushfl` but more that the dispatcher pops `rip` first, which effectively removes the return address from the stack, then `pushfl` overrides its value. It's not causing problems later because the dispatcher uses the poped `rip` value to return to the caller, but it temporarily confuses GDB stack unwinding. Maybe with your CFI instructions it's not required. > > Yes, that's what I've been told (maybe even *you* did). > > No, that wasnt me :smile:, it's actually my first PR. Also note, that I am not a wine expert, so please forgive me, if I miss something obvious. Well, nothing in this area is obvious to me either. > > Now the other part where unwinding doesn't work well is with the other side of syscalls, with KiUserCallbackDispatcher callbacks. > > Unfortunately, I am not aware of the `KiUserCallbackDispatcher`. So I can't tell if there is more work to be done/how this could be fixed. > > We basically looked at reported unwinding errors in Orbit, and discovered the missing unwind info (CFI) being the root cause of most of them. With this, and some adjustments to our unwinder to cope with certain corner-cases of PE/Coff files, we ended up with less than 1% of unwinding errors. > > Actually, another issue that kept us quite busy is, that the `kernel_stack` is not allocated on the "normal"/"user" stack. That apparently used to be the case before Wine 7. This way, Linux performance collector tools, such as perf_event_open, fail to collect the "user-space" part of the stack. For debugging this is fine, as the program execution is halted and we can just read the data from memory, but for Profiling, we needed to massively work around that. Does someone know about the reason for the two separated stacks? Would it be maybe possible, to actually allocate that "kernel_stack" at the normal stack? The reason I've been told, is that some DRMs are checking that the NT syscalls didn't touch the stack. I don't really know more. Yes, it's already an issue for `perf` captures when you want stack traces that cross user and kernel stacks, and I don't really have any good solution for that. Having an optional working mode which would interleave kernel frames and user frames may be possible but it doesn't seem much tractable. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10925

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) 17 Oct '22

17 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? My point is, that the issue is actually not about CFA not being constant, but that CFA has a semantic that many unwinding tools/libraries rely on, i.e. that CFA is suppose to be the value of the stack pointer at the caller, right before the call. In particular, CFA is suppose to be a value that would be a valid stack pointer. In your change, however, CFA gets later set to be a pointer into syscall_frame. >With GDB and with the two other changes I mentioned, it fully works yes. Ah, that is good to know, thanks. Apparently gdb's unwinder works slightly different, than the used we looked at. Also, I am surprised it actually can unwind Windows PE/Coff-based frames. >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. Interesting. I am wondering why the `pushfl` instruction corrupts the return address. If this would be the case, wouldn't that not lead to actual runtime issues when the dispatcher returns? Maybe the reason why we don't see an issue with that, is that we are actually setting the CFI rule for the return address based on `syscall_frame` right away? >Yes, that's what I've been told (maybe even *you* did). No, that wasnt me :smile:, it's actually my first PR. Also note, that I am not a wine expert, so please forgive me, if I miss something obvious. >Now the other part where unwinding doesn't work well is with the other side of syscalls, with KiUserCallbackDispatcher callbacks. Unfortunately, I am not aware of the `KiUserCallbackDispatcher`. So I can't tell if there is more work to be done/how this could be fixed. We basically looked at reported unwinding errors in Orbit, and discovered the missing unwind info (CFI) being the root cause of most of them. With this, and some adjustments to our unwinder to cope with certain corner-cases of PE/Coff files, we ended up with less than 1% of unwinding errors. Actually, another issue that kept us quite busy is, that the `kernel_stack` is not allocated on the "normal"/"user" stack. That apparently used to be the case before Wine 7. This way, Linux performance collector tools, such as perf_event_open, fail to collect the "user-space" part of the stack. For debugging this is fine, as the program execution is halted and we can just read the data from memory, but for Profiling, we needed to massively work around that. Does someone know about the reason for the two separated stacks? Would it be maybe possible, to actually allocate that "kernel_stack" at the normal stack? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10922

1 0

[PATCH 0/4] MR1076: opengl32: Cleanup extension disabling override in preparation for https://gitlab.winehq.org/wine/wine/-/merge_requests/1010.
by Rémi Bernon (＠rbernon) 17 Oct '22

17 Oct '22

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

3 5

[PATCH 0/13] MR1074: Draft: ntdll: Improve Valgrind and GDB integration.
by Rémi Bernon (＠rbernon) 17 Oct '22

17 Oct '22

Valgrind support requires a fork, which I've published to https://gitlab.winehq.org/rbernon/valgrind. The fork implements loading DWARF debug info from PE files, instead of the old and broken upstream PDB support. I've tried to upstream these changes a long time ago but didn't receive any feedback. I think we could maybe consider keeping a fork, which I'm happy to maintain, as the changes aren't too large. We may want to investigate adding 32-on-64 support, which may require a bit more changes (to VEX specifically, because its amd64 guest doesn't support segment register manipulation). The changes here are not all related to Valgrind, and I'll create separate MR for those which may make sense independently from Valgrind / GDB. Also included is a suppression file to silent some annoying false positives, many of which are coming from the cross-stack accesses during syscalls, which are confusing Valgrind's stack heuristics. One can try this out with something like: `WINELOADERNOEXEC=1 valgrind --suppressions=tools/valgrind.supp wine64/loader/wine64 wine64/programs/winecfg/winecfg.exe` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1074

5 32

[PATCH 0/1] MR1075: include: Add TOOLINFO[AW].
by Alex Henrie (＠alexhenrie) 17 Oct '22

17 Oct '22

Needed to compile Tera Term. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1075

3 2

[PATCH 0/2] MR1073: Fix video flickering.
by Akihiro Sagawa (＠sgwaki) 17 Oct '22

17 Oct '22

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

4 4

[PATCH 0/1] MR1002: win32u: Fix data race in NtUserGetProcessDpiAwarenessContext.
by Jinoh Kang (＠iamahuman) 16 Oct '22

16 Oct '22

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

5 9

[PATCH v3 0/1] MR363: user32/tests: Test for window exposure behaviours.
by Jinoh Kang (＠iamahuman) 16 Oct '22

16 Oct '22

Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com> -- v3: user32/tests: Test for window exposure behaviours. https://gitlab.winehq.org/wine/wine/-/merge_requests/363

3 3

[PATCH 0/4] MR1052: uiautomationcore: Initial patches for multi-provider HUIANODEs.
by Connor McAdams (＠cmcadams) 16 Oct '22

16 Oct '22

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

4 8

[PATCH v6 0/1] MR1024: xmllite/writer: Null terminate duplicated strings.
by David Kahurani (＠kahurani) 16 Oct '22

16 Oct '22

Currently, the code copies one extra character than requested and does not terminate the string. Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v6: xmllite/writer: Null terminate duplicated strings. https://gitlab.winehq.org/wine/wine/-/merge_requests/1024

4 4

[PATCH 0/6] MR1071: winedump: EMF spool files support
by Piotr Caban (＠piotr) 15 Oct '22

15 Oct '22

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

3 7

[PATCH v2 0/1] MR363: user32/tests: Test for window exposure behaviours.
by Jinoh Kang (＠iamahuman) 15 Oct '22

15 Oct '22

Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com> -- v2: user32/tests: Test for window exposure behaviours. https://gitlab.winehq.org/wine/wine/-/merge_requests/363

3 2

[PATCH v5 0/1] MR1024: xmllite/writer: Null terminate duplicated strings.
by David Kahurani (＠kahurani) 15 Oct '22

15 Oct '22

Currently, the code copies one extra character than requested and does not terminate the string. Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v5: xmllite/writer: Null terminate duplicated strings https://gitlab.winehq.org/wine/wine/-/merge_requests/1024

3 2

[PATCH v2 0/1] MR74: ntdll: Prevent double free (Coverity)
by Fabian Maurer (＠DarkShadow44) 15 Oct '22

15 Oct '22

The fd gets overwritten, therefore we need to close it before doing so. Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> --- Supersedes patch 233975 -- v2: ntdll: Prevent double free (Coverity) https://gitlab.winehq.org/wine/wine/-/merge_requests/74

4 8

[PATCH v4 0/1] MR1024: xmllite/writer: Null terminate duplicated strings.
by David Kahurani (＠kahurani) 15 Oct '22

15 Oct '22

Currently, the code copies one extra character than requested and does not terminate the string. Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v4: xmllite/writer: Null terminate duplicated strings https://gitlab.winehq.org/wine/wine/-/merge_requests/1024

3 2

[PATCH v3 0/1] MR1024: xmllite/writer: Null terminate duplicated strings.
by David Kahurani (＠kahurani) 15 Oct '22

15 Oct '22

Currently, the code copies one extra character than requested and does not terminate the string. Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v3: xmllite/writer: strings are not being "partially duplicated", but duplicated with explicit length https://gitlab.winehq.org/wine/wine/-/merge_requests/1024

4 3

[PATCH v2 0/46] MR1010: Draft: opengl32: Path towards wow64 support.
by Rémi Bernon (＠rbernon) 15 Oct '22

15 Oct '22

I was watching some random YouTube stream and then heard a voice telling me to do this. This can run wglgears on wow, though there's plenty of missing pieces which I don't have any idea how to fix (like buffer mapping, etc.). Opening it as a draft for now to show the whole thing, if it seems alright I'll send it in batches. -- v2: opengl32: Implement wow64 thunks for glMapBuffer (et al.). opengl32: Use manual win32 thunks for glMapBuffer (et al.). opengl32: Implement wow64 thunks for GLsizeiptr/GLintptr arrays. opengl32: Implement wow64 thunks for glFenceSync (et al.). opengl32: Implement wow64 thunks for input pointer arrays. opengl32: Implement wow64 thunk for wglGetPbufferDCARB. opengl32: Implement wow64 thunk for wglCreatePbufferARB. opengl32: Implement wow64 thunk for wglCreateContextAttribsARB. opengl32: Implement wow64 thunk for wglMakeCurrent (et al.). opengl32: Implement wow64 thunk for glGetString (et al.). opengl32: Implement wow64 thunk for wglGetProcAddress. opengl32: Generate stub wow64 params mapping. opengl32: Manually write glPathGlyphIndexRangeNV wow64 thunk. opengl32: Generate wow64 thunks. opengl32: Use RtlSetLastWin32Error instead of SetLastError. opengl32: Use msvcrt allocation functions. opengl32: Build with msvcrt. opengl32: Avoid recursively entering WGL critical section. opengl32: Use glReserved1 to keep draw and read DCs. opengl32: Move get_current_context_type to private.h. opengl32: Use NtCurrentTeb()->glCurrentRC instead of get_current_context_ptr. opengl32: Use glReserved1[0] and glReserved1[1] for disabled extensions. opengl32: Use the unixlib interface to check for extensions. opengl32: Use the unixlib interface in glGetStringi. opengl32: Use the unixlib interface in wglGetProcAddress. opengl32: Split opengl_ext.h into private.h and unix_private.h. opengl32: Avoid calling back the wglMakeCurrent win32 thunk. opengl32: Use the unixlib interface for more WGL functions. opengl32: Move some WGL functions to unix_wgl.c. opengl32: Introduce a new NtUserCallOpenGLDebugMessageCallback callback. opengl32: Avoid using internal functions in wglUseFontOutlines. opengl32: Avoid using internal functions in wglUseFontBitmaps. opengl32: Use the unixlib for wglSwapBuffers. opengl32: Use the unixlib for wglGetPixelFormat. opengl32: Use the unixlib for wglDescribePixelFormat. opengl32: Use the unixlib for wglSetPixelFormat. opengl32: Use the unixlib interface for WGL functions. opengl32: Use the unixlib interface for EXT functions. opengl32: Move the null functions to unix_thunks.c. opengl32: Use the unixlib for glGet(String|Integerv). opengl32: Warn about unixlib calls failures in Win32 thunks. opengl32: Create a unixlib interface for GL functions. opengl32: Use has_extension in filter_extensions_index. opengl32: Move filter_extensions (et al.) around. opengl32: Build extension list in is_extension_supported. opengl32: Split is_extension_supported helper. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/1010

1 1

[PATCH 0/1] MR1054: gdi32: Prevent out of bounds array access
by Fabian Maurer (＠DarkShadow44) 15 Oct '22

15 Oct '22

This fixes some heap corruption observed in ReactOS Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1054

4 12

Re: [PATCH 0/1] MR126: Draft: ddraw: Limit max texture size to fit a 16bit signed integer
by Fabian Maurer (＠DarkShadow44) 15 Oct '22

15 Oct '22

On Thu Jun 2 16:39:03 2022 +0000, Ghost User wrote: > Henri Verbeet replied on the mailing list: > ``` > On Thu, 2 Jun 2022 at 17:39, Fabian Maurer (@DarkShadow44) > <wine(a)gitlab.winehq.org> wrote: > > On Thu Jun 2 13:17:37 2022 +0000, **** wrote: > > > Henri Verbeet replied on the mailing list: > > > \`\`\` > > > On Wed, 25 May 2022 at 02:02, Fabian Maurer <wine(a)gitlab.winehq.org> wrote: > > > > Since ddraw propably never allowed sizes that big anyways, > > > > this should not cause any issues. > > > This seems like something it would be easy to write tests for. > > > \`\`\` > > Those tests would only work if your GPU advertises 32768x32768 > textures though. Would the testbot be able to handle that? > I suspect not, even feature level 12_1 only requires 16384 as maximum > texture dimensions. But a test testing that ddraw never advertises > dwMaxTextureWidth/dwMaxTextureHeight larger than 16384 would still > pass there. You'd need such a GPU to verify the change is in fact > correct, but presumably you already did that. > ``` Not quite sure how to continue here, my current GPU doesn't seem to allow texture sizes over 16384x16384. Not sure how to do proper testing like this. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/126#note_10821

1 0

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

14 Oct '22

-- v2: jscript: Implement `reviver` argument for JSON.parse. jscript/tests: Fix copy paste mistake in JSON test. jscript: Implement Function.prototype.bind's `thisArg` properly. https://gitlab.winehq.org/wine/wine/-/merge_requests/1067

4 5

[PATCH v5 0/2] MR1016: ntoskrnl.exe: Implement IoCreateNotificationEvent
by Etaash Mathamsetty (＠etaash.mathamsetty) 14 Oct '22

14 Oct '22

xigncode3 seems to use it -- v5: ntoskrnl.exe: Fix formatting in IoCreateSyncronizationEvent. ntoskrnl.exe: Implement IoCreateNotificationEvent. https://gitlab.winehq.org/wine/wine/-/merge_requests/1016

4 5

Re: [PATCH v2 0/1] MR1069: dxva2/tests: Add another render target format to fix a test failure. - 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/1069

1 0

Re: [PATCH v2 0/1] MR1066: nsi: Update struct nsi_tcp_conn_dynamic for Windows 11. - 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/1066

1 0

Re: [PATCH v2 0/2] MR1059: winegstreamer: Implement AAC decoder MFT. - 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/1059

1 0

Re: [PATCH v2 0/1] MR1043: wined3d: Use the supplied context in wined3d_device_context_blt(). - 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/1043

1 0

Re: [PATCH v2 0/1] MR1042: wined3d: Handle VKD3D_SHADER_RESOURCE_DATA_MIXED in wined3d_data_type_from_vkd3d(). - 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/1042

1 0

Re: [PATCH v2 0/5] MR1032: comctl32: preparation for HPROPSHEETPAGE structure layout changes - 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/1032

1 0

Re: [PATCH v2 0/4] MR1051: opengl32: Cleanup make_opengl in preparation for https://gitlab.winehq.org/wine/wine/-/merge_requests/1010 - 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/1051

1 0

Re: [PATCH v6 0/5] MR874: mfmediaengine: Avoid vertically flipping video. - 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/874

1 0

Re: [PATCH v2 0/1] MR1062: d2d1: Use a gcc pragma instead of a compiler flag for -fexcess-precision. - 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/1062

1 0

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

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: > > I'd suggest moving some of the existing code into helper functions first. > You asked for that the first time too. I've tried, but I just couldn't > find any good seams to carve it along besides consolidating the > PeekMessage calls (e7e4c3d8eee915975e958521b8caffe94ef7a34d). The 3 > major hunks (message pump, the IMessageFilter_MessagePending stuff, and > polling the handles for completions/APCs) all tie into how the loop > exits and the post conditions (re-posting QuitMessage, writing `*index` > (or leaving it unmodified), errors, translating previous Wait* result), > and the order is quite important (because of side-effects like > consuming/preserving QS_ALLPOSTMESSAGE). > If you have any ideas I'd love to hear them. I could certainly pull > those 3 major hunks out into functions, but when they have get passed in > pointers to a bunch of outside-the-loop variables, and their return > value ends up being decoded into ends up with stuff like `if(hr == > S_FALSE) break; else if(FAILED(hr)) goto err;` then the flow control > just turned into spaghetti I hated even more than what it started as. > > ten commits per MR is rather too many (especially when they're non trivial). > Yeah, for lack of coming up with decent helper functions I tried to dice > it *really* finely separate testable commits that changed only one > behavior. I think they are all correct and improvements on the status > quo, but the very first commit fixes the same bug (short-timeout race) > for MTAs that the last finally fixes for STAs, so it felt weird to > propose actually merging it partially. And yet that's really the order > in which the steps make the most sense to read (in terms of minimizing > extraneous code change); getting the MTA out of the loop, so that it's > *only* the mesage loops, then building toward toward the case where > everything is happening in the right order and there's a correct place > to put the timeout. > The part that I dislike about this series is temporarily introducing use > of MWMO_INPUTAVAILABLE; that was a detour born of trying to split the > last 3 commits apart from each other, so there's only one behavior > change at a time. > 1. WAIT_OBJECT_* signaled after dispatching a message > 2. WAIT_IO_COMPLETION after dispatching a message (rather than just once > at the start) > 3. making sure to we're out of relevant messages before escalating > WAIT_TIMOUET to RPC_S_CALLPENDING). > Required some careful work to *preserve* bugs until the next commit. > I guess there's a few things in the middle that basically just > refactor/add tests without changing any observable behavior, so I'll > move those to the front and make a separate MR, just to cut down the > size of this one... And I guess I could also put a lot of the new tests > in as just new `todo_wine` tests, separate from the actual changes that > fix them. That would at least get a lot of lines of code out of this MR, > though not much of the conceptual complexity. 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/969#note_10685

1 0

[PATCH v2 0/1] MR1024: xmllite/writer: Correctly partially duplicate strings
by David Kahurani (＠kahurani) 14 Oct '22

14 Oct '22

Currently, the code copies one extra character than requested and does not terminate the string. Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v2: xmllite/writer: Correctly partially duplicate strings https://gitlab.winehq.org/wine/wine/-/merge_requests/1024

4 11

[PATCH v5 0/5] MR874: mfmediaengine: Avoid vertically flipping video.
by Rémi Bernon (＠rbernon) 14 Oct '22

14 Oct '22

This shows that media session samples are correctly oriented, but that mfmediaengine renders them upside down. -- v5: mfmediaengine: Remove vertical flipping of video frames. mfmediaengine/tests: Check IMFMediaEngine_TransferVideoFrames output orientation. mfmediaengine/tests: Pass a device manager and output format to create_media_engine. mf/tests: Check sample grabber RGB / NV12 orientation. mf/tests: Factor test grabber callback implementations. https://gitlab.winehq.org/wine/wine/-/merge_requests/874

4 9

[PATCH 0/1] MR1062: d2d1: Use a gcc pragma instead of a compiler flag for -fexcess-precision.
by Alexandre Julliard (＠julliard) 14 Oct '22

14 Oct '22

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

4 3

Re: [PATCH v5 0/5] MR944: win32u: Make desktop resize logic asynchronous.
by Rémi Bernon (＠rbernon) 14 Oct '22

14 Oct '22

On Thu Oct 13 19:11:33 2022 +0000, Rémi Bernon wrote: > Sorry, I'll have a look. 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/944#note_10671

1 0

[PATCH v2 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 . -- v2: tests: Test explicit casts between types that are component-wise tests: Test implicit casts between types that are equal component-wise. vkd3d-shader/hlsl: Always go through implicit conversion in assignments. tests: Test for invalid complex broadcasts. tests: Set ULPs to 2 in normalize() test. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/29

5 10

[PATCH 0/1] MR1057: 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/1057

5 10

[PATCH 0/1] MR1064: 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/1064

4 4

[PATCH 0/1] MR1060: include: Remove interfaces already define in msxml6.idl
by Alistair Leslie-Hughes (＠alesliehughes) 14 Oct '22

14 Oct '22

The removed interfaces cannot be found in the windows SDK, so making it one step close to being the same. Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1060

3 2

[PATCH 0/1] MR1058: po: Update Finnish translation.
by Lauri Kenttä (＠lauri.kentta) 14 Oct '22

14 Oct '22

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

3 2

[PATCH 0/1] MR1056: win32u: Asynchronously send the WM_DISPLAYCHANGE to the desktop window.
by Rémi Bernon (＠rbernon) 13 Oct '22

13 Oct '22

I'm not sure this would solve the problem from https://gitlab.winehq.org/wine/wine/-/merge_requests/944?commit_id=bc09f081… as I'm not yet able to reproduce it, but I suspect it might help. In any case I don't think there's any good reason for this call to be synchronous with send_message. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1056

3 2

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

13 Oct '22

> I'd suggest moving some of the existing code into helper functions first. You asked for that the first time too. I've tried, but I just couldn't find any good seams to carve it along besides consolidating the PeekMessage calls (e7e4c3d8eee915975e958521b8caffe94ef7a34d). The 3 major hunks (message pump, the IMessageFilter_MessagePending stuff, and polling the handles for completions/APCs) all tie into how the loop exits and the post conditions (re-posting QuitMessage, writing `*index` (or leaving it unmodified), errors, translating previous Wait* result), and the order is quite important (because of side-effects like consuming/preserving QS_ALLPOSTMESSAGE). If you have any ideas I'd love to hear them. I could certainly pull those 3 major hunks out into functions, but when they have get passed in pointers to a bunch of outside-the-loop variables, and their return value ends up being decoded into ends up with stuff like `if(hr == S_FALSE) break; else if(FAILED(hr)) goto err;` then the flow control just turned into spaghetti I hated even more than what it started as. > ten commits per MR is rather too many (especially when they're non trivial). Yeah, for lack of coming up with decent helper functions I tried to dice it *really* finely separate testable commits that changed only one behavior. I think they are all correct and improvements on the status quo, but the very first commit fixes the same bug (short-timeout race) for MTAs that the last finally fixes for STAs, so it felt weird to propose actually merging it partially. And yet that's really the order in which the steps make the most sense to read (in terms of minimizing extraneous code change); getting the MTA out of the loop, so that it's *only* the mesage loops, then building toward toward the case where everything is happening in the right order and there's a correct place to put the timeout. The part that I dislike about this series is temporarily introducing use of MWMO_INPUTAVAILABLE; that was a detour born of trying to split the last 3 commits apart from each other, so there's only one behavior change at a time. 1. WAIT_OBJECT_* signaled after dispatching a message 2. WAIT_IO_COMPLETION after dispatching a message (rather than just once at the start) 3. making sure to we're out of relevant messages before escalating WAIT_TIMOUET to RPC_S_CALLPENDING). Required some careful work to *preserve* bugs until the next commit. I guess there's a few things in the middle that basically just refactor/add tests without changing any observable behavior, so I'll move those to the front and make a separate MR, just to cut down the size of this one... And I guess I could also put a lot of the new tests in as just new `todo_wine` tests, separate from the actual changes that fix them. That would at least get a lot of lines of code out of this MR, though not much of the conceptual complexity. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/969#note_10623

1 0

2025

2024

2023

2022

wine-gitlab