I would definitely use a socket for IPC, maybe shared memory in some cases. The most lightweight interprocess communication channel is probably an unnamed pipe but sockets are more flexible not to mention that the loopback interface is decoupled from the network stack so if both endpoints are on your machine then sockets are super-fast. With sockets you have the opportunity to run the processes on different machines anytime without much effort (possible with name pipes too, but thats more hassle and not crossplatform like sockets). In my opinion COM and DCOM are just unnecessary complications to solve your problem.
I backup the opinions on using sockets. Use them. That knowledge will help in the long run and will be good for other platforms. I wrote some articles on TCP/IP that might be useful. Search for them on this site.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
You can use COM objects if you make sure they are automation compatible (have the [oleautomation] attribute and use only automation compatible types in their methods). This will assure that all required marshalling code exists - it will be just like DCOM. There might be other ways (like writing your own marshalling code), but this is a way that will work. You can, of course, also use DCOM.
However, it depends very much on the details of your project, is this is the right way. The advantages are, that COM takes care of everything, like marshalling your data correctly (even between 32/64 bit processes). But also you might run into a lot of things that will be not so easy to solve for unexperienced COM programmers.
There are quite some articles here on CP about IPC, might be worth to take a look there.
In case you want to experiment a bit (and I would strongly suggest that before you decide for a certain solution!) I would suggest WTL (check out http://www.codeproject.com/kb/wtl/ [^]. A series of some very good articles is Michael Dunn's WTL for MFC Programmers). Create a project with the option "Create as COM Server" (will appear in the Application wizard). It will give you an exe project with a UI, that also acts as a COM server. Create two such projects in your solution, add some COM objects and start to play around a bit.
Normally the backward compatibility was planed to ensure that if one soft is compiled for an old version of the library, it can continue to work with the new higher version of the library without recompilation or special adaptation.(situation 1)
Is the reverse also true?
Means if the soft is compiled with the new higher version of dll it can continue to work with the old version of the library without recompilation or special adaptation.(situation 2)
My situation is the first one, So I ask if should I have also situation 2 works ?
In the end, no one of us can see into the future, therefore it is not possible to say that your program will work with another version of the DLL in the future. Just because it is... you know... the future.
I had an application which is using MFC serialization mechanism w.r.t MBCS (both for serialization/ de serialization ). Now I would like to convert my application to read/write Unicode using MFC serialization mechanism.
What would list of changes in this regard. (dos & dont's) Thanks in Advance !!
class ATL_NO_VTABLE CSubTapiCom :
public IProvideClassInfo2Impl<&CLSID_SubTapiCom, &__uuidof(_ISubTapiComEvents), &LIBID_SubTapiATLcomLib>,
#ifdef _WIN32_WCE // IObjectSafety is required on Windows CE for the control to be loaded correctly