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... :-)
- 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.
- 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.
- "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".
- "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