https://bugs.winehq.org/show_bug.cgi?id=50279
Bug ID: 50279 Summary: Registration free COM Product: Wine Version: 6.0-rc1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs@winehq.org Reporter: bvandermerwe@kbcat.com Distribution: ---
Created attachment 68829 --> https://bugs.winehq.org/attachment.cgi?id=68829 Appx.exe.manifest
At first I thought wine does not support registration free COM, but according to bug 25340 it does, and should be working. However, it does not work in some situations.
Consider a 32 bit Windows application (composed of one small EXE and many linked DLLs), which has the attached manifest file embedded via:
mt.exe /manifest Appx.exe.manifest /outputresource:Appx.exe;#1
Now in the 32 bit application you have this C++ code:
hr = ::CoCreateInstance(CLSID_KCUnitop, NULL, CLSCTX_INPROC_SERVER, IID_IKCUnitopSimulation, (void**)&m_pKCHunitopSimulation);
Then it fails saying the component is not registered. CLSID_KCUnitop comes from:
MIDL_DEFINE_GUID(CLSID, CLSID_KCUnitop,0xC4203DFD,0x03FA,0x11D3,0x9B,0xC7,0x00,0x50,0x04,0x09,0xFB,0x41);
This corresponds to the second comclass entry in the manifest file:
<file name="kcunitop.dll"> <comClass clsid="{27345ECA-2B0E-11D3-BF76-0090271CC18F}" threadingModel="Apartment"/> <comClass clsid="{C4203DFD-03FA-11D3-9BC7-00500409FB41}" threadingModel="Apartment"/> </file>
Registering the dll first using 'regsvr32 kcunitop.dll' does work around the issue.
Sadly, I cannot provide the entire application. Perhaps the person who works on this component can read through this and go "Ah we need to check for more than one comClass entry" or "Oh you have curly brackets which we need to ignore" or "Ah the #1 is causing it to not find the manifest" or "The leading 0 is causing isses". (one can hope :-) )
I tried wine 5.0 onwards through 6.0 and the behavior is the same in all of them.
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- Please attach +ole,+actctx,+loaddll log when it fails.
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #2 from Ben bvandermerwe@kbcat.com --- Created attachment 68846 --> https://bugs.winehq.org/attachment.cgi?id=68846 Trace log file
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #3 from Ben bvandermerwe@kbcat.com --- I have attached the log when it fails. Of interest, and I am guessing, please note: Line 10: It parses the manifest file in the exe Line 18: It notices kcunitop.dll in there.
If you search for the GUID C4203DFD, around line 40285 for example, you will see that it decides that nothing is registered.
Note that the exe manifest contains the registration COM free line for the COM component, but it is being cocreated in another dll which is automatically loaded when the exe is loaded. I don't know if that is maybe the issue under wine?
Maybe line 18 should contain more information about the item?
https://bugs.winehq.org/show_bug.cgi?id=50279
Ben bvandermerwe@kbcat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Registration free COM |Registration free COM fails
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #4 from Nikolay Sivov bunglehead@gmail.com --- I think this part could be a problem:
--- 0078:trace:actctx:lookup_assembly looking for name=L"KBC.Historian" version=7.1.0.0 arch=L"x86" 0078:trace:actctx:get_manifest_in_pe_file looking for res #0001 in L"\??\c:\program files (x86)\KBC\sim suite 7.1\PSIM\KBC.Historian.dll" 0078:trace:actctx:get_manifest_in_module looking for res #0001 in module 0x230001 L"\??\c:\program files (x86)\KBC\sim suite 7.1\PSIM\KBC.Historian.dll" 0078:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"KBC.Historian" (7.1.0.0) ---
Does it exist under that path? Please attach the manifest from this dll.
Also I'm sure how accurate is this:
--- 0078:trace:actctx:parse_assembly_identity_elem name=L"KBC.Historian" version=7.1.0.0 arch=L"x86" ---
Application manifest you attached has version 7.3.0.0 and different arch. Also the log contains wine-stable paths, was that wine-5.0? If problem happens in latest wine-6.0-rc1, it's better to use that for testing.
So to summarize:
- some clarification on assembly dependency is needed; - manifest you posted does not seem to match the one used when generating the log, which might be because both 32/64 builds were used.
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #5 from Ben bvandermerwe@kbcat.com --- Ignore KBC.Historian.DLL, it is never loaded, the applicaton can function without it, it is fine if it fails. It is a .NET COM component, not registered.
Please focus on the kcunitop.dll. You can clearly see it in the manifest and the trace log file, and if you search for its GUID C4203DFD you can see in the trace file where the cocrete fails.
The manifest I attached is accurate, but I renamed a few of the DLLs in there for anonimity (so the KC.Historian is really KBC.Historian).
Please note that only the EXE has a manifest, anything else doesnt, unless it is a small dummy one automatically created by the compiler or something. The EXE manifest lists the registration free COM components:
<file name="kcunitop.dll"> <comClass clsid="{27345ECA-2B0E-11D3-BF76-0090271CC18F}" threadingModel="Apartment"/> <comClass clsid="{C4203DFD-03FA-11D3-9BC7-00500409FB41}" threadingModel="Apartment"/> </file>
But cocreateinstance using the second fails. It either does not get it from the manifest, or looks in the manifest for the DLL which calls cocreateinstance and does not also loo at the exe manifest. I am guessing.
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com --- Thing is, I think what happens is that context creation fails because of inaccessible dependency. So it does not matter if comClass elements are parsed correctly, they won't be used if context wasn't created. You can easily verify with +relay log, looking for STATUS_SXS_CANT_GEN_ACTCTX status from RtlCreateActivationContext().
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #7 from Ben bvandermerwe@kbcat.com --- Hi Nikolay, it appears that you are correct! *puts you on my Christmas list* If I modify the manifest and remove these lines:
<dependency> <dependentAssembly> <assemblyIdentity name="KBC.Historian" version="7.3.0.0" processorArchitecture="amd64"/> </dependentAssembly> </dependency> <dependency> <dependentAssembly> <assemblyIdentity name="KBC.Workflow" version="7.3.0.0" publicKeyToken="d1d331cb83dd8fde" processorArchitecture="msil"/> </dependentAssembly> </dependency>
Then it works even with the COM components unregistered. That helps and moves this forward. But it would be nice to be able to run this application without jumping through hoops and things.
The above two dependencies do exist as DLLs, so there is a KC.Historian.dll, but it is a .NET dll. It does not get registered ever, as COM or in the GAC, but it gets invoked via SxS COM.
But KBC.Historian.dll certainly does exist. But we still get the line "0078:fixme:actctx:parse_depend_manifests" below? What can be done about that? In this case it would be sufficient just to do the minimum to create the context that fails? Is is just the parsing that does not cope?
FYI: I dislike that DLL, Purify, AQTime etc. all have conniptions over it. I shall confer with the developer in question to see if it can be changed to load on demand instead of something.
0078:trace:actctx:get_manifest_in_pe_file looking for res #0001 in L"\??\c:\program files (x86)\KBC\sim suite 7.1\PSIM\KBC.Historian.dll" 0078:trace:actctx:get_manifest_in_module looking for res #0001 in module 0x230001 L"\??\c:\program files (x86)\KBC\sim suite 7.1\PSIM\KBC.Historian.dll" 0078:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"KBC.Historian" (7.1.0.0)
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #8 from Ben bvandermerwe@kbcat.com --- As for why I use sudo so much:
headless@288a70c5e231:~$ wine cmd wine: /home/headless/.wine is not owned by you
And there may be chown I can run to fix that. But I am working on an Ubunutu linux docker container, and trust me, just getting it working so far has been a long road.
Thank you for all the help. WINE is awesome!
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #9 from Ben bvandermerwe@kbcat.com --- (In reply to Ben from comment #8)
As for why I use sudo so much:
headless@288a70c5e231:~$ wine cmd wine: /home/headless/.wine is not owned by you
And there may be chown I can run to fix that. But I am working on an Ubunutu linux docker container, and trust me, just getting it working so far has been a long road.
Thank you for all the help. WINE is awesome!
I like just need:
sudo chown -R $USER: ~/.wine
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #10 from Ben bvandermerwe@kbcat.com --- (In reply to Ben from comment #9)
(In reply to Ben from comment #8)
As for why I use sudo so much:
headless@288a70c5e231:~$ wine cmd wine: /home/headless/.wine is not owned by you
And there may be chown I can run to fix that. But I am working on an Ubunutu linux docker container, and trust me, just getting it working so far has been a long road.
Thank you for all the help. WINE is awesome!
I like just need:
sudo chown -R $USER: ~/.wine
Even so it still happens. I think the container was set up in some weird way that there are two "headless" users who are not the same, ugh, over my head. Works with sudo.
https://bugs.winehq.org/show_bug.cgi?id=50279
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1
--- Comment #11 from Nikolay Sivov bunglehead@gmail.com --- To summarize, if you remove <dependency> elements for modules that you don't actually have everything works? In this case it's likely an issue with manifest processing, rather than registration-free servers. Could you provide a minimal archive with some dll stubs in it, so we can test this on wine and windows?
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #12 from Ben bvandermerwe@kbcat.com --- That is correct. The manifest has:
<dependentAssembly> <assemblyIdentity name="KBC.Historian" version="7.3.0.0" processorArchitecture="amd64"/> </dependentAssembly> </dependency>
And KBC.Historian.dll is a .NET dll. Wine reports:
0078:trace:actctx:lookup_assembly looking for name=L"KBC.Historian" version=7.1.0.0 arch=L"x86" 0078:trace:actctx:get_manifest_in_pe_file looking for res #0001 in L"\??\c:\program files (x86)\KBC\sim suite 7.1\PSIM\KBC.Historian.dll" 0078:trace:actctx:get_manifest_in_module looking for res #0001 in module 0x230001 L"\??\c:\program files (x86)\KBC\sim suite 7.1\PSIM\KBC.Historian.dll" 0078:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"KBC.Historian" (7.1.0.0)
Even though that file definitely does exist. Why it has issues, I do not know.
But this failure causes the context to not be created. The application loads, but any side by side COM invocation, even for other DLLs, fails. It is as if the manifest is not there, you have to regsvr32 the COM components.
It looks to me like the context creation should not fail because of this. It is throwing the baby out with the bath water. If the application is going to run, which it does, do everything to make work what does work, create a context and use what you can from it.
So one snippet with issues in the manifest brings down the whole thing, that at least can be improved. Please save that baby! Only throw out the water, not the baby too!
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #13 from Ben bvandermerwe@kbcat.com --- As for a sample, I shall have to create one, may take a little time.
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #14 from Ben bvandermerwe@kbcat.com --- Attached is a small project that should reproduce the issue.
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #15 from Ben bvandermerwe@kbcat.com --- Created attachment 69162 --> https://bugs.winehq.org/attachment.cgi?id=69162 Small test project
https://bugs.winehq.org/show_bug.cgi?id=50279
--- Comment #16 from Nikolay Sivov bunglehead@gmail.com --- This test program opens same blank window on Windows, same as on Wine. How do I tell that it's working as intended?
-
WineHQ Bugzilla