https://bugs.winehq.org/show_bug.cgi?id=56801
Bug ID: 56801 Summary: Invalid path to UIAutomationCore.dll in the registry Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: oleaut32 Assignee: wine-bugs@winehq.org Reporter: rikul@inbox.ru Distribution: ---
Created attachment 76604 --> https://bugs.winehq.org/attachment.cgi?id=76604 test app
I'm using the pywinauto library to perform some automatic actions in a GUI. pywinauto, in turn, uses comtypes, which requires the location of UIAutomationCore.dll to work. During this process, comtypes reports that it cannot find UIAutomationCore.dll.
It turns out that, comtypes uses windll.oleaut32.QueryPathOfRegTypeLib (that is, the QueryPathOfRegTypeLib from oleaut32.dll) to find UIAutomationCore.dll.
Wine 9.0 registry [HKEY_CLASSES_ROOT\Typelib{8A9CA8EB-856B-43D9-ABD7-4A590054064F}\1.0\0\win64] lists its location as "C:\windows\system32\uiautomationcore.dll\1", while the path in Wine 8.0 is C:\windows\system32\uiautomationcore.dll.
Windows registry shows path as C:\windows\system32\uiautomationcore.dll
Can the correctness of this behavior be verified? Should it be "C:\windows\system32\uiautomationcore.dll\1" (\1 at the end) or is this the wrong value?
I have attached a test application that reports the guid and path from the registry.
https://bugs.winehq.org/show_bug.cgi?id=56801
Levon l@laa.am changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |l@laa.am
https://bugs.winehq.org/show_bug.cgi?id=56801
--- Comment #1 from BugSeeker rikul@inbox.ru --- The described behavior has been observed since this commit: https://gitlab.winehq.org/wine/wine/-/commit/88a1e949718cfbffedc46a63a8ad7da... .
https://bugs.winehq.org/show_bug.cgi?id=56801
BugSeeker rikul@inbox.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|oleaut32 |uiautomationcore Version|9.0 |8.3
https://bugs.winehq.org/show_bug.cgi?id=56801
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |dark.shadow4@web.de Status|UNCONFIRMED |NEW
--- Comment #2 from Fabian Maurer dark.shadow4@web.de --- Not 100% sure myself, but it does look like a bug.
https://bugs.winehq.org/show_bug.cgi?id=56801
--- Comment #3 from Nikolay Sivov bunglehead@gmail.com --- Those numbers indicate resource id, in case you have multiple libraries. Maybe QueryPathOfRegTypeLib() should strip those.
https://bugs.winehq.org/show_bug.cgi?id=56801
--- Comment #4 from BugSeeker rikul@inbox.ru --- (In reply to Nikolay Sivov from comment #3)
Those numbers indicate resource id, in case you have multiple libraries. Maybe QueryPathOfRegTypeLib() should strip those.
Yes, this may solve the problem, but on Windows the behavior is slightly different. In Windows, the registry itself already has a path without an identifier for the guid {944DE083-8FB8-45CF-BCB7-C477ACB2F897}, which is determined using LoadTypeLibEx => GetLibAttr => guid (see attached source code of example), and there are also other guids where identifiers already exist. set in values.
I believe that in order not to break anything else, it is worth implementing similarly to Windows and having one default guid that will store the path without any identifiers.
-
WineHQ Bugzilla