- wine-gitlab - winehq.org

[PATCH v2 0/1] MR6891: cmd: Use CD /D to change directory in POPD (same as PUSHD).
by huangqinjin (＠huangqinjin) 25 Nov '24

25 Nov '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57137 -- v2: cmd: Use CD /D to change directory in POPD (same as PUSHD). https://gitlab.winehq.org/wine/wine/-/merge_requests/6891

4 3

[PATCH v21 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 25 Nov '24

25 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v21: timeout: add minimal test suite https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

4 8

[PATCH 0/2] MR6885: cmd: Use the console output codepage to read batch files.
by Akihiro Sagawa (＠sgwaki) 25 Nov '24

25 Nov '24

To prevent performance degradation, we will cache the result returned by GetConsoleOutputCP() after executing any external command. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6885

4 6

[PATCH v2 0/1] MR6800: winegstreamer: Lock the media source critical section while using the event queue.
by Conor McCarthy (＠cmccarthy) 25 Nov '24

25 Nov '24

These changes are the documented way to implement IMFMediaEventGenerator for a media source. Avoiding using a destroyed event queue is the only reason to lock the CS that I can find. On top of !6783 it seems to resolve hanging while switching characters in Killsquad (not decisively proven though). -- v2: winegstreamer: Lock the media source critical section while using the event queue. https://gitlab.winehq.org/wine/wine/-/merge_requests/6800

4 21

[PATCH 0/2] MR6897: dplayx: Support DPMESSAGEQUEUE_RECEIVE in GetMessageQueue().
by Anton Baskanov (＠baskanov) 25 Nov '24

25 Nov '24

This allows STAR WARS Galactic Battlegrounds Saga to join and play multiplayer sessions created by native dplay. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6897

4 4

[PATCH 0/1] MR6896: dplayx: Add a few more locks (Coverity)
by Fabian Maurer (＠DarkShadow44) 25 Nov '24

25 Nov '24

It's done like this everywhere else, so add locks everywhere. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6896

3 2

[PATCH v3 0/8] MR6427: winevulkan: Introduce a vulkan object structure.
by Rémi Bernon (＠rbernon) 25 Nov '24

25 Nov '24

I'm starting to consider wrapping more vulkan objects in win32u, I think it'll be useful to implement compositing (and incidentally shared resources with interop with the D3DKMT/NtGdi API), starting with nulldrv/offscreen swapchains. Alternatively we could export more functions from win32u and keep all the wrappers in winevulkan, but having access to win32u internals with a generic vulkan object wrapping mechanism seems to be more interesting. Right now this is not very convenient because the vulkan object hierarchy is only available in winevulkan. This introduces shared structures and API between win32u and winevulkan so they can manipulate the wrapped objects from both side. The interface would only expose what is necessary, ie: the object hierarchy and wrapped handles, the instance and device functions, and the objects rbtree for debugging, so win32u can insert its wrapper there as well. After moving the surface and swapchain wrappers to win32u, the interface would look like this: https://gitlab.winehq.org/rbernon/wine/-/blob/65ca1280d46a2dff792e298c22242… (I pushed a complete WIP branch to https://gitlab.winehq.org/rbernon/wine/-/commits/wip/vulkan-win32u-driver?r…). We can also consider moving all the winevulkan wrappers to win32u but it's not clear whether it's necessary or desirable, and we can also do that later using this interface. -- v3: winevulkan: Introduce a new vulkan_physical_device base structure. winevulkan: Introduce a new vulkan_instance base structure. winevulkan: Pass physical device array params to some helpers. winevulkan: Name wine_instance parameters and variables more consistently. winevulkan: Move vulkan_client_object header to wine/vulkan_driver.h. winevulkan: Generate vulkan_(device|instance)_funcs in wine/vulkan.h. win32u: Use PFN_* typedefs for vulkan function pointers. winevulkan: Add missing wine_vkGetPhysicalDeviceSurfaceFormatsKHR manual wrapper. https://gitlab.winehq.org/wine/wine/-/merge_requests/6427

2 9

[PATCH 0/1] MR6848: mf/evr: Increase the number of prerolled samples to 3.
by Rémi Bernon (＠rbernon) 25 Nov '24

25 Nov '24

Fixes some stuttering in Secret of Mana. Native seems to only preroll 2 samples, but it still stutters a bit in Secret of Mana without at least 3 buffers. This is probably caused by a different sample decoding pattern, and 3 buffers in flight should be fine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6848

3 3

[PATCH v2 0/1] MR6893: msi: Use mybool instead of bool as variable name.
by Gerald Pfeifer (＠gerald) 25 Nov '24

25 Nov '24

bool is a reserved identifier in C23 and would break with GCC 15 moving to -std=gnu23 (based on C23). Use mybool instead, along the line of myint in the same context. -- v2: msi: Use mybool instead of bool as variable name. https://gitlab.winehq.org/wine/wine/-/merge_requests/6893

3 2

[PATCH 0/1] MR6877: ntdll: Force redirect all ARM64EC indirect calls until the JIT is ready.
by Billy Laws (＠bylaws) 24 Nov '24

24 Nov '24

Tested by running chrome without no-sandbox successfully. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6877

4 6

[PATCH 0/7] MR4947: winewayland.drv: part 12: Display mode change emulation
by Alexandros Frantzis (＠afrantzis) 24 Nov '24

24 Nov '24

This MR uses the existing compositor side surface scaling in the driver (through wp_viewporter, currently used for Hi-DPI scaling) to emulate display mode changes. This works wonderfully in coordination with fullscreen since the compositor is required non only to scale the surface, but also to position it properly and provide opaque surroundings (note: some compositors don't implement the last two features properly!). Since: 1. Wayland doesn't allow clients to change the actual display configuration, and 2. there is no queryable service that holds the display information in a consistent manner (à la xrandr), the MR uses the win32 device settings as the source of truth for the current display mode. We let win32u handle the display mode change in the default manner (i.e., just updating the registry settings), and provide access to the current mode when updating the display devices through a new `gdi_display_manager.get_adapter()` function. In order to be able to consistently (across all processes) associate an adapter device with its corresponding `wl_output` the MR introduces per-adapter driver data. Note for people trying this out: many modern games don't change the hardware display settings, but rather scale themselves in right way to achieve the visual effect of a mode change (similarly to how this MR works, but they do it on the application side). To exercise most of the functionality in this MR you need an application that actually uses the `ChangeDisplaySettings` win32 API. Thanks! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4947

16 48

[PATCH v4 0/28] MR6207: include: Introduce new COM implementation helper macros.
by Rémi Bernon (＠rbernon) 23 Nov '24

23 Nov '24

I think it would be very nice to have something like that to reduce the burden of implementing COM interfaces. This shows for instance on the windows.gaming.input module a 30% LoC reduction (from ~6800 to ~4700), even though the module already had a boilerplate helper macros already. The MR introduces macros to automatically implement each IUnknown method, as well as all of them at once. It also includes a helper to implement IInspectable methods at once, as well as macros to forward both interface methods to a base interface or an outer object. Last, it provides higher-level macros to implement a main interface and any number of sub interfaces and generate IUnknown, forwarding and vtables for all of them at once, with IInspectable support when needed. It uses widl to generate additional per-interface macros, for things like inheritance and vtable generation. The rest of the macros are otherwise shared in a Wine-specific header. The implementation is split to show individual macro being used, although they are later replaced by higher-level macros. The individual helpers are still useful in some corner cases where specific behavior needs to be implemented, or for aggregating classes. -- v4: windows.gaming.input: Use the new COM macros everywhere possible. windows.gaming.input: Use the new macros for class implementation. widl: Generate new macros for class implementation. windows.gaming.input: Use the new macros for IInspectable implementation. widl: Generate new macros for IInspectable implementation. windows.gaming.input: Use the new macros for IUnknown implementation. widl: Generate new macros for IUnknown implementation. windows.gaming.input: Use the WIDL_impl_IUnknown_QueryInterface boilerplate macros. widl: Generate some WIDL_impl_IUnknown_QueryInterface boilerplate macros. windows.gaming.input: Use the WIDL_impl_QueryInterface boilerplate macros. widl: Generate some WIDL_impl_QueryInterface boilerplate macros. windows.gaming.input: Use the WIDL_impl_IUnknown_Release boilerplate macros. widl: Generate some WIDL_impl_IUnknown_Release boilerplate macros. windows.gaming.input: Use the WIDL_impl_IUnknown_AddRef macros. widl: Generate some WIDL_impl_IUnknown_AddRef boilerplate macros. windows.gaming.input: Use the WIDL_impl_IInspectable_forwards boilerplate macros. widl: Generate some WIDL_impl_IInspectable_forwards boilerplate macros. windows.gaming.input: Use the WIDL_impl_IUnknown_forwards boilerplate macros. widl: Generate some WIDL_impl_IUnknown_forwards boilerplate macros. windows.gaming.input: Use the new WIDL_impl_from_* boilerplate macros. widl: Generate some WIDL_impl_from_* boilerplate macros. windows.gaming.input: Use the new WIDL_impl_*Vtbl macros. widl: Generate WIDL_impl_*Vtbl boilerplate macros. windows.gaming.input: Use type-prefixed impl_from helpers. windows.gaming.input: Move struct qualifier inside the macro. windows.gaming.input: Use a separate interface for IAgileObject. makedep: Generate some new impl.h headers from the IDLs. widl: Generate some new impl.h headers from the IDLs. 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/6207

1 1

[PATCH v6 0/7] MR6892: dlls/propsys: Implement IPropertyDescription for several known system properties.
by Vibhav Pant (＠vibhavp) 23 Nov '24

23 Nov '24

This MR adds a very basic implementation of `IPropertyDescription` for system defined properties (i.e, the ones in \<propkey.h\>). This is needed to support the [`Properties`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation.properties?view=winrt-26100) method for `IDeviceInformation` in Windows.Devices.Enumeration (!6874). -- v6: dlls/propsys: Implement IPropertyDescription for several known system properties. dlls/propsys: Add IPropertyDescription stub for system defined properties. https://gitlab.winehq.org/wine/wine/-/merge_requests/6892

3 8

[PATCH 0/1] MR6895: mlang: In GetFontCodePages add another null check (Coverity)
by Fabian Maurer (＠DarkShadow44) 23 Nov '24

23 Nov '24

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

3 2

[PATCH v3 0/2] MR6289: dsound: Reject NaN values in some functions.
by Aida Jonikienė (＠DodoGTA) 23 Nov '24

23 Nov '24

The tests aren't really tested though (they partially require interactive mode and they caused lag issues on one person's machine). -- v3: dsound/tests: Add NaN tests for floating-point 3D functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/6289

2 5

[PATCH v2 0/3] MR6715: Support separated debug information for PE images.
by eric pouech (＠epo) 23 Nov '24

23 Nov '24

This serie is a first attempt to provide a solution to bug 57308 [1]. Basically, Arch distro is looking for Wine support in distributing debug information for Wine PE modules separated from image. A quick overview of distro (Debian, Fedora, Arch) situation i (I may have missed a couple of items), but: - no distro ship separate debug information for PE modules (they do it for ELF ones though) - at best, they ship unstripped PE modules. IMO, we need to help them pave the way to what should be the best expected situation (in Wine and wrt distros) to support separate debug information for PE images. First, I believe we need to use a (solid) key to bind the stripped image and the file holding the debug information. In ELF format, this is typically done by inserting a .note.gnu.build-id section (in both stripped image and debug information file) which contains the key. This key is used to either search in fixed location (eg /usr/lib/.debug), or as key to download the debug information from a remote server (debuginfod). The key is generally made of a hash of (some sections of) the image file. This allows (esp. in the case of downloading the debug information from a debugger) to discriminate between several versions of the same module. I think we should target this kind of solution instead of storing the debug information alongside the module (usually done as ntdll.dll.debug). This wouldn't let debuggers download the expected debug info upon request. Fortunately, gcc and clang provide a build-id option (when generating PE images) which stores this key in the PE image. What this serie does: - fixes & improves dbghelp in the support of the build-id information from gcc/mingw & clang, - improves Wine's configure script so that clang can be used to generate dwarf debug information and build-id information in PE builds, - adds a couple of additional search locations for debug information files, It takes the following assumptions for the storage: - debug information files for PE images are stored in same hierarchy as debug information files for ELF images (eg /usr/lib/.debug) - naming of such files is done as ELF, ie by using the hex string generated from the binary blob of the key. This is *NOT* the usual way how the GUID will be printed (because the first 3 integers of the GUID are stored in little-endian format). (Note: I had to make a choice here. I don't have strong arguments one way or the other, but we need to agree on the convention here). What distro should do to support separate debug info: - configure Wine with --enable-build-id - adapt at least the packaging tool to extract the key out of unstripped image [2], - if binutils isn't compiled with PE support (this is apparently the Arch case), adapt the scripts to use x86_64-objcopy instead of objcopy (and friends). I marked this MR as draft for now, as: - I still need to polish some items (like the default location for looking up debug information files), - wait for feedback on this proposal (it does make a couple of assumptions that need sharing IMO), Further steps: - the steps above are mainly targetted to have a solution for packaged download of debug information files, - this should be integrated in debuginfod (server side: ingestion of PE files and client side: ensure gdb, lldb are compatible; implement debuginfod in winedbg). Feed back welcomed! [1]: https://bugs.winehq.org/show_bug.cgi?id=57308 [2]: The least invasive readelf replacement (assuming binutils is compiled with PE support). (otherwise, use x86_64-objdump) ``` BUILDID=`objdump -p "$INPUT" | sed -n "/RSDS signature / {s/.*signature //; s/ age.*//p; q;}"` BUILDID=${BUILDID:6:2}${BUILDID:4:2}${BUILDID:2:2}${BUILDID:0:2}${BUILDID:10:2}${BUILDID:8:2}${BUILDID:14:2}${BUILDID:12:2}${BUILDID:16} ``` Additional note: gcc/mingw puts the desired debug entry inside a dedicated section (.buildid), while clangs keeps it in .rdata (as msvc does). So, this invalidates any attempt to get information from the .buildid section (as stated in bug report). -- v2: configure.ac: Improve clang configuration for dwarf as cross debug format. dbghelp: Search debug info with buildid for RSDS debug entry w/o filenames. dbghelp: Extend search for buildid in system directories. https://gitlab.winehq.org/wine/wine/-/merge_requests/6715

5 8

[PATCH v5 0/7] MR6892: dlls/propsys: Implement IPropertyDescription for several known system properties.
by Vibhav Pant (＠vibhavp) 23 Nov '24

23 Nov '24

This MR adds a very basic implementation of `IPropertyDescription` for system defined properties (i.e, the ones in \<propkey.h\>). This is needed to support the [`Properties`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation.properties?view=winrt-26100) method for `IDeviceInformation` in Windows.Devices.Enumeration (!6874). -- v5: dlls/propsys: Implement IPropertyDescription for several known system properties. dlls/propsys: Add IPropertyDescription stub for system defined properties. dlls/propsys/tests: Add conformance tests for PSGetNameFromPropertyKey. dlls/propsys: Add stubs for PSGetNameFromPropertyKey. dlls/propsys: Add stubs for PropertySystem. https://gitlab.winehq.org/wine/wine/-/merge_requests/6892

3 8

[PATCH v7 0/5] MR7: Draft: ntdll: Properly track refcount with forwarded exports.
by Jinoh Kang (＠iamahuman) 23 Nov '24

23 Nov '24

This fixes https://bugs.winehq.org/show_bug.cgi?id=52094. -- v7: ntdll: Properly track refcount with forwarded exports. ntdll: Don't re-add a module dependency if it already exists. ntdll: Remove some unnecessary NULL checks for current_importer. ntdll: Set export forwarder DLL as the dynamic importer in LdrGetProcedureAddress(). https://gitlab.winehq.org/wine/wine/-/merge_requests/7

3 8

Re: [PATCH v2 0/8] MR6427: winevulkan: Introduce a vulkan object structure.
by Rémi Bernon (＠rbernon) 23 Nov '24

23 Nov '24

On Wed Sep 4 18:06:48 2024 +0000, Jacek Caban wrote: > Actually, depending on other design details, win32u may sometimes need > client handle, but then the same concerns apply as against the host handle. What would you think of an interface in `wine/vulkan_driver.h` like this one: ```c struct vulkan_client_object { /* Special section in each dispatchable object for use by the ICD loader for * storing dispatch tables. The start contains a magical value '0x01CDC0DE'. */ UINT64 loader_magic; UINT64 unix_handle; }; #ifdef WINE_UNIX_LIB struct vulkan_object { UINT64 host_handle; UINT64 client_handle; struct vulkan_object *parent; struct rb_entry entry; }; #define VULKAN_OBJECT_HEADER( type, name, parent_type, parent_name ) \ union { \ struct vulkan_object obj; \ struct { \ union { type name; UINT64 handle; } host; \ union { type name; UINT64 handle; } client; \ parent_type *parent_name; \ }; \ } static inline void vulkan_object_init( struct vulkan_object *obj, struct vulkan_object *parent, UINT64 host_handle, struct vulkan_client_object *client ) { obj->host_handle = (UINT_PTR)host_handle; obj->client_handle = client ? (UINT_PTR)client : (UINT_PTR)obj; obj->parent = parent; if (client) client->unix_handle = (UINT_PTR)obj; } static inline void vulkan_object_init_ptr( struct vulkan_object *obj, struct vulkan_object *parent, void *host_handle, struct vulkan_client_object *client ) { vulkan_object_init( obj, parent, (UINT_PTR)host_handle, client ); } struct vulkan_instance { VULKAN_OBJECT_HEADER( VkInstance, instance, void, unused ); struct vulkan_instance_funcs funcs; void (*p_insert_object)( struct vulkan_instance *instance, struct vulkan_object *obj ); void (*p_remove_object)( struct vulkan_instance *instance, struct vulkan_object *obj ); }; static inline struct vulkan_instance *vulkan_instance_from_handle( VkInstance handle ) { struct vulkan_client_object *client = (struct vulkan_client_object *)handle; return (struct vulkan_instance *)(UINT_PTR)client->unix_handle; } struct vulkan_physical_device { VULKAN_OBJECT_HEADER( VkPhysicalDevice, physical_device, struct vulkan_instance, instance ); }; static inline struct vulkan_physical_device *vulkan_physical_device_from_handle( VkPhysicalDevice handle ) { struct vulkan_client_object *client = (struct vulkan_client_object *)handle; return (struct vulkan_physical_device *)(UINT_PTR)client->unix_handle; } struct vulkan_device { VULKAN_OBJECT_HEADER( VkDevice, device, struct vulkan_physical_device, physical_device ); struct vulkan_device_funcs funcs; }; static inline struct vulkan_device *vulkan_device_from_handle( VkDevice handle ) { struct vulkan_client_object *client = (struct vulkan_client_object *)handle; return (struct vulkan_device *)(UINT_PTR)client->unix_handle; } struct vulkan_queue { VULKAN_OBJECT_HEADER( VkQueue, queue, struct vulkan_device, device ); }; static inline struct vulkan_queue *vulkan_queue_from_handle( VkQueue handle ) { struct vulkan_client_object *client = (struct vulkan_client_object *)handle; return (struct vulkan_queue *)(UINT_PTR)client->unix_handle; } struct vulkan_surface { VULKAN_OBJECT_HEADER( VkSurfaceKHR, surface, struct vulkan_instance, instance ); }; static inline struct vulkan_surface *vulkan_surface_from_handle( VkSurfaceKHR handle ) { return (struct vulkan_surface *)(UINT_PTR)handle; } struct vulkan_swapchain { VULKAN_OBJECT_HEADER( VkSwapchainKHR, swapchain, struct vulkan_surface, surface ); }; static inline struct vulkan_swapchain *vulkan_swapchain_from_handle( VkSwapchainKHR handle ) { return (struct vulkan_swapchain *)(UINT_PTR)handle; } struct vulkan_funcs { /* Vulkan global functions. These are the only calls at this point a graphics driver * needs to provide. Other function calls will be provided indirectly by dispatch * tables part of dispatchable Vulkan objects such as VkInstance or vkDevice. */ PFN_vkGetDeviceProcAddr p_vkGetDeviceProcAddr; PFN_vkGetInstanceProcAddr p_vkGetInstanceProcAddr; /* winevulkan specific functions */ const char *(*p_get_host_surface_extension)(void); }; /* interface between win32u and the user drivers */ struct vulkan_driver_funcs { VkResult (*p_vulkan_surface_create)(HWND, VkInstance, VkSurfaceKHR *, void **); void (*p_vulkan_surface_destroy)(HWND, void *); void (*p_vulkan_surface_detach)(HWND, void *); void (*p_vulkan_surface_update)(HWND, void *); void (*p_vulkan_surface_presented)(HWND, void *, VkResult); VkBool32 (*p_vkGetPhysicalDeviceWin32PresentationSupportKHR)(VkPhysicalDevice, uint32_t); const char *(*p_get_host_surface_extension)(void); }; #endif /* WINE_UNIX_LIB */ ``` It's sharing the minimum required, each object has its own type but the macro is there to ensure a common header layout (mostly to simplify insert_object/remove_object, which can then take a simple object pointer), and the instance exports two function pointers to register object wrappers, regardless of where it is wrapped. With that I can move the surface/swapchain wrappers to win32u, while keeping only one level of indirection, while the other objects are still wrapped in winevulkan. It doesn't seem useful to move other wrappers to win32u for now, especially as some of them are more or less strongly coupled together: wine_instance uses the debug objects, wine_device_memory wrapper needs some info in the wine_phys_dev, etc. Also note that I'm thinking we could have an OpenXR icd upstream, similarly to winevulkan, for host OpenXR integration (and it'd make our life easier with Proton), and OpenXR is also interacting quite deeply with Vulkan, and would probably need to have access to the instance and device wrappers. This would mean either moving them somehow (and maybe all the wrappers) to some VK/XR shared win32u code, or use winevulkan as the XR icd too. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6427#note_88726

1 0

[PATCH v4 0/7] MR6892: dlls/propsys: Implement IPropertyDescription for several known system properties.
by Vibhav Pant (＠vibhavp) 23 Nov '24

23 Nov '24

This MR adds a very basic implementation of `IPropertyDescription` for system defined properties (i.e, the ones in \<propkey.h\>). This is needed to support the [`Properties`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation.properties?view=winrt-26100) method for `IDeviceInformation` in Windows.Devices.Enumeration (!6874). -- v4: dlls/propsys: Implement IPropertyDescription for several known system properties. dlls/propsys: Add IPropertyDescription stub for system defined properties. dlls/propsys/tests: Add conformance tests for PSGetNameFromPropertyKey. dlls/propsys: Add stubs for PSGetNameFromPropertyKey. dlls/propsys: Add stubs for PropertySystem. https://gitlab.winehq.org/wine/wine/-/merge_requests/6892

3 8

[PATCH v3 0/7] MR6892: dlls/propsys: Implement IPropertyDescription for several known system properties.
by Vibhav Pant (＠vibhavp) 23 Nov '24

23 Nov '24

This MR adds a very basic implementation of `IPropertyDescription` for system defined properties (i.e, the ones in \<propkey.h\>). This is needed to support the [`Properties`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation.properties?view=winrt-26100) method for `IDeviceInformation` in Windows.Devices.Enumeration (!6874). -- v3: dlls/propsys: Implement IPropertyDescription for several known system properties. dlls/propsys: Add IPropertyDescription stub for system defined properties. dlls/propsys/tests: Add conformance tests for PSGetNameFromPropertyKey. dlls/propsys: Add stubs for PSGetNameFromPropertyKey. dlls/propsys: Add stubs for PropertySystem. dlls/propsys/tests: Add conformance tests for PSGetPropertyKeyFromName. dlls/propsys/tests: Add conformance tests for getting PropertyDescriptions from PropertySystem. https://gitlab.winehq.org/wine/wine/-/merge_requests/6892

3 8

[PATCH 0/7] MR6892: dlls/propsys: Implement IPropertyDescription for several known system properties.
by Vibhav Pant (＠vibhavp) 23 Nov '24

23 Nov '24

This MR adds a very basic implementation of `IPropertyDescription` for system defined properties (i.e, the ones in \<propkey.h\>). This is needed to support the [`Properties`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation.properties?view=winrt-26100) method for `IDeviceInformation` in Windows.Devices.Enumeration (!6874). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6892

3 8

[PATCH 0/1] MR6891: cmd: Use CD /D to change directory in POPD (same as PUSHD)
by huangqinjin (＠huangqinjin) 23 Nov '24

23 Nov '24

Fixes https://bugs.winehq.org/show_bug.cgi?id=57137 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6891

3 2

[PATCH v20 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 23 Nov '24

23 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v20: timeout: add minimal test suite timeout: Windows 10 introduce the timeout command https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

3 3

[PATCH v2 0/2] MR6289: dsound: Reject NaN values in some functions.
by Aida Jonikienė (＠DodoGTA) 23 Nov '24

23 Nov '24

The tests aren't really tested though (they partially require interactive mode and they caused lag issues on one person's machine). -- v2: dsound/tests: Add NaN tests for floating-point 3D functions. dsound: Reject NaN values in floating-point 3D functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/6289

2 2

[PATCH v3 0/2] MR6884: Draft: Iphlpapi.dll: Included SendARP
by Thi Garlet (＠garlett) 23 Nov '24

23 Nov '24

Returns MAC address by: - search local interfaces, or - send UDP packed that does not need linux privilege, then search local cache solve https://bugs.winehq.org/show_bug.cgi?id=9418 files updated - /dlls/iphlpapi/iphlpapi_main.c - /dlls/iphlpapi/tests/iphlpapi.c -- v3: Returns MAC address by: https://gitlab.winehq.org/wine/wine/-/merge_requests/6884

3 3

[PATCH 0/1] MR6890: win32u: Use boolean instead of bool as name of a union member.
by Gerald Pfeifer (＠gerald) 23 Nov '24

23 Nov '24

bool is a reserved identifier in C23 and would break with GCC 15 moving to -std=gnu23 (based on C23). Use boolean instead. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6890

3 2

Re: [PATCH v5 0/1] MR5924: Draft: mfmediaengine: Implement SVR.
by Nikolay Sivov (＠nsivov) 22 Nov '24

22 Nov '24

Some things to test: * could we use sample allocator unconditionally? In other words, is it possible to get SVR used when no device manager was provided; * EVR has a circular buffer logic, so maybe we could copy from there; * it would be great if we could get rid of locking sample buffer for copies, and that should be possible if we always have d3d samples. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5924#note_88688

1 0

Re: [PATCH v5 0/1] MR5924: Draft: mfmediaengine: Implement SVR.
by Nikolay Sivov (＠nsivov) 22 Nov '24

22 Nov '24

Nikolay Sivov (@nsivov) commented about dlls/mfmediaengine/video_frame_sink.c: > + LONGLONG pts2; > + transfer_sample = TRUE; > + /* if the second sample we have is also OK, we'll drop the first and use the second */ > + sample_index_increment(&sample_read_index); > + if (sink->sample[sample_read_index] && sample_get_pts(sink->sample[sample_read_index], clocktime, &pts2) == S_OK) > + { > + *pts = pts2; > + IMFSample_Release(sink->sample[sink->sample_read_index]); > + sink->sample[sink->sample_read_index] = NULL; > + sink->sample_read_index = sample_read_index; > + } > + } > + else if (sink->presentation_sample && !sink->sample_presented) > + { > + hr = sample_get_pts(sink->presentation_sample, clocktime, pts); > + } I find this hard to understand. We'll need to document what's happening. For example, why does this check one more sample at all? Is that because buffer size is 2, or we always would check the adjacent one. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5924#note_88687

1 0

Re: [PATCH v5 0/1] MR5924: Draft: mfmediaengine: Implement SVR.
by Nikolay Sivov (＠nsivov) 22 Nov '24

22 Nov '24

Nikolay Sivov (@nsivov) commented about dlls/mfmediaengine/main.c: > { > media_engine_set_flag(engine, FLAGS_ENGINE_SHUT_DOWN, TRUE); > media_engine_clear_presentation(engine); > + /* critical section can not be held during shutdown, as shut down requires all pending > + * callbacks to complete, and some callbacks require this cs */ > + LeaveCriticalSection(&engine->cs); > IMFMediaSession_Shutdown(engine->session); > + EnterCriticalSection(&engine->cs); > } That's something else, unrelated to SVR work? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5924#note_88686

1 0

Re: [PATCH v5 0/1] MR5924: Draft: mfmediaengine: Implement SVR.
by Nikolay Sivov (＠nsivov) 22 Nov '24

22 Nov '24

Nikolay Sivov (@nsivov) commented about dlls/mfmediaengine/main.c: > > IMFMediaEngineNotify_EventNotify(engine->callback, MF_MEDIA_ENGINE_EVENT_ENDED, 0, 0); > break; > + > + case MEEndOfPresentation: > + video_frame_sink_notify_end_of_presentation(engine->presentation.frame_sink); > + break; I think you can use MFSTREAMSINK_MARKER_ENDOFSEGMENT for this. The way you did it sort of bypasses normal session flow, there is potentially unknown number of pending samples in the pipeline once MEEndOfPresentation is received. This is only a problem if for some reason earlier node somehow requests more times than the sink. ENDOFSEGMENT is already used in EVR, and that seems to work. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5924#note_88685

1 0

Re: [PATCH v5 0/1] MR5924: Draft: mfmediaengine: Implement SVR.
by Nikolay Sivov (＠nsivov) 22 Nov '24

22 Nov '24

Nikolay Sivov (@nsivov) commented about dlls/mfmediaengine/main.c: > > static void free_media_engine(struct media_engine *engine) > { > + EnterCriticalSection(&engine->cs); This helper is called when refcount is already 0, nothing else should be using it at this point. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5924#note_88684

1 0

Re: [PATCH v5 0/1] MR5924: Draft: mfmediaengine: Implement SVR.
by Nikolay Sivov (＠nsivov) 22 Nov '24

22 Nov '24

Nikolay Sivov (@nsivov) commented about dlls/mfmediaengine/video_frame_sink.c: > + IMFMediaType *current_media_type; > + BOOL is_shut_down; > + IMFMediaEventQueue *event_queue; > + IMFMediaEventQueue *stream_event_queue; > + IMFPresentationClock *clock; > + IMFAsyncCallback *callback; > + float rate; > + enum sink_state state; > + unsigned int flags; > + IMFSample *sample[2]; > + IMFSample *presentation_sample; > + int sample_write_index; > + int sample_read_index; > + BOOL sample_request_pending; > + BOOL sample_presented; > + BOOL eos; These could be "bool", we use that in several modules already. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5924#note_88683

1 0

Re: [PATCH v5 0/1] MR5924: Draft: mfmediaengine: Implement SVR.
by Nikolay Sivov (＠nsivov) 22 Nov '24

22 Nov '24

Nikolay Sivov (@nsivov) commented about dlls/mfmediaengine/video_frame_sink.c: > + return CONTAINING_RECORD(iface, struct video_frame_sink, IMFMediaEventGenerator_iface); > +} > + > +static struct video_frame_sink *impl_from_IMFStreamSink(IMFStreamSink *iface) > +{ > + return CONTAINING_RECORD(iface, struct video_frame_sink, IMFStreamSink_iface); > +} > + > +static struct video_frame_sink *impl_from_IMFMediaTypeHandler(IMFMediaTypeHandler *iface) > +{ > + return CONTAINING_RECORD(iface, struct video_frame_sink, IMFMediaTypeHandler_iface); > +} > + > +static void video_frame_sink_samples_release(struct video_frame_sink *sink) > +{ > + for (int i = 0; i < ARRAYSIZE(sink->sample); i++) ARRAY_SIZE is more common throughout the codebase. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5924#note_88682

1 0

Re: [PATCH v2 0/5] MR6879: dplayx: Connection caching. - approved
by Alexandre Julliard (＠julliard) 22 Nov '24

22 Nov '24

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

1 0

Re: [PATCH v4 0/7] MR6846: winex11: Misc tweaks to the emulated display mode support. - approved
by Alexandre Julliard (＠julliard) 22 Nov '24

22 Nov '24

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

1 0

Re: [PATCH v4 0/3] MR6882: secur32, urlmon, wininet: Fix some failing tests. - approved
by Alexandre Julliard (＠julliard) 22 Nov '24

22 Nov '24

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

1 0

Re: [PATCH v3 0/2] MR6868: win32u: Fix a couple of raw monitor DPI issues. - approved
by Alexandre Julliard (＠julliard) 22 Nov '24

22 Nov '24

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

1 0

Re: [PATCH v2 0/1] MR6880: gitlab: Wait for the fvwm process to start. - approved
by Alexandre Julliard (＠julliard) 22 Nov '24

22 Nov '24

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

1 0

Re: [PATCH v3 0/1] MR6881: kernel32/tests: Check for the _SW_INVALID bit presence only. - approved
by Alexandre Julliard (＠julliard) 22 Nov '24

22 Nov '24

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

1 0

Re: [PATCH v4 0/1] MR6523: wtsapi32: Handle WTSSessionInfo class in WTSQuerySessionInformationW(). - approved
by Alexandre Julliard (＠julliard) 22 Nov '24

22 Nov '24

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

1 0

[PATCH v3 0/1] MR6883: msxml3: Add indentation test.
by Orin Varley (＠ovarley1) 22 Nov '24

22 Nov '24

Adding a test to make sure the indentation of xml elements is a tab even after moving to another thread. To prevent regressions like the bug bellow. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57325 -- v3: msxml3: Add indentation test. https://gitlab.winehq.org/wine/wine/-/merge_requests/6883

3 2

[PATCH v5 0/5] MR6889: threadpoolwinrt: Implement IAsyncAction and IAsyncInfo.
by Vibhav Pant (＠vibhavp) 22 Nov '24

22 Nov '24

This MR adds an implementation for the `IAsyncAction` and `IAsyncInfo` interfaces exported by `Windows.System.Threading`, including support for setting `IAsyncActionCompletedHandler` values for an `IAsyncAction`. It also re-writes (or factors?) the `IAsyncOperation<boolean>` implementation in dlls/cryptowinrt to use `ThreadPoolStatics::RunAsync`, by introducing a type-punning variant of `AsyncOperationCompletedHandler<T>` (similar to `WineAsyncOperationCompletedHandler`), which is a wrapper around the `IAsyncAction` returned by `RunAsync`. The new `IAsyncOperation<T>` implementation is simpler, and if merged, can be exported to other dlls (windows.gaming.input and windows.security.credentials.ui.userconsentverifier for now). -- v5: cryptowinrt: Rewrite IAsyncOperation using Windows.System.Threading. https://gitlab.winehq.org/wine/wine/-/merge_requests/6889

4 8

[PATCH 0/5] MR6879: dplayx: Connection caching.
by Anton Baskanov (＠baskanov) 22 Nov '24

22 Nov '24

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

4 7

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Gabriel Ivăncescu (＠insn) 22 Nov '24

22 Nov '24

Ugh this was more complicated due to legacy DOCTYPEs being represented as comment elements. Since I added test (as assert was crashing) I implemented only get_data for them for now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88585

1 0

[PATCH v4 0/5] MR6889: threadpoolwinrt: Implement IAsyncAction and IAsyncInfo.
by Vibhav Pant (＠vibhavp) 22 Nov '24

22 Nov '24

This MR adds an implementation for the `IAsyncAction` and `IAsyncInfo` interfaces exported by `Windows.System.Threading`, including support for setting `IAsyncActionCompletedHandler` values for an `IAsyncAction`. It also re-writes (or factors?) the `IAsyncOperation<boolean>` implementation in dlls/cryptowinrt to use `ThreadPoolStatics::RunAsync`, by introducing a type-punning variant of `AsyncOperationCompletedHandler<T>` (similar to `WineAsyncOperationCompletedHandler`), which is a wrapper around the `IAsyncAction` returned by `RunAsync`. The new `IAsyncOperation<T>` implementation is simpler, and if merged, can be exported to other dlls (windows.gaming.input and windows.security.credentials.ui.userconsentverifier for now). -- v4: cryptowinrt: Rewrite IAsyncOperation using RunAsync from Windows.System.Threading. https://gitlab.winehq.org/wine/wine/-/merge_requests/6889

3 6

[PATCH v3 0/5] MR6889: threadpoolwinrt: Implement IAsyncAction and IAsyncInfo.
by Vibhav Pant (＠vibhavp) 22 Nov '24

22 Nov '24

This MR adds an implementation for the `IAsyncAction` and `IAsyncInfo` interfaces exported by `Windows.System.Threading`, including support for setting `IAsyncActionCompletedHandler` values for an `IAsyncAction`. It also re-writes (or factors?) the `IAsyncOperation<boolean>` implementation in dlls/cryptowinrt to use `ThreadPoolStatics::RunAsync`, by introducing a type-punning variant of `AsyncOperationCompletedHandler<T>` (similar to `WineAsyncOperationCompletedHandler`), which is a wrapper around the `IAsyncAction` returned by `RunAsync`. The new `IAsyncOperation<T>` implementation is simpler, and if merged, can be exported to other dlls (windows.gaming.input and windows.security.credentials.ui.userconsentverifier for now). -- v3: cryptowinrt: Rewrite IAsyncOperation using RunAsync from Windows.System.Threading. threadpoolwinrt: Implement put_Completed and get_Completed for IAsyncAction. threadpoolwinrt: Implement get_Id, get_Status, get_ErrorCode, Cancel, Close for IAsyncInfo. threadpoolwinrt: Implement GetResults() for IAsyncInfo. threadpoolwinrt/tests: Add conformance tests for setting IAsyncActionCompletedHandler handlers on an IAsyncAction. https://gitlab.winehq.org/wine/wine/-/merge_requests/6889

3 6

[PATCH v2 0/5] MR6889: threadpoolwinrt: Implement IAsyncAction and IAsyncInfo.
by Vibhav Pant (＠vibhavp) 22 Nov '24

22 Nov '24

This MR adds an implementation for the `IAsyncAction` and `IAsyncInfo` interfaces exported by `Windows.System.Threading`, including support for setting `IAsyncActionCompletedHandler` values for an `IAsyncAction`. It also re-writes (or factors?) the `IAsyncOperation<boolean>` implementation in dlls/cryptowinrt to use `ThreadPoolStatics::RunAsync`, by introducing a type-punning variant of `AsyncOperationCompletedHandler<T>` (similar to `WineAsyncOperationCompletedHandler`), which is a wrapper around the `IAsyncAction` returned by `RunAsync`. The new `IAsyncOperation<T>` implementation is simpler, and if merged, can be exported to other dlls (windows.gaming.input and windows.security.credentials.ui.userconsentverifier for now). -- v2: cryptowinrt: Rewrite IAsyncOperation using RunAsync from Windows.System.Threading. threadpoolwinrt: Implement put_Completed and get_Completed for IAsyncAction. threadpoolwinrt: Implement get_Id, get_Status, get_ErrorCode, Cancel, Close for IAsyncInfo. https://gitlab.winehq.org/wine/wine/-/merge_requests/6889

3 6

[PATCH 0/2] MR6888: Properly set exit code for default ctrl-c handlers.
by eric pouech (＠epo) 22 Nov '24

22 Nov '24

Stumbled upon this while reviewing MR!6869. It looks like default ctrl-c handlers return a given value. No app known to require this. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6888

3 3

[PATCH 0/1] MR6782: gdi32: Add support of monochrome bitmap to get_bitmap_info()
by AlexeyLushnikov (＠AlexeyLushnikov) 22 Nov '24

22 Nov '24

Emfdc.c. Function get_bitmap_info. Added filling of bmiColors for monochrome bitmaps when get_bitmap_info creates a new bitmap. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6782

3 4

[PATCH v19 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 22 Nov '24

22 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v19: timeout: add minimal test suite timeout: Windows 10 introduce the timeout command https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

4 5

[PATCH 0/1] MR6880: gitlab: Wait for the fvwm process to start.
by Rémi Bernon (＠rbernon) 22 Nov '24

22 Nov '24

I've seen some cases where the X server is a bit slow to start, and I suspect it could be a reason for some rare spurious test failures. Not 100% sure but at least this should be harmless and better than leaving it to chance. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6880

3 3

[PATCH 0/1] MR6884: Draft: Iphlpapi.dll: Included SendARP
by Thi Garlet (＠garlett) 22 Nov '24

22 Nov '24

Returns MAC address by: - search local interfaces, or - send UDP packed that does not need linux privilege, then search local cache solve https://bugs.winehq.org/show_bug.cgi?id=9418 files updated - /dlls/iphlpapi/iphlpapi_main.c - /dlls/iphlpapi/tests/iphlpapi.c -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6884

4 8

[PATCH v2 0/1] MR6883: msxml3: Add indentation test.
by Orin Varley (＠ovarley1) 22 Nov '24

22 Nov '24

Adding a test to make sure the indentation of xml elements is a tab even after moving to another thread. To prevent regressions like the bug bellow. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57325 -- v2: msxml3: Add indentation test. https://gitlab.winehq.org/wine/wine/-/merge_requests/6883

2 1

[PATCH v18 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 22 Nov '24

22 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v18: timeout: add minimal test suite https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

3 4

[PATCH v17 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 22 Nov '24

22 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v17: timeout: add minimal test suite https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

4 4

[PATCH 0/3] MR6855: server: Fix renaming file to a hardlink of itself.
by Gabriel Ivăncescu (＠insn) 22 Nov '24

22 Nov '24

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

3 13

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Gabriel Ivăncescu (＠insn) 22 Nov '24

22 Nov '24

Oh yeah I forgot about that. Quick test shows it doesn't. I guess I'll go with custom interface then and just forward. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88537

1 0

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Jacek Caban (＠jacek) 22 Nov '24

22 Nov '24

On Fri Nov 22 16:13:26 2024 +0000, Gabriel Ivăncescu wrote: > What about just using `IHTMLCommentElement2` for CharacterData's > interface, since it exposes the exact same props that it has? I mean > instead of the custom interface. Sounds better but should `QI(IHTMLCommentElement2)` succeeded on text nodes? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88536

1 0

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Gabriel Ivăncescu (＠insn) 22 Nov '24

22 Nov '24

On Fri Nov 22 16:09:59 2024 +0000, Jacek Caban wrote: > The ugly part of forwarding to `IHTMLDOMTextNode2` is that you need to > implement `IHTMLDOMTextNode2` in an object that's not a text node > (comment node). > With a private interface, we could give it a proper set of properties, > so no hooks would be needed, and just forward to it from both > `IHTMLDOMTextNode*` and `IHTMLCommentElement*` interfaces. We could even > share its entire implementation with something like: > ``` > struct HTMLCharacterData { > IHTMLCharacterData IHTMLCharacterData_iface; > DispatchEx *dispex; // used to forward IDispatch to comment's or > text node's dispex > nsIDOMCharacterData *character_data; // used for the actual implementation > }; > ``` > You could then embed it both in both comment and text node structs and > just use the single `IHTMLCharacterData` implementation. What about just using `IHTMLCommentElement2` for CharacterData's interface, since it exposes the exact same props that it has? I mean instead of the custom interface. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88535

1 0

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Jacek Caban (＠jacek) 22 Nov '24

22 Nov '24

On Fri Nov 22 15:47:04 2024 +0000, Gabriel Ivăncescu wrote: > Other than this, only CSS-related styles/stylesheets have a similar case > like this, but those are more convoluted. > I also don't see how introducing a private interface helps to simplify > it. We'd still have to expose it (and forward) in comment elements, but > now we'd also have to expose and forward it in text nodes, making it > actually less simple, IMO. > But is my forwarding a good idea? The ugly part of forwarding to `IHTMLDOMTextNode2` is that you need to implement `IHTMLDOMTextNode2` in an object that's not a text node (comment node). With a private interface, we could give it a proper set of properties, so no hooks would be needed, and just forward to it from both `IHTMLDOMTextNode*` and `IHTMLCommentElement*` interfaces. We could even share its entire implementation with something like: ``` struct HTMLCharacterData { IHTMLCharacterData IHTMLCharacterData_iface; DispatchEx *dispex; // used to forward IDispatch to comment's or text node's dispex nsIDOMCharacterData *character_data; // used for the actual implementation }; ``` You could then embed it both in both comment and text node structs and just use the single `IHTMLCharacterData` implementation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88534

1 0

[PATCH v15 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 22 Nov '24

22 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v15: timeout: add minimal test suite https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

3 3

[PATCH 0/1] MR6883: msxml3: Add indentation test.
by Orin Varley (＠ovarley1) 22 Nov '24

22 Nov '24

Adding a test to make sure the indentation of xml elements is a tab even after moving to another thread. To prevent regressions like the bug bellow. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57325 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6883

3 5

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Gabriel Ivăncescu (＠insn) 22 Nov '24

22 Nov '24

On Fri Nov 22 15:44:33 2024 +0000, Jacek Caban wrote: > Yeah, it shows that those interfaces do not reflect prototypes. In a > sense, `IHTMLDOMTextNode2` is as bad for `CharacterData` as > `IHTMLCommentElement2`. Do we have a lot of cases like that? I'm > wondering if we need to change the mechanism or could we just introduce > a private `IHTMLCharacterData` interface. Other than this, only CSS-related styles/stylesheets have a similar case like this, but those are more convoluted. I also don't see how introducing a private interface helps to simplify it. We'd still have to expose it (and forward) in comment elements, but now we'd also have to expose and forward it in text nodes, making it actually less simple, IMO. But is my forwarding a good idea? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88530

1 0

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Jacek Caban (＠jacek) 22 Nov '24

22 Nov '24

On Fri Nov 22 15:40:33 2024 +0000, Gabriel Ivăncescu wrote: > On second thought maybe just forwarding to `IHTMLCommentElement2` would > be enough, but we still need the `IHTMLDOMTextNode2` so the prototype > works right? Yeah, it shows that those interfaces do not reflect prototypes. In a sense, `IHTMLDOMTextNode2` is as bad for `CharacterData` as `IHTMLCommentElement2`. Do we have a lot of cases like that? I'm wondering if we need to change the mechanism or could we just introduce a private `IHTMLCharacterData` interface. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88529

1 0

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Gabriel Ivăncescu (＠insn) 22 Nov '24

22 Nov '24

On Fri Nov 22 15:39:38 2024 +0000, Gabriel Ivăncescu wrote: > Interesting, but I'm not sure. The issue here is that these are in the > `CharacterDataPrototype`, not in the comment element itself. So, won't > they fail if we don't handle `IHTMLDOMTextNode2` when called on the > comment element? Since it's looked up by IID/DISPID pair, not name. > `IHTMLCommentElement2` might be used for legacy modes though, I guess I > will need to test it from C code to know. On second thought maybe just forwarding to `IHTMLCommentElement2` would be enough, but we still need the `IHTMLDOMTextNode2` so the prototype works right? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88528

1 0

[PATCH v3 0/3] MR6882: secur32, urlmon, wininet: Fix some failing tests.
by Rémi Bernon (＠rbernon) 22 Nov '24

22 Nov '24

Probably caused by some winehq.org HTTP server update, it now supports HTTP/2 and sends "Upgrade, Keep-Alive" connection strings (was "Keep-Alive" before). -- v3: wininet: Parse multi-token Connection strings for Keep-Alive. https://gitlab.winehq.org/wine/wine/-/merge_requests/6882

3 6

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Gabriel Ivăncescu (＠insn) 22 Nov '24

22 Nov '24

On Fri Nov 22 15:33:09 2024 +0000, Jacek Caban wrote: > Shouldn't it be `IHTMLCommentElement2` instead? Interesting, but I'm not sure. The issue here is that these are in the `CharacterDataPrototype`, not in the comment element itself. So, won't they fail if we don't handle `IHTMLDOMTextNode2` when called on the comment element? Since it's looked up by IID/DISPID pair, not name. `IHTMLCommentElement2` might be used for legacy modes though, I guess I will need to test it from C code to know. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88525

1 0

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Jacek Caban (＠jacek) 22 Nov '24

22 Nov '24

Jacek Caban (@jacek) commented about dlls/mshtml/htmlcomment.c: > struct HTMLCommentElement { > HTMLElement element; > IHTMLCommentElement IHTMLCommentElement_iface; > + IHTMLDOMTextNode IHTMLDOMTextNode_iface; > + IHTMLDOMTextNode2 IHTMLDOMTextNode2_iface; Shouldn't it be `IHTMLCommentElement2` instead? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88523

1 0

[PATCH v14 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 22 Nov '24

22 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v14: timeout: add minimal test suite https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

3 3

[PATCH v16 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 22 Nov '24

22 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v16: timeout: add minimal test suite https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

2 2

[PATCH v13 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 22 Nov '24

22 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v13: timeout: add minimal test suite https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

3 3

[PATCH v2 0/3] MR6882: secur32, urlmon, wininet: Fix some failing tests.
by Rémi Bernon (＠rbernon) 22 Nov '24

22 Nov '24

Probably caused by some winehq.org HTTP server update, it now supports HTTP/2 and sends "Upgrade, Keep-Alive" connection strings (was "Keep-Alive" before). -- v2: wininet: Parse multi-token Connection strings for Keep-Alive. https://gitlab.winehq.org/wine/wine/-/merge_requests/6882

2 5

[PATCH v12 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 22 Nov '24

22 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v12: timeout: add minimal test suite https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

3 3

[PATCH v11 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 22 Nov '24

22 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v11: timeout: add minimal test suite timeout: Windows 10 introduce the timeout command https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

3 3

[PATCH 0/3] MR6882: secur32, urlmon, wininet: Fix some failing tests.
by Rémi Bernon (＠rbernon) 22 Nov '24

22 Nov '24

Probably caused by some winehq.org HTTP server update, it now supports HTTP/2 and sends "Upgrade, Keep-Alive" connection strings (was "Keep-Alive" before). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6882

3 5

[PATCH v10 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 22 Nov '24

22 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v10: timeout: add minimal test suite timeout: Windows 10 introduce the timeout command https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

3 3

[PATCH v3 0/1] MR6523: wtsapi32: Handle WTSSessionInfo class in WTSQuerySessionInformationW().
by Pétur Runólfsson (＠petur) 22 Nov '24

22 Nov '24

-- v3: wtsapi32: Handle WTSSessionInfo class in WTSQuerySessionInformationW(). https://gitlab.winehq.org/wine/wine/-/merge_requests/6523

3 3

[PATCH v2 0/1] MR6881: kernel32/tests: Check for the _SW_INVALID bit presence only.
by Rémi Bernon (＠rbernon) 22 Nov '24

22 Nov '24

-- v2: kernel32/tests: Check for the _SW_INVALID bit presence only. https://gitlab.winehq.org/wine/wine/-/merge_requests/6881

2 1

[PATCH 0/1] MR6881: kernel32/tests: Add a todo_wine for _statusfp returning _SW_INVALID bit.
by Rémi Bernon (＠rbernon) 22 Nov '24

22 Nov '24

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

2 2

[PATCH v2 0/1] MR6838: msi: Dynamically determine supported package architectures.
by Billy Laws (＠bylaws) 22 Nov '24

22 Nov '24

I wish there was a nicer way to do this, but SystemSupportedProcessorArchitectures is incomplete on ARM64EC even on Windows so there isn't really a cleaner way I can find. -- v2: msi: Dynamically determine supported package architectures. https://gitlab.winehq.org/wine/wine/-/merge_requests/6838

4 3

[PATCH v9 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 22 Nov '24

22 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v9: timeout: add minimal test suite https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

4 9

[PATCH v2 0/2] MR6868: win32u: Fix a couple of raw monitor DPI issues.
by Rémi Bernon (＠rbernon) 22 Nov '24

22 Nov '24

-- v2: win32u: Map cursor pos to raw DPI before calling drivers SysCommand. win32u: Check if parent is the desktop window in get_win_monitor_dpi. https://gitlab.winehq.org/wine/wine/-/merge_requests/6868

2 3

[PATCH v3 0/7] MR6846: winex11: Misc tweaks to the emulated display mode support.
by Rémi Bernon (＠rbernon) 22 Nov '24

22 Nov '24

This fixes window size being broken when dragged over multiple monitors with different scales and adds support for padded fullscreen windows when physical display mode aspect ratio doesn't match the emulated one. -- v3: winex11: Remove now unnecessary WindowPosChanged re-entry guards. winex11: Update the Win32 window state outside of event handlers. user32/tests: Workaround a FVWM maximized window state bug. winex11: Delay window config request when restoring from fullscreen/maximized. winex11: Avoid sending WM_WINDOWPOSCHANGING when applying window manager config. winex11: Generate GravityNotify events instead of ConfigureNotify. winex11: Introduce a new get_window_state_updates helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/6846

2 8

[PATCH 0/1] MR5925: d2d: Added support for DXGI_FORMAT_R8G8B8A8_UNORM on wic render targets
by Agustin Principe (＠principeagustin) 21 Nov '24

21 Nov '24

Added suppot for DXGI_FORMAT_R8G8B8A8_UNORM to d2d_wic_render_target_init. For further testing i can provide and .exe that renders a red circle over a blue background. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5925

4 5

Re: [PATCH v4 0/1] MR6875: mshtml: Set the name of the non-function constructors to the same as the object. - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

Re: [PATCH v2 0/1] MR6872: threadpoolwinrt: Associate work items with the appropriate TP_CALLBACK_ENVIRON. - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

Re: [PATCH v2 0/1] MR6870: threadpoolwinrt: Fix potential NULL dereference in QueryInterface for IAsyncAction. - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

Re: [PATCH v3 0/1] MR6735: msxml3: Undo removal of xmlThrDefTreeIndentString - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

Re: [PATCH v6 0/3] MR4794: comctl32/combo: Add tests for keypresses showing search functionality - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

Re: [PATCH v2 0/2] MR6876: d2d1/tests: Add some tests for WIC target formats. - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

Re: [PATCH v7 0/4] MR6835: wintrust: Implement support for CryptCATAdminAcquireContext2 and CryptCATAdminCalcHashFromFileHandle2 - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

Re: [PATCH v2 0/1] MR6871: winevulkan: Update to VK spec version 1.3.302. - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

Re: [PATCH v2 0/5] MR6863: winex11: Use more of the new state tracker and make initial window properties changes asynchronous too. - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

Re: [PATCH v2 0/1] MR6867: kernel32: Add GetCurrentPackageInfo() stub. - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

Re: [PATCH v3 0/3] MR6830: icmui: Add SetupColorMatchingW() stub. - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

Re: [PATCH v10 0/2] MR6059: mf: Retry PROCESSINPUTNOTIFY if TRANSFORM_TYPE_NOT_SET is returned. - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

Re: [PATCH v10 0/6] MR6640: propsys: Support converting to BSTR for PropVariantToVariant. - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

Re: [PATCH v5 0/2] MR6787: wineps.drv: Use locale aware variants _sprintf_l and _sscanf_l. (ASan) - approved
by Alexandre Julliard (＠julliard) 21 Nov '24

21 Nov '24

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

1 0

[PATCH v3 0/1] MR6875: mshtml: Set the name of the non-function constructors to the same as the object.
by Gabriel Ivăncescu (＠insn) 21 Nov '24

21 Nov '24

-- v3: mshtml: Set the name of the non-function constructors to the same as https://gitlab.winehq.org/wine/wine/-/merge_requests/6875

3 2

2025

2024

2023

2022

wine-gitlab