http://bugs.winehq.org/show_bug.cgi?id=59522 Esme Povirk <madewokherd@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com --- Comment #1 from Esme Povirk <madewokherd@gmail.com> --- It's not clear to me why a stub returning S_OK would cause a deadlock. If the problem is COM marshaling, changing the implementation won't affect that. You might just need to switch the object to a free-threaded model. I think the desktop integration will have to live in the user driver, as I don't see how else one could properly map an HWND to whatever object needs to be adjusted, without baking in the assumption that it has something to do with .desktop shortcuts. Mapping an HWND to an "application" is a much larger problem that we don't currently have a solution for. Windows has a concept of "App User Model IDs" (https://learn.microsoft.com/en-us/windows/win32/shell/appids) which are string values that identify an "application". I don't think these are exposed through the Windows API, so we can't test them directly. This ID can then be mapped to a .lnk shortcut, or a shortcut can be created when a user decides to "pin" an application to the start menu or taskbar. Last I looked into this, Linux desktops used a daemon called "BAMF" (https://launchpad.net/bamf) to do something similar. IMO, the ideal is for win32u to know the App User Model ID of each window and send it to the user driver, which would use that to map HWND to .desktop file and pass that information along to BAMF. But this would be a big project, and I doubt it's needed for your purposes. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.