This implements setting `ThreadPriorityBoost`, `ProcessPriorityBoost`, `ProcessBasePriority` and getting `ThreadPriorityBoost`, `ProcessPriorityBoost` NT info classes and adds tests where appropriate.
The actual boosting mechanism will be in part 2 to keep the size of this MR manageable.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7869
Follow-up of !2786, which appears to have been abandoned.
--
v19: ws2_32/tests: Add test for AF_UNIX sockets
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7650
Windows 3.0, Windows 3.1 and Windows 95 have library WIN87EM.DLL with
symbol name __FPMATH, not with _FPMATH. So fix the __FPMATH symbol name.
This change fixes running Windows 3.0 CALC.EXE application, which imports
WIN87EM.DLL symbols by name. Without this change the CALC.EXE fails on:
"No implementation for WIN87EM.__FPMATH, setting to 0xdeadbeef"
Other Windows application, including Windows 3.1+ CALC.EXE application,
import WIN87EM.DLL symbols by ordinals, so are not affected by this issue.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7863
Over the past several weeks I've been working on and off on this. I didn't track the hours but I'm sure that I've spent 80+ hours on the feature. I've tested and retested all known scenarios and it seems to be working as expected.
--
v5: cmd: Implement tab completion for command line entry.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843
To prevent performance degradation, we will cache the result of GetConsoleOutputCP() after executing every external command.
--
v3: cmd: Use the console output code page to read batch files.
programs/cmd: Factor out code_page when searching for a label.
cmd/tests: Add updated code page test in batch file.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6885
To prevent performance degradation, we will cache the result of GetConsoleOutputCP() after executing every external command.
--
v2: cmd: Use the console output codepage to read batch files.
cmd/tests: Add updated code page test in batch file.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6885
On Sat Apr 19 16:23:57 2025 +0000, eric pouech wrote:
> forgot to say that executable files must be in considered directory
> (eg if a.exe and e.bat exist in current directory, then 'a\<tab\>' shall
> circle around both files); PATH is not used
My code already does this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101459
On Sat Apr 19 16:20:43 2025 +0000, eric pouech wrote:
> maybe. i could also be something that cmd implements in
> CONSOLE_READCONSOLE_CONTROL (using 0x1B in control mask).
That's how I'm handling it in current changes (not yet pushed). But I shouldn't need to, based on ReadConsole behaviour that I see on Windows.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101458
On Sat Apr 19 16:23:57 2025 +0000, Joe Souza wrote:
> Testing on Windows 11 this morning, I find that Windows does not filter
> on .EXE or anything in PATHEXT if tab key is hit for first word on
> command line.
forgot to say that executable files must be in considered directory
(eg if a.exe and e.bat exist in current directory, then 'a\<tab\>' shall circle around both files); PATH is not used
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101456
On Sat Apr 19 15:01:13 2025 +0000, Joe Souza wrote:
> A bug in Wine's ReadConsole implementation that I found while making
> these changes is that Wine does not handle ESC key correctly. On
> Windows, ESC key clears the text on the screen and clears the buffer.
> Wine emits the control character for the ESC key. I'll handle this in
> my changes and add a FIXME comment.
maybe. i could also be something that cmd implements in CONSOLE_READCONSOLE_CONTROL (using 0x1B in control mask).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101455
On Fri Apr 18 16:37:52 2025 +0000, Joe Souza wrote:
> OK, using ReadConsole/CONSOLE_READCONSOLE_CONTROL on Windows gives me
> the behaviour that I need; i.e. pre-filled text is preserved and can be
> further edited. Caller must output the text first, but seems to work as expected.
> I'll start making the changes to my code soon, within the coming days.
A bug in Wine's ReadConsole implementation that I found while making these changes is that Wine does not handle ESC key correctly. On Windows, ESC key clears the text on the screen and clears the buffer. Wine emits the control character for the ESC key. I'll handle this in my changes and add a FIXME comment.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101451
On Sat Apr 19 14:56:08 2025 +0000, Joe Souza wrote:
> Will definitely handle .exe filtering as a subsequent patch.
Testing on Windows 11 this morning, I find that Windows does not filter on .EXE or anything in PATHEXT if tab key is hit for first word on command line.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101450
This fixes a test failure/crash on Windows 8.1 introduced by dd1d82728811c15716eefa0917eb3ecac4b9a85a.
--
v3: mfplat/tests: Don't assume video processor MFT can provide samples.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7838
I think what's missing is an audio client Reset(). We currently do Stop+Reset when the clock is stopped, and just Stop when the clock is paused. We don't Reset on pause so we don't lose pending data. But when we restart from at a different timestamp I think we should.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7833#note_101438
On Thu Apr 17 21:23:59 2025 +0000, Brendan McGrath wrote:
> I couldn't get this to build unfortunately. But if you can seek in this
> program, then you should be able to recreate the issue with pause, seek
> and then play.
You can seek with it, but it's not implemented on our side yet.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7833#note_101437
Adapted from [check_invalid_gs](https://gitlab.winehq.org/wine/wine/-/blob/d7a7cae2e2d1ad… in signal_i386.c. This prevents crashing when the %gs register is manipulated, such as in 32-bit code on "new-style" WoW64.
"Exertus: Darkness Approaches" is a 32-bit game that triggers this crash (on WoW64), which can be downloaded from the Bugzilla page's attachments. For another example, [test.c](https://bugs.winehq.org/attachment.cgi?id=77444) can reproduce it, courtesy of Fabian Maurer from the Bugzilla comments. This will crash whether it's compiled as 32-bit or 64-bit, while it works fine on Windows.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57444
Also, excuse me if submitting this is against some sort of code-freeze etiquette, it wasn't my intention try to have it merged immediately.
--
v8: ntdll/tests: Re-enable a previously crashing test.
ntdll: Check for invalid gs_base in the 64-bit segv_handler.
ntdll/tests: Add an exception test for accessing a modified %gs on x86_64.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7064
On Fri Apr 18 17:25:10 2025 +0000, eric pouech wrote:
> also note that for the first word of command line, when using tab,
> native cmd.exe filters on directories and files that can be executed
> (likely using PATHEXT list of extensions, didn't test that though)
> i'd suggest handling in two seperate patches the rd/md part, and the
> first parameter one...
> that should boil down to adding filters to the files gotten out of find
> files (directories and/or extensions) depending on context
Will definitely handle .exe, etc. filtering as a subsequent patch.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101422
--
v6: amstream: Implement dynamic formats in ddraw stream.
amstream/tests: Test for dynamic formats in ddraw stream.
amstream: Implement custom allocator for ddraw stream.
amstream/tests: Test for custom allocator in ddraw stream.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7715
--
v5: mshtml: Validate builtin host functions in IE9+ using prototype_id rather
mshtml: Store the prototype_id of the last member that contains the needed
mshtml: Define "create" from XMLHttpRequest constructor as a jscript prop
mshtml: Consolidate the functional constructors into a common struct
mshtml: Rename struct constructor to stub_constructor.
mshtml: Use get_constructor in window's get_XMLHttpRequest.
mshtml: Move Option constructor to the window rather than the prototype.
mshtml: Move Image constructor to the window rather than the prototype.
mshtml: Don't expose "create" from Option constructor in IE9+ modes.
mshtml: Don't expose "create" from Image constructor in IE9+ modes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7779
Over the past several weeks I've been working on and off on this. I didn't track the hours but I'm sure that I've spent 80+ hours on the feature. I've tested and retested all known scenarios and it seems to be working as expected.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843
Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/7815, for https://gitlab.winehq.org/wine/wine/-/merge_requests/7226, this only split the sync ops to a separate vtable and let objects delegate theirs to a separate object.
This starts using a event-like interface for most objects, leaving the decision regarding if/how to split sync themselves / integrate inproc syncs for later.
--
v2: server: Use an event as debug event sync.
server: Use an event as file lock sync.
server: Use an event as process startup info sync.
server: Use an event as thread context sync.
server: Use an event as thread apc sync.
server: Use an event as fd sync.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7848
Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/wayland_pointer.c:
> }
> else if (!needs_relative && pointer->zwp_relative_pointer_v1)
> {
> + pointer->accum_x = pointer->accum_y = 0;
I was thinking... if we perform the initialization/zeroing just before enabling relative motion in the if clause above, we reduce (although we do not completely eliminate) the window for the data race mentioned in a previous comment (i.e., some handler running concurrently). This also takes care of the lack of explicit initialization of the accum_x/accum_y members during wayland_pointer init.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7806#note_101383
This serie finishes the migration of the remaining types from TPI
stream (function signature, struct/class/union, enum) to new PDB
backend.
And it removes dual allocation of symt_* in old PDB backed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7849
Componenets installed by winetricks have "deadbeef.manifest" trailer
in their manifests, so it's not clear that filtering logic works. On
the other hand when manifests for versions 1.2.3.4 and 1.2.3.10 are
installed and application exe needs version 1.2.0.0 and later uses
LoadLibrary() to load a plugin.dll that needs 1.2.3.7, version 1.2.3.4
gets loaded with an .exe (because manifest for version 1.2.3.10 is
ignored) and version 1.2.3.10 gets loaded with a plugin.dll, and
this leads to crashes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7028
For https://gitlab.winehq.org/wine/wine/-/merge_requests/7226
This MR introduces a new wineserver "sync" entity, to be used by objects to implement the signal/wait operations. Later, the server sync implementations will be reduced as much as possible to event/mutex/semaphore/queue[^1]. I think it will then make the integration of ntsync cleaner, with inproc syncs being a separate flavor from the traditional server-side syncs.
Unlike how the fd struct have been implemented, I chose not to derive these syncs from the object base, because it seemed inconvenient to have to declare all the unused ops. Still they are refcounted, to allow us to share a sync between multiple objects, which will later benefit the console objects use cases, maybe others.
This makes me thing that the fd struct could also benefit from being lightweight entities as well, as it doesn't seem they really use most of the object vtable ops, and arguably we could have a common "light" refcounted/dumpable base for all fds, syncs and objects, but I didn't want to jump into that rabbit hole and it could be implemented later.
[^1]: And server-only async/completion waits, which maybe can be changed to use events too, but I'm not familiar enough.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7815
This MR modifies winegstreamer to match Windows behaviour in that:
1. the video decoders will output the PTS and duration of the input sample (if provided); and
2. the WMV decoder will set any value not provided to zero
It also adds support for supplying a DTS value to the MFTs.
I've marked this as draft as it fixes the tests in MR !7563 (in addition to fixing some existing `test_wmv_decoder` tests). Also, as demonstrated in MR !7569, our demuxers output different timestamps to Windows. This change will result in those different timestamps being forwarded from the decoder. So we may also want to address that difference prior to accepting this MR.
--
v7: winegstreamer: Use provided PTS and duration in video_decoder.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7623
This MR modifies winegstreamer to match Windows behaviour in that:
1. the video decoders will output the PTS and duration of the input sample (if provided); and
2. the WMV decoder will set any value not provided to zero
It also adds support for supplying a DTS value to the MFTs.
I've marked this as draft as it fixes the tests in MR !7563 (in addition to fixing some existing `test_wmv_decoder` tests). Also, as demonstrated in MR !7569, our demuxers output different timestamps to Windows. This change will result in those different timestamps being forwarded from the decoder. So we may also want to address that difference prior to accepting this MR.
--
v6: winegstreamer: Use provided PTS and duration in video_decoder.
mf/tests: Add negative timestamp tests for h264.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7623
On Thu Apr 17 21:21:27 2025 +0000, Brendan McGrath wrote:
> `OnClockRestart` is only used if you call `IMFPresentationClock::Start`
> with `PRESENTATION_CURRENT_POSITION`
> So my test is pause -> seek -> play.
Specifically I'm using:
- `IMFMediaEngine::Pause`
- `IMFMediaEngine::SetCurrentTime`
- `IMFMediaEngine::Play`
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7833#note_101314
On Thu Apr 17 21:21:27 2025 +0000, Nikolay Sivov wrote:
> This is already working using OnClockRestart(). How does it break in
> your testing?
`OnClockRestart` is only used if you call `IMFPresentationClock::Start` with `PRESENTATION_CURRENT_POSITION`
So my test is pause -> seek -> play.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7833#note_101312
--
v4: mshtml: Move Option constructor to the window rather than the prototype.
mshtml: Move Image constructor to the window rather than the prototype.
mshtml: Validate builtin host functions in IE9+ using prototype_id rather
mshtml: Store the prototype_id of the last member that contains the needed
mshtml: Define "create" from XMLHttpRequest constructor as a jscript prop
mshtml: Don't expose "create" from Option constructor in IE9+ modes.
mshtml: Don't expose "create" from Image constructor in IE9+ modes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7779
Follow-up of !2786, which appears to have been abandoned.
--
v18: ws2_32/tests: Add test for AF_UNIX sockets.
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7650
(For after the code freeze.)
I think we want to have this DLL living in Wine for easier development, and probably dynamically load our custom Chromium fork from here. (just like MSHTML and wine-Gecko)
The code for that fork could then be created in its own repo.
--
v7: embeddedbrowserwebview: Create CreateWebViewEnvironmentWithOptionsInternal stub.
embeddedbrowserwebview: Add stub dll.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7032
This serie implements the migration of some type into the
new PDB reader.
During the migration phase (this serie and next one), the types (A)
will:
- always be loaded by old PDB reader,
- be migrated accoring to the type's tag (UDT, pointer, enum...),
one commit for each tag by:
+ storing in new PDB reader an offset to that type inside the
PDB file,
+ requesting type details directly from the file.
(A) typedef:s are handled differently than the other types, so
they'll be taken care of later on.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7844
Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/wayland_pointer.c:
>
> if (!(hwnd = wayland_pointer_get_focused_hwnd())) return;
> if (!(data = wayland_win_data_get(hwnd))) return;
> + if (!private) return;
>
> - wayland_surface_coords_to_window(data->wayland_surface,
> + wayland_motion_delta_to_window(data->wayland_surface,
> wl_fixed_to_double(dx),
> wl_fixed_to_double(dy),
> - (int *)&screen.x, (int *)&screen.y);
> -
> + &screen.x, &screen.y);
> wayland_win_data_release(data);
>
> + d_accum->x += screen.x;
> + d_accum->y += screen.y;
The accum x and y are accessed in two contexts: in `wayland_pointer_update_constraint` for the zeroing, and also updated here in relative motion handler. These may be running concurrently in different threads, and since access to doubles may not be atomic we ideally need to protect the variables. Especially with the suggestion below to place them in wayland_pointer instead, it's straightforward to guard these in the relative motion handler with the wayland_pointer mutex.
Note that even with the lock, there are some Wayland event races left that are harder to resolve (e.g., Thread1: relative motion handler starts running, Thread2: zero accum and destroy relative motion, Thread1: handler updates accum), but at least we won't end up with some half-updated `double` value, and the worst case is then only a very small glitch.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7806#note_101267
Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/wayland_pointer.c:
> process_wayland.zwp_relative_pointer_manager_v1,
> pointer->wl_pointer);
> zwp_relative_pointer_v1_add_listener(pointer->zwp_relative_pointer_v1,
> - &relative_pointer_v1_listener, NULL);
> + &relative_pointer_v1_listener, &accum);
> TRACE("Enabling relative motion\n");
> }
> else if (!needs_relative && pointer->zwp_relative_pointer_v1)
> {
> + memset(&accum, 0, sizeof(accum));
I would recommend setting the doubles explicitly with `= 0.0`, as memset(0) of double variables is undefined behavior (from a C standard perspective, although you'd be hard-pressed to find a system where this causes a problem).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7806#note_101266
Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/waylanddrv.h:
> pthread_mutex_t mutex;
> };
>
> +struct wayland_point
> +{
> + double x;
> + double y;
> +};
With the move of accumulated x and y to `wayland_pointer` I don't think there is much benefit in a `struct wayland_point` anymore. A plain `double accum_x, accum_y;` or similar is enough.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7806#note_101265
Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/wayland_pointer.c:
> process_wayland.zwp_relative_pointer_manager_v1,
> pointer->wl_pointer);
> zwp_relative_pointer_v1_add_listener(pointer->zwp_relative_pointer_v1,
> - &relative_pointer_v1_listener, NULL);
> + &relative_pointer_v1_listener, &accum);
Let's place the accumulated x and y values in wayland_pointer, since it's really a per-pointer state (currently per-process since we have a single pointer).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7806#note_101263