- wine-gitlab - winehq.org

[PATCH v2 0/1] MR2118: ntdll: Explaining with wine requires a 3G/1G split on 32bit
by Steve Schnepp (＠steveschnepp) 06 Feb '23

06 Feb '23

Windows has a 2G/2G split by default, but some addresses are fixed in the win32 API, so we have to ensure that those addresses are still available in the virtual memory space and not taken by Linux. Kudos to stefand for taking the time to explain on IRC. -- v2: ntdll: Explaining with wine requires a 3G/1G split on 32bit https://gitlab.winehq.org/wine/wine/-/merge_requests/2118

4 4

[PATCH v6 0/1] MR1937: kernelbase: Fix grouping repeat for number formatting.
by Gabriel Ivăncescu (＠insn) 06 Feb '23

06 Feb '23

LOCALE_SGROUPING's string and the `Grouping` field in NUMBERFMTW are confusingly different. The former, which is what is fixed here, treats a '0' as a repeat of the previous grouping. But a 0 at the end of the `Grouping` field prevents it from repeating (it repeats by default otherwise) so it's the opposite. Note that without a '0' in the LOCALE_SGROUPING string, it shouldn't even repeat in the first place. This fixes the typical "3;0" default grouping, for example. See: https://learn.microsoft.com/en-us/windows/win32/intl/locale-sgrouping -- v6: kernelbase: Fix grouping repeat for number formatting. https://gitlab.winehq.org/wine/wine/-/merge_requests/1937

2 3

[PATCH 0/1] MR2118: ntdll: Explaining with wine requires a 3G/1G split on 32bit
by Steve Schnepp (＠steveschnepp) 06 Feb '23

06 Feb '23

Windows has a 2G/2G split by default, but some addresses are fixed in the win32 API, so we have to ensure that those addresses are still available in the virtual memory space and not taken by Linux. Kudos to stefand for taking the time to explain on IRC. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2118

2 1

[PATCH 0/5] MR2098: mshtml: Implement synchronous XMLHttpRequests.
by Gabriel Ivăncescu (＠insn) 06 Feb '23

06 Feb '23

wine-gecko does actually support synchronous XMLHttpRequests, even if they are deprecated, but unfortunately it is very broken compared to IE or all the other major browsers (more details [here](https://bugzilla.mozilla.org/show_bug.cgi?id=697151)). Thankfully, it still provides us with the event message loop, which is enough to fix it on mshtml side and act like IE. For sync XHRs, send() is supposed to block all script code, except for notifications sent to the sync XHR. This is because when send() blocks, no other piece of code in the script should execute other than the sync XHR handlers. Unfortunately, that's not the case in Gecko's broken implementation, which can execute handlers as if they were APCs while it's "blocked" in send(). Note that it doesn't actually block, though, because we still process the message loop (non-event related tasks such as navigation, paints, and other stuff), and that's normal. Gecko doesn't block everything related to script events, only some things on the document and timers, but that's far from enough and not even enough for our purposes since we use our own timer tasks. And not even message events are blocked, even though we *also* use our own message event dispatchers (but it doesn't block Gecko ones either). So what we have to do is we need to track all the timers and events dispatched that result in script handlers being executed, while "blocking" inside of a sync XHR send(), and queue them up to defer them to be dispatched later, after send() unblocks. But this is easier said that done. There are many corner cases to consider here, for example: * Events dispatched *synchronously* from within a sync XHR handler or other piece of code called from it. * Nested sync XHR send() calls (called during handler of another sync XHR). * Async XHRs having their events dispatched during a blocking sync XHR send() are complicated. `readyStateChange` for example needs to have the async XHR's readyState at the time it was sent, **not** at the time it was actually dispatched, since we're going to delay it and dispatch it later. It's similar with other XHR states, such as responseText (which can be partial). * Aborts of async XHRs during such handlers. These patches hopefully should address all the issues and, on a high level, work like this: * Track the `readyState` and `responseText` length manually, so we can override / force them to specific values. * "Snapshot" the async XHR at the time we encounter an event for it, and queue this event with such information. When later dispatching this event (after being deferred), we temporarily set the state of the async XHR to the snapshot. * To deal with nested event dispatches, keep track of a "dispatch depth" (everytime we dispatch an event we increase the depth, and when it returns we decrease it). * For sync XHRs, we note the depth when send() is called, and defer events at that depth, since they're dispatched during the "blocked" message loop and need to be delayed (except for sync XHR events, which is a special case since it must be dispatched synchronously). When it returns, we restore the previous blocking depth. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2098

3 7

[PATCH 0/7] MR2117: More improvements in PDB dumping.
by eric pouech (＠epo) 06 Feb '23

06 Feb '23

This series: - complements PDB dumping in a few areas (internals of MSF, string tables, public stream) - allow to opt in for only a portion of PDB file -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2117

2 7

[PATCH 0/1] MR2106: ntdll: Fix path to ntdll for "old" wow64 configuration.
by eric pouech (＠epo) 06 Feb '23

06 Feb '23

For a 32bit process, running in the "old" wow64 configuration, the filename of loaded (32 bit) ntdll.dll is reported as ..\system32\ntdll.dll instead of being in the wow64 directory. This affects: - filename used for image mapping - filename entry in LdrData (Note all the others DLLs in this configuration are correctly exposed in wow64 directory). Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2106

3 4

[PATCH 0/1] MR1764: inetmib1: Get rid of GCC12 warning.
by eric pouech (＠epo) 06 Feb '23

06 Feb '23

Code assumes that tableIndex is never 0, while GCC cannot infer it. So include tableIndex=0 case into already handled error cases. GCC/Mingw complains with: /home/eric/work/wine/dlls/inetmib1/main.c: In function 'mib2IfEntryQuery': /home/eric/work/wine/dlls/inetmib1/main.c:646:25: warning: array subscript 4294967295 is above array bounds of 'MIB_IFROW[1]' {aka 'struct _MIB_IFROW[1]'} [-Warray-bounds] 646 | &ifTable->table[tableIndex - 1], item, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /home/eric/work/wine/include/ipmib.h:21, from /home/eric/work/wine/include/iprtrmib.h:24, from /home/eric/work/wine/include/iphlpapi.h:25, from /home/eric/work/wine/dlls/inetmib1/main.c:30: /home/eric/work/wine/include/ifmib.h:66:15: note: while referencing 'table' 66 | MIB_IFROW table[1]; Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1764

3 3

[PATCH 0/1] MR978: kernelbase: Fix uninitialized return value in GetModuleHandleA().
by eric pouech (＠epo) 06 Feb '23

06 Feb '23

GCC (MingW) 12.2 rightfully warns with: /home/eric/work/wine/dlls/kernelbase/loader.c: In function 'GetModuleHandleA': /home/eric/work/wine/dlls/kernelbase/loader.c:332:12: warning: 'ret' may be used uninitialized [-Wmaybe-uninitialized] 332 | return ret; | ^~~ /home/eric/work/wine/dlls/kernelbase/loader.c:329:13: note: 'ret' declared here 329 | HMODULE ret; | ^~~ So set module to NULL on all error codepaths in GetModuleHandleExA(). Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/978

2 2

[PATCH 0/1] MR1765: krnl386.exe16: Get rid of GCC 12 warning.
by eric pouech (＠epo) 06 Feb '23

06 Feb '23

Mark args local variable with volatile to tell GCC not to check for out of bounds access. Alternative fix: use an intermediate variable to store &fun as an integer. MingW/GCC 12 complains with: In file included from /home/eric/work/wine/dlls/krnl386.exe16/thunk.c:36: /home/eric/work/wine/dlls/krnl386.exe16/thunk.c: In function 'SSCall': /home/eric/work/wine/include/wine/debug.h:91:4: warning: array subscript 1 is outside array bounds of 'INT_PTR (__attribute__((stdcall)) *[1])(void)' {aka 'int (__attribute__((stdcall)) *[1])(void)'} [-Warray-bounds] 91 | wine_dbg_log( __dbcl, __dbch, __func__, __VA_ARGS__); } } while(0) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/eric/work/wine/include/wine/debug.h:88:8: note: in expansion of macro '__WINE_DBG_LOG' 88 | __WINE_DBG_LOG | ^~~~~~~~~~~~~~ /home/eric/work/wine/include/wine/debug.h:463:36: note: in expansion of macro '__WINE_DPRINTF' 463 | #define WINE_TRACE __WINE_DPRINTF(_TRACE,__wine_dbch___default) | ^~~~~~~~~~~~~~ /home/eric/work/wine/include/wine/debug.h:506:36: note: in expansion of macro 'WINE_TRACE' 506 | #define TRACE WINE_TRACE | ^~~~~~~~~~ /home/eric/work/wine/dlls/krnl386.exe16/thunk.c:996:32: note: in expansion of macro 'TRACE' 996 | for (i = 0; i < nr/4; i++) TRACE("0x%08lx,",args[i]); | ^~~~~ /home/eric/work/wine/dlls/krnl386.exe16/thunk.c:989:17: note: at offset 4 into object 'fun' of size 4 989 | FARPROC fun, /* [in] function to call */ | ~~~~~~~~^~~ Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1765

3 3

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Timo Zuccarello (＠timozuccarello) 06 Feb '23

06 Feb '23

On Mon Feb 6 15:31:37 2023 +0000, Rémi Bernon wrote: > Yes I believe so. Is there anything I can help with? I obviously have a bit of a personal interest in having this "fixed" finally. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23088

1 0

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Rémi Bernon (＠rbernon) 06 Feb '23

06 Feb '23

On Mon Feb 6 15:28:54 2023 +0000, Timo Zuccarello wrote: > Looks great, I didn't know you were working on it already! I presume a > fixed offset is enough then in most cases, so no need for manual > mappings from XKB names? Yes I believe so. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23087

1 0

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Timo Zuccarello (＠timozuccarello) 06 Feb '23

06 Feb '23

On Mon Feb 6 15:05:02 2023 +0000, Rémi Bernon wrote: > I mean, I don't know if we need to detect VNC, but at least having an > option to enable or disable the bogus scancode auto-detect is imho a > good solution. Looks great, I didn't know you were working on it already! I presume a fixed offset is enough then in most cases, so no need for manual mappings from XKB names? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23086

1 0

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Rémi Bernon (＠rbernon) 06 Feb '23

06 Feb '23

On Mon Feb 6 15:03:35 2023 +0000, Rémi Bernon wrote: > I think it's a good way to fix this, and I started implementing the > `winecfg` option, with a first MR for some preparatory work here: https://gitlab.winehq.org/wine/wine/-/merge_requests/2062 I mean, I don't know if we need to detect VNC, but at least having an option to enable or disable the bogus scancode auto-detect is imho a good solution. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23085

1 0

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Rémi Bernon (＠rbernon) 06 Feb '23

06 Feb '23

On Mon Feb 6 14:32:23 2023 +0000, Timo Zuccarello wrote: > @rbernon Prompted by someone who also had issues with exotic or > non-qwerty keyboard layouts in #winehq, I've taken another look at this. > Came across a StackOverflow post about detecting whether a display is > VNC > (https://stackoverflow.com/questions/29371717/linux-detecting-if-youre-runni…). > Would that be an option? I.e. add an override winecfg option and by > default try to detect a VNC session and if it's VNC, use previous > mapping/code, otherwise use XKB? I think it's a good way to fix this, and I started implementing the `winecfg` option, with a first MR for some preparatory work here: https://gitlab.winehq.org/wine/wine/-/merge_requests/2062 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23083

1 0

[PATCH 0/1] MR80: vkd3d-shader/hlsl: Support reflect() intrinsic.
by Nikolay Sivov (＠nsivov) 06 Feb '23

06 Feb '23

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

3 4

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Timo Zuccarello (＠timozuccarello) 06 Feb '23

06 Feb '23

On Thu Oct 6 11:55:45 2022 +0000, Timo Zuccarello wrote: > I just went through the email thread (I'm still new to navigating > pipermail/mailing list archives) and I see the point, although I don't > think I can entirely grasp what VNC does. But the way I understand it is > that even if we used XKB names for the scan codes as in this MR, those > would be messed up just as well when using a VNC X server, as it maps > backwards from vkeys to scan codes? > In the XKB specification/documentation, "The key name links keys with > similar functions or in similar positions on keyboards that report > different scan codes", which gets me wondering how Windows actually > handles exotic keyboards or rather what is common practice in the > drivers for said exotic keyboards. > In any case, I agree, I suppose optional layout detection would be the > most compatible solution for now at least. @rbernon Prompted by someone who also had issues with exotic or non-qwerty keyboard layouts in #winehq, I've taken another look at this. Came across a StackOverflow post about detecting whether a display is VNC (https://stackoverflow.com/questions/29371717/linux-detecting-if-youre-runni…). Would that be an option? I.e. add an override winecfg option and by default try to detect a VNC session and if it's VNC, use previous mapping/code, otherwise use XKB? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23078

1 0

[PATCH 0/1] MR82: vkd3d: Fix checking for failure from SleepConditionVariableCS().
by Zebediah Figura (＠zfigura) 06 Feb '23

06 Feb '23

Fixes: 552926cfca64db45e9731f675c65a7214bfa6441 -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/82

4 3

[PATCH 0/1] MR83: vkd3d-shader: Initialize the parameter allocator head.
by Zebediah Figura (＠zfigura) 06 Feb '23

06 Feb '23

This fixes a memory leak. Fixes: 007f894b9493eb80091899dab971e369f1673a4f -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/83

4 3

[PATCH v6 0/4] MR1088: ntdll: Avoid calling pthread_exit on thread exit.
by Rémi Bernon (＠rbernon) 06 Feb '23

06 Feb '23

Using a dedicated exit jmpbuf and removing the need for assembly routines. When Wine handles an exception in unix code, we return to user mode by jumping to the last syscall frame. This can leave some pthread cancel cleanups registered, in the pthread internal linked list, and at the same time later overwrite the stack frame they were registered for. In the same way, jumping to the exit frame on thread exit or abort, can also leave some cleanup handlers registered for invalid stack frames. Depending on the implementation, calling pthread_exit will cause all the registered pthread cleanup handlers to be called, possibly jumping back to now overwritten stack frames and causing segmentation faults. Exiting a pthread normally, by returning from its procedure, or calling exit(0) for the main thread doesn't run pthread_exit and doesn't call cleanup handlers, avoiding that situation. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213 ### Additional note: For robustness, we should probably try to execute these cleanup handlers when unwinding the stack frames, as we would otherwise leave pthread objects in a potential problematic state (like a mutex locked, etc). It is however hard to do so when the handlers are registered from some C code: pthread C implementation is done by calling some internal pthread functions to register the handlers, and they aren't registered as standard unwind handlers. Only pthread_cancel and pthread_exit can unwind and call / unregister the C handlers, but interrupting that procedure, for instance calling setjmp / longjmp from withing our own handler isn't supported. From C++ code, pthread cleanup handlers are registered through C++ class constructors / destructors, and it would then be possible to partially unwind and call them at the same time. -- v6: ntdll: Remove now unnecessary arch-specific exit frame. ntdll: Avoid calling pthread_exit on thread exit. ntdll: Return entry and suspend from server_init_process_done. ntdll: Create a pthread for the main thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/1088

2 5

[PATCH v2 0/6] MR77: hlsl: Fixes for function definition vs declaration.
by Zebediah Figura (＠zfigura) 06 Feb '23

06 Feb '23

-- v2: vkd3d-shader/hlsl: Add functions to the global list inside the func_prototype rule. vkd3d-shader/hlsl: Use the original hlsl_ir_function_decl struct rather than allocating a new one for each definition. vkd3d-shader/hlsl: Put synthetic variables into a dummy scope. vkd3d-shader/hlsl: Add a hlsl_cleanup_semantic() helper. vkd3d-shader/hlsl: Store function parameters in an array. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/77

4 12

Re: [PATCH v5 0/8] MR66: vkd3d-shader/hlsl: Broaden resources support v2 (PART 1).
by Francisco Casas (＠fcasas) 06 Feb '23

06 Feb '23

:arrow_up: Rebased on top of current master. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/66#note_23066

1 0

[PATCH 0/1] MR78: vkd3d: Initialize image aspect for NULL SRVs.
by Matteo Bruni (＠Mystral) 06 Feb '23

06 Feb '23

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

3 2

[PATCH 0/1] MR2115: programs/conhost: only update font when running with a window.
by eric pouech (＠epo) 06 Feb '23

06 Feb '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54449 Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2115

3 2

[PATCH v3 0/3] MR1259: gitlab: Run some tests with nulldrv driver.
by Rémi Bernon (＠rbernon) 06 Feb '23

06 Feb '23

Allowing the job to fail to avoid failing the pipeline. Some new tests are failing with it, and some are succeeding todo_wine. -- v3: gitlab: Run user32 32-bit tests with nulldrv driver. https://gitlab.winehq.org/wine/wine/-/merge_requests/1259

2 4

[PATCH v2 0/5] MR1756: ntdll: Various performance improvements to hash_short_file_name.
by Rémi Bernon (＠rbernon) 06 Feb '23

06 Feb '23

The function is called a lot, I believe something like this would improve its performance in general. -- v2: ntdll: Lookup extension from the end in hash_short_file_name. ntdll: Use invalid char lookup table in lookup_unix_name. ntdll: Use invalid char lookup table in nt_to_unix_file_name_no_root. ntdll: Use invalid char lookup table in is_legal_8dot3_name. ntdll: Use invalid char lookup table in is_invalid_dos_char. https://gitlab.winehq.org/wine/wine/-/merge_requests/1756

2 7

2025

2024

2023

2022

wine-gitlab