- wine-gitlab - winehq.org

[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

2025

2024

2023

2022

wine-gitlab