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

[Olaf Schmidt]

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.

If you want to test a Server/Client-Pair - here's our free Download:
www.datenhaus.de/Downloads/dh_RPC.zip

For a successful test under Wine, you have to Install
the Redistributables of an actual VB6-Runtime
and some ADO-Distributable >=2.5 first.

I've tested the whole thing under a Debian-Sid with a somewhat
older Kernel (2.6.9), but with a new "apt-getted" Wine-Version
(0.97). The Installation of the VB6-Runtime and the ADO-Redist
was not possible, until I figured out, that a prior install of IE6 was
helpful, to install the two above mentioned packages.

After installing these prerequisites, I removed the IE6-ProgramFolder,
unpacked our ZIP to c:\dh_RPC, started the Server and the Client -
eh voilà - all was working fine (Linux->Linux and XP->Linux).
The complete set of COM-DemoCalls was working "OutOfTheBox",
even the "Disconnected ADO-Recordset"-Call was successful.
(For the Linuxers, that are serialized DB-Resultsets, wich are often
used in distributed COM-Scenarios).
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). So
Wine has ca. 3 times the Call-Overhead, regarding Object-Instantiation
and Method-Invoking-By-Name. 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.

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?)
2. Win-Authentication and -Impersonation
   (LogonUser- and ImpersonateLoggedOnUser-APIs - already mapped to...?)
3. "Global ServerSingletons" using ROT-Entries with FileMoniker-Binding
4. "RPCServer-internal Singletons" (CoMarshalInterThreadInterfaceInStream
    and CoGetInterfaceAndReleaseStream against the IUnknown-Interface).

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

Thanks.

Olaf Schmidt

P.S. As Dan Kegel has recommended in 'wine.user', I will try to isolate
       the Problems 3. und 4. in separate Binaries and post a link later.

[Robert Shearman]

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

[Olaf Schmidt]

> I assume you mean cross-process COM calls?
No, no it works cross-machine. We've designed our own binary protocol
(Variant-ParamArray-Serialization + support for IPersistStream regarding
Object-Transport + ZLib-based Compression + built-in Strong-Encryption
+ MITM-secured Diffie-Hellman-Auth.).
It has its own Server-Part, uses only one Port (where DCOM needs a
complete Port-Range), it has a runtime- adjustable ThreadPool, it is
working completely independent of DCOM and - most important - of
the Windows-Registry.
We've developed this some years ago, because we were annoyed by the
DCOM-Config-Orgies and the Dll-Hell regarding correct Proxy/Stub-
Interface-Registrations, the difficulties, to change COM-Binaries whilst
continous operation - all those problems -> gone since we implemented
our own "RPC-Server".

If you have an XP- or W2K-VM somewhere, there's no setup needed, to
test our Download (VB6-Runtime and ADO are then already present).
Just copy the Server- and Client-Folders, start the appropriated Apps
and play around, to get an idea of the whole thing (needs 5 minutes).

>The D-part of DCOM  is not currently supported.
I know, but as said, we don't need it.

> >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...
Good to know... :-)

> >1. Running as Service...
> 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.
Ok, no big problem.

> >2. Win-Authentication and -Impersonation
> >   (LogonUser- and ImpersonateLoggedOnUser-APIs ...
> The probably both do nothing. Since you shouldn't be running as root,
> then this isn't a problem.
Ok, no big problem under Linux, but the MS-SQLServer for example,
supports (besides DB-Internal Security-Accounts) Win-Based-Security
(Tables/Views/etc., wich are secured using Win-Auth.) and this feature
is often used by MSSQL-Admins - that's why impersonation is (among
other things) important under Windows inside the "Pre-DB-Layer".
But someone who decides, to do COM-Hosting under Linux, probably
uses Postgre or Firebird and their builtin DB-Security/Usermanagement.

> >3. "Global ServerSingletons" using ROT-Entries with FileMonikers...
> 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.
Ok, no big problem, if we can get '4.' to work (it's anyway the more
recommended way to work with "Stateful Objects".

> >4. "RPCServer-internal Singletons" ...
> > CoMarshalInterThreadInterfaceInStream and
> > CoGetInterfaceAndReleaseStream ...
> I'm not sure what you mean here by "RPCServer-internal singletons".
> Please elaborate.
Normally RPCs should use stateless objects (Object-Instantiation, Method-
Calling, Object-Destroying). That's what we do inside our WorkerThreads.
Now there's often the need, to "pin" an object or some data somewhere
between two or more RPCs (for Transactions, Session-Management,
Object-Pooling, usage of serverside resources like COM-Ports , etc.).
So we allow instantiation of Singleton-Objects inside the RPC-
Serverprocess on their own threads (beside the WorkerThreadPool).
The two types of singletons behave the same regarding their access
from inside the workerthreads (handled unter Windows by the Free-
Threaded-Marshaler) - but only the Singletons of Type '3.' can also be
accessed from outside (and marshaled) X-Process per GetObject(...).

> Both of the APIs you mention should be fully functional.
I've just tested this using the following VB-Code:
Inside the same Thread it works without problems under Wine
(altough that makes no sense of course).
Cross-Thread it is failing under Wine, whilst the cast of the  IUnkn.-Proxy
to a second ObjectVariable of Type IDispatch.

Maybe, the problem is related to VBs Apartment-Threading and its
usage of Thread-Local-Storage (TLS), but it could also be related to
incorrect Ref-Counting inside Wine.

Here's the Debug-Output of WINEDEBUG=+ole:
(First two parts are sucessful, the 3rd-part fails - I've
intermitted the Output using "MessageBox-related-Breaks"
http://www.datenhaus.de/Downloads/WineDebug.txt

'here the Types and WinAPI-Declares
Private Type GUID
  Data1 As Long '32Bit-Value
  Data2 As Integer '16Bit
  Data3 As Integer '16Bit
  Data4(0 To 7) As Byte
End Type

Declare Function CoMarshalInterThreadInterfaceInStream& Lib "ole32.dll" _
      (ByRef rIID As Any, ByVal pUnk As IUnknown, ByRef ppStm as Long)
Declare Function CoGetInterfaceAndReleaseStream& Lib "ole32.dll" _
       (ByVal pStm As Long, ByRef rIID As Any, ByRef pUnk As IUnknown)

'And here the used Functions (last one is failing with a valid pStream-Ptr -
'but only in a Cross-Thread-Scenario)
Function GetStreamPtr(ByVal Obj As Object) As Long
Dim IID_IUnknown As GUID
  IID_IUnknown.Data4(0) = &HC0: IID_IUnknown.Data4(7) = &H46
  CoMarshalInterThreadInterfaceInStream IID_IUnknown, Obj, GetStreamPtr
End Function

Function GetProxyFromStreamPtr(ByVal pStream As Long) As Object
Dim IID_IUnknown As GUID, IU As IUnknown
  IID_IUnknown.Data4(0) = &HC0: IID_IUnknown.Data4(7) = &H46

  '#Start of Part2 -> see http://www.datenhaus.de/Downloads/WineDebug.txt
  CoGetInterfaceAndReleaseStream pStream, IID_IUnknown, IU
  '#End of Part 2

  '#Start of Part 3 (the failing Cast to IDispatch)
  Set GetProxyFromStreamPtr = IU 'cast to IDispatch
  '#End of Part 3
End Function

Olaf