On Wed, Feb 23, 2022 at 03:36:55PM +0300, Dmitry Timoshkov wrote:
Huw Davies huw@codeweavers.com wrote:
On Tue, Feb 22, 2022 at 05:49:54PM +0300, Dmitry Timoshkov wrote:
+int WINAPI wWinMain(HINSTANCE hinst, HINSTANCE previnst, LPWSTR cmdline, int showcmd) +{
- HRESULT hr;
- CLSID clsid;
- CoInitializeEx(NULL, COINIT_MULTITHREADED);
- hr = CLSIDFromString(cmdline, &clsid);
It looks like Windows uses the cmdline:
dllhost.exe /PROCESSID:{GUID}
MSDN's "Using the System-Supplied Surrogate" article https://docs.microsoft.com/en-us/windows/win32/com/using-the-system-supplied... and a pretty good guide for writing custom surrogate (which I follow in my work) https://docs.microsoft.com/en-us/windows/win32/com/writing-a-custom-surrogat... they both mention only "CLSID on the launch command line". Also the prototype patch attached to the bug https://bugs.winehq.org/show_bug.cgi?id=20296 passes just {GUID} on the command line.
Thanks for the links, I'll take a look.
Where do you see /PROCESSID mentioned for the surrogate process context? Also it's not clear to me that /PROCESSID belongs to the hosted object, and not something else, like really some process id.
I used Process Explorer on Win 10 to look at the command-lines of some running dllhost.exe instances. For the one handling the thumbnail cache, the guid matched the CLSID of the thumbnail cache server (and besides there was nothing else on the command-line, so it had to be that).
Also see: https://www.howtogeek.com/326462/what-is-com-surrogate-dllhost.exe-and-why-i...
Probably that's an internal implementation detail, and I'm open to use whatever is deemed to be appropriate.
Sure, but as it's easy enough to implement, I think we should follow Windows' behaviour.
Huw.