I've been doing research on how processes communicate for the past like 4 months and I still can not answer this very simple question, how do most present day applications communicate within their own framework? Which tends to get me asking another question, do application programmers still program using C++?

note: I am aware of the game design forum! This is not intended to be a question directed at game design but at all application development. The resulting application will be more similar in nature to say Inventor.

Now to begin I guess it would be best to describe what I'm thinking and what I'm trying to accomplish. I am creating a tool chain or an 'engine' which will simulate various real time events and present these events in a visual manner. To do so I will be utilizing various techniques for application structuring such as Client/Server and RPC and the such. I would like to program the core process which will handle things such as UI, Physics, 3D Visualization, Peripheral Interfacing and so on in C++ as speed optimization in core would be ideal. As in many game type engines I would like to have a tier dedicated to the programming of a new world or in my case system. And in the end I am focusing on the Windows platform.

All of that said..... I am not sure what tools I should be using especially when it comes to IPC. At present time I believe I am narrowing to three distinct possibilities for IPC with connection to the core process COM, Named Pipes and Socketing. Now there are probably a bizzilion articles on all of this but I cannot find one that clearly identifies the intended end use and common present use of any IPC tools currently employable. The only thing I have to go on at the moment is many programmers saying do not use COM(forums and such.) Well right there in my humble opinion COM would be ideal for the core process. Using COM I can connect to client modules written in C#.NET and leave the possibility open to C++ modules as well. I'm sure Named Pipelines can accomplish similar tasks if not the exact same tasks as COM Connection Points and C# Deligates ???? Socketing I would probably leave to across network communication ... I am honestly so lost in this regards because I do not find any TypeLibraries on my computer not directly related to Microsoft infra-structuring ??? This to me suggests that no one uses COM! I did find some .tlb files in the XSI folder but I can't say for certain what their intended uses are but their presence makes me feel I'm at least not completely wasting my time ???

I mean there are plenty of DLLs are all communications done through object level shared memory ? Are applications just acquiring C++ interfaces and calling the functions from there?? Essentially that is how I started but there are all these tools already created that have long lasting and present standards why not use them? I really don't know anybody who does any programming so I only know what I read. My texts are all very clear on how and what can be done but not on the who's and the why's thereof ... Could someone please shed some light? I guess it would help if I start by trying the different methods out and seeing what works best for me ... I will be trying to write my first complete idl and compile my first complete tlb .. kind of as we speak ....

Grateful,
Butta

Edited 6 Years Ago by Buttacup: n/a

I agree. Download a game engine for half-life 2 where the source code is free to look at. This will be your first step.

I for example, built a half-life 2 and Call of Duty game engine in under a weekend . . . So it is more that possible. Good luck.

Microsoft has something called .NET Remoting. I realise this is C++, but the principle behind it is the same.

In .NET Remoting, Microsoft make use of TCP and named-pipes, which suggest that both of those are the best way forward for IPC in your application.

If you do require .NET at any point, your C++ libraries can be used through invoking [DllImport] It's common name is P/Invoke or Platform Invoke if you want to look it up.

This site has a good example of how to do that.

Edited 6 Years Ago by Ketsuekiame: n/a

Multi Quote ??????

I agree. Download a game engine for half-life 2 where the source code is free to look at. This will be your first step.

I for example, built a half-life 2 and Call of Duty game engine in under a weekend . . . So it is more that possible. Good luck.

I'm not sure what it is we are agreeing on or to what you are agreeing? The Client and Server modules for the Source Engine allow developers to develop their games but are completely self contained modules. Any of the code directly pertaining to anything from the rendering pipeline to resource management is well not open source. They are using 'COM like' structuring but as far as I can tell they are not using COM anywhere as goes with RPC. I would like to point at their methods for passing variables between the Client and Server modules and then stare ....

I've gone through the Source Engine a number of times and I don't see how this applies to this thread. Source is far from 'Modular', and for my purposes I am adding, is hardly a model for concurrent programming under C++. Source is like a big bowl of spaghetti that was the result of the left overs of a pot luck ....

Microsoft has something called .NET Remoting. I realise this is C++, but the principle behind it is the same.

In .NET Remoting, Microsoft make use of TCP and named-pipes, which suggest that both of those are the best way forward for IPC in your application.

If you do require .NET at any point, your C++ libraries can be used through invoking [DllImport] It's common name is P/Invoke or Platform Invoke if you want to look it up.

This site has a good example of how to do that.

Yeah I tried to get at that in my op. I mean I guess a lot of people are moving or have moved to C# and .NET and away from C++. So like everyone's using Assemblies instead of Type Libraries and not using RPC and obviously not COM. Named Pipes do seem to be a thing....

But again I don't know the who's and the why's because I have oodles of information on the how's and the what's but I can't find an article defining who the people are who are using what techniques to get what done and why? I would like to point out that there are still articles being written on the proper methods to implement COM so someone has to be using it but who and why? Aside from a little bit of unsuccessful posting on forums I am not involved with others socially or professionally that have any sort of opinions on these matters!

In the end I will probably employ a combination of all the above and as per my general standard of end products it will be of a high quality. Even if I did just that I still wouldn't know the answer to my question though ... :/

Edited 6 Years Ago by Buttacup: n/a

I personally use WCF for my .NET work and named-pipes for any C++ IPC. I guess it's down to what you want to use.

WCF appears to be the way forward with .NET. As for C++...Put your choices in a hat and draw one out at random :P

I personally use WCF for my .NET work and named-pipes for any C++ IPC. I guess it's down to what you want to use.

WCF appears to be the way forward with .NET. As for C++...Put your choices in a hat and draw one out at random :P

thx for the reply :)

I Googled Named Pipe Interop C++ C# and happened across this ....

http://channel9.msdn.com/shows/ARCast.TV/ARCastTV-Bridging-The-Gap-from-C-to-C/

It doesn't really get down and dirty with the comparison of technologies but it does highly recommend using Named Pipes and with WCF on the .NET side for interoping(XML is good \o/.) It is strongly suggested that C++ is an ever present thing of the past but I'm not really interested in the argument of the existence of C++.

I would like to find an argument on using COM that explicitly details the pros and cons to its use at present..... I mean even with the above method sure the transmission of data is efficient but it then has to be processed and handled on each end which assumes foreknowledge of intent ????

Edited 6 Years Ago by Buttacup: n/a

This article has been dead for over six months. Start a new discussion instead.