Ever try to get a VB app to talk to a multi-threaded C++ ActiveX component?
Yes, all the time! We write central, computationally intensive, multi-threaded (MTA) components with c++, and handle the high level, low-bandwidth logic using VB, Python or Tcl (depending on what we need and what we feel like). And we rely upon late binding when using Python and Tcl. In my experience, everyone (including me) complains when faced with new technology that doesn't bear any kind of similarity to understood work. That's ok - issues like these can be sorted out by talking to people who have solved these problems. Have you tried the DCOM mailing list?
The response time for posted questions is usually very fast.
And don't even get me started about interfacing DCOM to non Windows systems.
This in the past has been my biggest headache too - I don't think this is negative point about COM. Perhaps for low-bandwidth connectivity, protocols like XMLRPC or SOAP might be a good solution. I remember back in the OpenDoc days, the boys and girls at IBM did put together a COM/CORBA bridge - I wonder if that's still available.
Hmm, yes you can - in our company we've used DCOM for quite some time, tying our objects across a network. And its relatively easy. Without starting a flame war, I don't believe you have an understanding of COM at all - COM uses the notion of Proxy/Stub components to marshall an interface pointer across the process/machine boundary. For the network case, the DCOM definition (which is part of COM) handles the transport. This is quite suitable for most cases. In situations where the default implementation is not suitable, we've written our own proxy/stub components, which implement our own transport.
Slashdot Mirror
Heh, heh. The Solaris port was actually achieved using Mainsoft. So what was so bad about it?
Yes, all the time! We write central, computationally intensive, multi-threaded (MTA) components with c++, and handle the high level, low-bandwidth logic using VB, Python or Tcl (depending on what we need and what we feel like). And we rely upon late binding when using Python and Tcl. In my experience, everyone (including me) complains when faced with new technology that doesn't bear any kind of similarity to understood work. That's ok - issues like these can be sorted out by talking to people who have solved these problems. Have you tried the DCOM mailing list?
http://discuss.microsoft.com/archiv es/dcom.html
The response time for posted questions is usually very fast.
And don't even get me started about interfacing DCOM to non Windows systems.
This in the past has been my biggest headache too - I don't think this is negative point about COM. Perhaps for low-bandwidth connectivity, protocols like XMLRPC or SOAP might be a good solution. I remember back in the OpenDoc days, the boys and girls at IBM did put together a COM/CORBA bridge - I wonder if that's still available.
Hmm, yes you can - in our company we've used DCOM for quite some time, tying our objects across a network. And its relatively easy. Without starting a flame war, I don't believe you have an understanding of COM at all - COM uses the notion of Proxy/Stub components to marshall an interface pointer across the process/machine boundary. For the network case, the DCOM definition (which is part of COM) handles the transport. This is quite suitable for most cases. In situations where the default implementation is not suitable, we've written our own proxy/stub components, which implement our own transport.