November 2024 - Wine-GitLab

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

Nov. 23, 2024

-- 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ė Nov. 23, 2024

Nov. 23, 2024

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

1 5

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

Nov. 23, 2024

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) Nov. 23, 2024

Nov. 23, 2024

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) Nov. 23, 2024

Nov. 23, 2024

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 Nov. 23, 2024

Nov. 23, 2024

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) Nov. 23, 2024

Nov. 23, 2024

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) Nov. 23, 2024

Nov. 23, 2024

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) Nov. 23, 2024

Nov. 23, 2024

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) Nov. 23, 2024

Nov. 23, 2024

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

3 2