COM and .NET vs WinAPI

Thank you, I will take a look .

Now I just have to get interoperability working with my old C code...

I realize that both routes (WCF and COM) require significant rewrites in code. The question is, which would be more troublesome? I want to convince my employer that moving forward with a longterm .NET conversion and WCF is the way to go but in terms of implementation, what are the ups and downs and estimated development time?

1) From my understanding, code in both cases needs to be rewritten in some way (the source is just straight C compiled as an executable that utilizes several 3rd party dlls)
- For WCF, I would have to rewrite the functions that I need exported into a dll, then call them with p/Invoke to work with a CLR language and use the appropriate syntax to define the A,B,C's of WCF (using a Named Pipe Transport). The latter seems straightforward enough, I am mainly afraid of the rewriting of the original code
- For COM, how difficult would it be to restructure the code so the COM server runs as a standalone out of process .exe? Can I isolate the needed functionality and simply repackage those?
- For COM, would I have to expose global data structures using the IObjectData? Still hazy on this...

2) Why is COM obsolete?
- for example, we interface with programs like SolidWorks which utilize COM
- .NET and WCF provide many alternative modes of transport which are relatively easily implemented (e.g web interfacing)?

Sorry to keep bothering you Gurus! As I said, I know how to code, but don't really understand the architectures and technology behind it. I really appreciate the help from all of you. I've been fumbling around in the dark and it's all coming together slowly!

Well, the whole situation seems rather ambiguous. To chose between COM and .NET you need to understand your customers, first of all. What client type would suit them better, COM or .NET? The latter inevitably involves some .NET programming on client side. Is this okay for customers? I don't know. So far all I have heard is how hard or long or expensive it gets to implement. Not a word about customers. This is obviously wrong.

As well, I constantly hear about how outdated COM is. I don't buy it. COM is alive, and constitutes a good deal of user level functionality in Windows, including the most recent version of it. So this is another consideration that has to be revised.

And finally, I still can hear nothing about why simple custom made socket based channel cannot serve the purpose as it gets stated by now. Stream bases data exchange is the most flexible and all-in-your-hands solution requiring no COM or .NET knowledge and fully compatible with any language, C, C++, VB, Delphi, C#, whatever. Why this constantly gets neglected? I don't know.

An adjacent to the latter, http protocol based call interface could serve to the purpose alright. Did anybody look in the direction of light-weight http server? Afraid, that was neglected the same way. Well, maybe this looks rather exotic. Again, I don't know, as long as I don't understand ultimate requirements.

Really, to judge on all the four above I'd be already implementing prototypes for every choice, starting from the simplest socket (or named pipe, why not?) solution, unless I got a clear instruction to focus on some particular ones.

I see your point Igor, but mainly my boss wants one of the two haha.
but in the end, the use cases boil down to the customer being able to use the getString and setString functions within a running .exe