[Bug 46466] New: Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism
https://bugs.winehq.org/show_bug.cgi?id=46466 Bug ID: 46466 Summary: Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism Product: Wine Version: 4.0-rc6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: reinhold.hoffmann(a)hotmail.com Distribution: --- For more than 10 years a brilliant blog exists how to start a 32-bit DLL from an x64 application. This sound weird but in case a DLL cannot be converted to 64-bit for whatever reason such a solution is very helpful. In the blog there is a method described how to do this. The blog is very sophistcated. Please see https://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/ On Windows accessing a DLL through the COM IPC mechanism works like a charm. On Wine64 a 32-bit DLL can only be accessed and executed from a 32-bit app through a COM IPC mechanism (btw. works great). But accessing the 32-bit DLL through a COM IPC mechanism from the same x64 version of such an app fails. Of course, such a capability is beyond Wine-4.0. But it would be great if a fix could be addressed in the scope of Wine-5.0. I try to provide a sample which demonstrate the issue. May be somebody familiar with the COM IPC mechnism may help to address the right component. Thx. Reinhold -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46466 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #1 from Fabian Maurer <dark.shadow4(a)web.de> --- Can you provide a program depending on this functionality? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46466 --- Comment #2 from Reinhold <reinhold.hoffmann(a)hotmail.com> --- Created attachment 63288 --> https://bugs.winehq.org/attachment.cgi?id=63288 Demo for bug 46466 Please read the file "Readme_Demo_for_COMServer_bug_46466.txt" first. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46466 --- Comment #3 from Reinhold <reinhold.hoffmann(a)hotmail.com> --- Thx for the immediate response. Please find a demo package in the zip file. At first please read the file "Readme_Demo_for_COMServer_bug_46466.txt" VERY IMPORTANT The COMServer.exe modifies the Registry as described in "Registry_Values_of_COMServer.txt" which can be removed executing the command as described in section 5. of the Readme file. I believe that the bug is that an 64-app cannot access 32-bit instances calling CreateInstance Could be that it is really not a big deal to fix that because the complete implementation of CoInitialize, CreateInstance, CoUninitialize works fine but just for one side (either 32-bit or 64-bit) but interworkng between these two worlds fails. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46466 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords| |download, source --- Comment #4 from Fabian Maurer <dark.shadow4(a)web.de> --- Thanks for the sample, makes debugging a lot easier! To me it sounds like an easy fix, CoCreateInstance needs to also search Wow6432Node for classes. When you add another registry entry for the same dll but outside of the wow64 node, it works just fine. After codefreeze I can try to write a few tests and a fix for this. In the meantime, as I said, just copy the registry entries it adds under Wow6432Node directly under "Classes". -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46466 --- Comment #5 from Nikolay Sivov <bunglehead(a)gmail.com> --- The problem is not just about locating the dll in registry, but using auxiliary host process in case of arch mismatch. CoCreateInstance() also supports flags to explicitly specify which module you want. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46466 --- Comment #6 from Reinhold <reinhold.hoffmann(a)hotmail.com> --- Created attachment 63289 --> https://bugs.winehq.org/attachment.cgi?id=63289 Demo with CoCreateInstance and explicitely specified architecture I tried ===================================================================================== IServerWrapperPtr ptr = NULL; HRESULT hr = CoCreateInstance(__uuidof(ServerWrapper), NULL, CLSCTX_LOCAL_SERVER | CLSCTX_ACTIVATE_32_BIT_SERVER, __uuidof(IServerWrapperPtr), reinterpret_cast<void**>(&ptr)); ===================================================================================== (please find attacted "ClientModified_001.cpp" and the accordingly built "ClientModified_x64_001.exe") where I explicitely specified architecture. This works fine on Windows but on Wine the result is still REGDB_E_CLASSNOTREG = 0x80040154L Or do I do something wrong here (additional flags required)? Please let me know if there is a way in the current Wine-4.0 where it may work or confirm the bug report. If there is anything more that I can provide, please let me know. Again, many thx for immediately providing comments. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46466 --- Comment #7 from Reinhold <reinhold.hoffmann(a)hotmail.com> --- Just a further comment. I used the parameter according to https://docs.microsoft.com/en-us/windows/desktop/api/wtypesbase/ne-wtypesbas... see table at the bottom of that page. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46466 --- Comment #8 from Fabian Maurer <dark.shadow4(a)web.de> --- As already noted, it works when adding registry entries into the 64bit registry. CLSCTX_ACTIVATE_32_BIT_SERVER is not checked by wine, so this won't help. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46466 --- Comment #9 from Nikolay Sivov <bunglehead(a)gmail.com> --- I'm not saying it will help, but it's more than registry access. It won't help you if you have 32-bit server, and 64-bit client. Or did you verify that it works for out-of-proc case already in wine? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46466 --- Comment #10 from Fabian Maurer <dark.shadow4(a)web.de> --- (In reply to Nikolay Sivov from comment #9)
I'm not saying it will help, but it's more than registry access. It won't help you if you have 32-bit server, and 64-bit client. Or did you verify that it works for out-of-proc case already in wine?
Well, we have the sample attached here, and I got it to work using the x64 client and the 32bit COMServer.exe. Isn't that enough? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46466 --- Comment #11 from Reinhold <reinhold.hoffmann(a)hotmail.com> --- Yeah. Got it working, too. Also our product works great now. -------------------------------------------- What I did in details (in case of the Demo): --------------------------------------------
From the keys in att.#1 "COMServer.zip" file "Registry_Values_of_COMServer.txt" I just exported the key and all the values of the 32-bit part
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{AE14D6C6-2E7E-484D-A621-E62611B75B42} converted it to the 64-bit part HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{AE14D6C6-2E7E-484D-A621-E62611B75B42} (Notice: took out Wow6432Node) and imported it to the Registry. -------------------------------------------- For our product I did the similar change. Also our product works great now. I am not sure if this is sufficient for every case and for every situation. But for us for the time being we can add a specific Registry change to our installer for an installation on Wine until a final solution of #46466 will be available. Thx a lot for your help and taking the time to investigate this complex area so fast. With this solution a major issue is resolved for us now. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46466 Aaron Franke <arnfranke(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arnfranke(a)yahoo.com --- Comment #12 from Aaron Franke <arnfranke(a)yahoo.com> --- Is this related to Codeweavers's recent work with Crossover 19 allowing running 32-bit apps in a 64-bit-only environment? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46466 --- Comment #13 from Nikolay Sivov <bunglehead(a)gmail.com> --- (In reply to Aaron Franke from comment #12)
Is this related to Codeweavers's recent work with Crossover 19 allowing running 32-bit apps in a 64-bit-only environment?
No, it's unrelated. -- 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.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla