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

[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