[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: [e-mail]
          Reporter: [e-mail]
      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

[Bug 46466] Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism

https://bugs.winehq.org/show_bug.cgi?id=46466

Fabian Maurer  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Fabian Maurer  ---
Can you provide a program depending on this functionality?

[Bug 46466] Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism

https://bugs.winehq.org/show_bug.cgi?id=46466

--- Comment #2 from Reinhold  ---
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.

[Bug 46466] Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism

https://bugs.winehq.org/show_bug.cgi?id=46466

--- Comment #3 from Reinhold  ---
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.

[Bug 46466] Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism

https://bugs.winehq.org/show_bug.cgi?id=46466

Fabian Maurer  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
           Keywords|                            |download, source

--- Comment #4 from Fabian Maurer  ---
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".

[Bug 46466] Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism

https://bugs.winehq.org/show_bug.cgi?id=46466

--- Comment #5 from Nikolay Sivov  ---
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.

[Bug 46466] Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism

https://bugs.winehq.org/show_bug.cgi?id=46466

--- Comment #6 from Reinhold  ---
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.

[Bug 46466] Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism

https://bugs.winehq.org/show_bug.cgi?id=46466

--- Comment #7 from Reinhold  ---
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.

[Bug 46466] Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism

https://bugs.winehq.org/show_bug.cgi?id=46466

--- Comment #8 from Fabian Maurer  ---
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.

[Bug 46466] Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism

https://bugs.winehq.org/show_bug.cgi?id=46466

--- Comment #9 from Nikolay Sivov  ---
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?

[Bug 46466] Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism

https://bugs.winehq.org/show_bug.cgi?id=46466

--- Comment #10 from Fabian Maurer  ---
(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?

[Bug 46466] Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism

https://bugs.winehq.org/show_bug.cgi?id=46466

--- Comment #11 from Reinhold  ---
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.

[Bug 46466] Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=46466

Aaron Franke  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #12 from Aaron Franke  ---
Is this related to Codeweavers's recent work with Crossover 19 allowing running
32-bit apps in a 64-bit-only environment?

[Bug 46466] Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=46466

--- Comment #13 from Nikolay Sivov  ---
(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.