If a client can crash a wineserver via requests only, it's a bug.
The wineserver crashes when a privileged client deletes every object in
the NT object namespace (which frees `root_directory`) and then attempts
to lookup or create any object name.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5343
This issue originated on IRC (a person complained about Tomato Jones II
not working but the ole errors in the log weren't actually an issue).
With this patch the game boots to the main menu (at least with
wine-staging).
--
v2: wbemprox: Stub most of the Win32_VideoController properties.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5372
Which is what !5255 was supposed to do.
--
v2: winegstreamer: Fallback to input caps only when no parser was found.
winegstreamer: Create the transform parsed caps from wg_format.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5405
Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into
a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices.
Note, it *increase* the number of vertices, but bandwith is much less costly
than multiple calls.
Note, only a very precise subset of the calls get buffered in order to
ensure that the disruption is minimal.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814
--
v21: ddraw: Increasing the vertex batch size on demand
ddraw: add d3d_perf statistics on buffering
wined3d: Add a TRACE in wined3d_streaming_buffer_unmap()
ddraw: Add a local buffer in d3d_device7_DrawPrimitive()
https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
I'm not completely sure what the expectations are regarding these registry key paths, but @afrantzis said Wayland reports adapters in an arbitrary order and this would let us find the right adapter config and their current settings based on their unique name instead.
Other drivers simply format the numeric ID themselves, though might not be 0-based index anymore.
--
v2: win32u: Use named sources instead of struct gdi_adapter.
win32u: Rename struct adapter to struct source.
win32u: Use a symlink for the logically indexed adapter config key.
win32u: Split writing adapter to registry to a separate helper.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5137
The Windows 11 message failure only seems to reproduce in a full test run, so we have to make an MR to investigate. I think it's clear with current results that just adjusting the expected sequence isn't going to be a solution.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5408
See also https://bugs.winehq.org/show_bug.cgi?id=56361
This patch makes piped commands work like for example "echo os get version|wmic" or "type file.txt | wmic" where file.txt contains some commands.
(probably used by program in aforementioned bugreport)
Also support interactive mode (wine wmic.exe)
Marked for now as draft.
--
v7: wmic.exe: Support interactive mode and piped commands.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5402
Fixes Sim City 3000 Building Architect.
--
v5: ddraw/tests: Add tests for multiple devices.
ddraw: Support multiple devices per ddraw object.
ddraw: Sync wined3d render target in d3d_device_sync_rendertarget().
ddraw: Store wined3d state in d3d_device.
wined3d: Factor out wined3d_texture_set_lod() function.
ddraw: Don't apply state in ddraw_surface_blt().
ddraw: Store matrix handle in the global table.
ddraw: Store surface handles in the global table.
ddraw: Store material handles in the global table.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5329
Do we always reallocate to larger size? It is currently reallocated based on the actual message size returned by the server, while buffer_size in peek_message may be bigger (and it is first allocated to 1024 bytes). Granted, I only reproduced the actual memory corruption with Proton, but it seems to me that in this regard the handling is the same.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5392#note_66132
We only reallocate the buffer to larger size, so I don't see how we can write past the allocated memory. Still, we potentially miss some opportunities to reuse the buffer, so better tracking of the size seems good to me, but the commit message could be adjusted.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5392#note_66130
Jacek Caban (@jacek) commented about dlls/win32u/message.c:
> }
>
> /* make sure that there is space for 'size' bytes in buffer, growing it if needed */
> -static inline void *get_buffer_space( void **buffer, size_t size, size_t prev_size )
> +static inline void *get_buffer_space( void **buffer, size_t size, size_t *prev_size )
This is no longer "prev", `buffer_size` would be a better name after this change.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5392#note_66129
Jacek Caban (@jacek) commented about dlls/win32u/message.c:
> {
> if (*prev_size < size)
> {
> - *buffer = malloc( size );
> + *buffer = realloc( *buffer, size );
This leaks on error, we could leave the buffer unchanged in that case.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5392#note_66128
Creating a new process is inefficient and also visible to applications. You don't need to duplicate the code, it can be factored out in a couple of handlers used in both command line and interactive mode. In interactive mode you'd run a loop that accepts commands and executes them, until you hit 'quit' or 'exit'.
wmic not handling spaces in the property list (unless quoted) is a bug, but you should be able to reuse process_property_list().
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5402#note_66122
Udev monitor monitors the whole input subsystem, but not all devices
in the input subsystem have devnodes associated to them.
This MR makes the event processing ignore such devices.
All device handling assumes devices have devnodes, so here we just
simply ignore all devices which do not have one. They are irrelevant.
Previously, udev bus thread aborted when an event for a device without
a devnode was processed:
```
10111.330:0068:0084:trace:hid:process_monitor_event Received action "remove" for udev device (null)
10111.330:0068:0084:warn:hid:bus_main_thread L"UDEV" bus wait returned status 0xc0000005
```
Just plugging in and out a normal mouse was enough cause this.
This was because root input devices (which do not have devnodes) were
handled too and `find_device_from_devnode()` choked on NULL argument.
--
v5: winebus: ignore udev events of devices which do not have devnodes
https://gitlab.winehq.org/wine/wine/-/merge_requests/5385
Udev monitor monitors the whole input subsystem, but not all devices
in the input subsystem have devnodes associated to them.
This MR makes the event processing ignore such devices.
All device handling assumes devices have devnodes, so here we just
simply ignore all devices which do not have one. They are irrelevant.
Previously, udev bus thread aborted when an event for a device without
a devnode was processed:
```
10111.330:0068:0084:trace:hid:process_monitor_event Received action "remove" for udev device (null)
10111.330:0068:0084:warn:hid:bus_main_thread L"UDEV" bus wait returned status 0xc0000005
```
Just plugging in and out a normal mouse was enough cause this.
This was because root input devices (which do not have devnodes) were
handled too and `find_device_from_devnode()` choked on NULL argument.
--
v4: winebus: change debugging class of an error case from WARN to ERR.
winebus: change debugging class of an error case from FIXME to ERR
winebus: group local variable declarations
https://gitlab.winehq.org/wine/wine/-/merge_requests/5385
--
v8: explorer: Restore display settings on process exit.
winex11.drv: Process RRNotify events in xrandr14_get_id.
user32/tests: Test that display settings are restored on process exit.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5060
With some intermediate refactoring to make the code simpler.
I believe the failures that happened previously were coming from how NtGdiDdDDIOpenAdapterFromLuid initialized desc->hAdapter in win32u while winex11 was then relying on it. I missed this detail before and it should be working fine now that the vulkan path is only used to retrieve the physical device.
--
v4: win32u: Move D3DKMT vulkan implementation out of winex11.
winex11: Introduce a new find_adapter_from_handle helper.
winex11: Introduce a new get_vulkan_physical_device helper.
winex11: Initialize D3DKMT vulkan instance only once.
win32u: Open adapters in NtGdiDdDDIEnumAdapters2 outside of the display devices lock.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5306
Tests failed. Apparently the AVI decoder is expected to enumerate formats that it doesn't actually support?
?_? and also ಠ_ಠ.
Well, that's not the first insane part of Windows I've seen. Apparently something calls pin_query_accept anyways, so that patch is unnecessary.
Also fixed 16bit BI_RGB in the iccvid patch.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5744#note_71576
> > If you wish to have me removed as maintainer of winegstreamer, please propose that directly, rather than abusing GitLab to get your patches committed.
>
> This is not an automated process and I don't think I'm abusing any mechanism here.
Well... unless I'm mistaken, it kind of is. The whole point of using Gitlab's reviewers feature is to have the software track things so that Alexandre doesn't have to. If he has to look at every patch to check if the right people have reviewed it then that point is defeated. If he's just looking for patches with no pending review [in areas that are known to have a maintainer] then removing a reviewer will make a patch effectively ready to commit. I can only assume this is why my patches to wined3d have been committed without Jan's approval when the bot flakes out and doesn't assign Jan as a reviewer.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5667#note_71571