> 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