Cross-Machine COM-Calls under Wine... (RePost from wine.user)

Robert Shearman rob at codeweavers.com
Wed Feb 22 10:15:52 CST 2006


Olaf Schmidt wrote:

>are working here, using our own implementation of a COM-based
>RPC-Server. Its speciality is the hosting of COM-Binaries, that
>don't have to be registered, to instantiate Classes and invoke Methods
>on them.
>  
>

I assume you mean cross-process COM calls? The D-part of DCOM is not 
currently supported.

>No Memory-Leaking, even under Stress (the server was able, to
>deliver max. 700 small COMRequsest per second, stressed from
>multiple Clients (XP-Box, comparable Hardware, reached ca. 2000).
>

Great!

>So
>Wine has ca. 3 times the Call-Overhead, regarding Object-Instantiation
>and Method-Invoking-By-Name. 
>

This is expected and it is on my todo list to fix this. However, I want 
to get more applications working first before I make the ones that do 
work faster!

>But the more realistic Recordset-Call
>was finished after 14ms, where the XP-Box needed 9ms - so for realistic
>Calls, we now see only factor 1.5 under Wine. And in the "Large-String-
>Reflection-Test" (2MB Up- and 4MB-Download) - Wine was a little bit
>faster than XP - good job, regarding your socket-bindings.
>Minimizing to the "KDE-SysTray", all was working; I was impressed.
>
>  
>

Brilliant!

>Now the bad news:  ;-)
>Not working was:
>1. Running as Service (Service-Registering was successful, but ...)
>   (Ok, no big problem, running as UserProcess was working, but
>    are there plans, to simulate the Win-ServiceControlmanager?)
>  
>

No. It doesn't really make sense at the moment. We don't recommend that 
Wine be run as root and we don't support impersonating other Unix users 
that would be necessary to maintain security in this environment.

>2. Win-Authentication and -Impersonation
>   (LogonUser- and ImpersonateLoggedOnUser-APIs - already mapped to...?)
>  
>

The probably both do nothing. Since you shouldn't be running as root, 
then this isn't a problem.

>3. "Global ServerSingletons" using ROT-Entries with FileMoniker-Binding
>  
>

Not supported yet. During a recent rewrite of the ROT implementation I 
made it easier to do this, but our midl replacement "widl" isn't quite 
at the point where this can be implemented yet. I can provide more 
details about the architecture of the ROT if you are interested.

>4. "RPCServer-internal Singletons" (CoMarshalInterThreadInterfaceInStream
>    and CoGetInterfaceAndReleaseStream against the IUnknown-Interface).
>  
>

I'm not sure what you mean here by "RPCServer-internal singletons". 
Please elaborate. Both of the APIs you mention should be fully functional.

>Any Ideas, especially for 3. and 4.?--> a good working X-Process-,
>respective X-Thread-Marshaling would be important, to take COM-
>Hosting under Linux/Wine seriously into account.
>My attempts, to get any useful information per WineDebug were not
>successful.
>  
>

The best debugging source would be to run with the environment variable 
"WINEDEBUG=+ole" and dump the output to a file.

>It would be great, if anybody with more "Wine-Debugging-Experience"
>could look at the appropriate Calls using our free Server-Download.
>  
>

I don't have time to download and install your applications, but I am 
willing to look at debug logs if you generate them.

-- 
Rob Shearman




More information about the wine-devel mailing list