COM and .NET vs WinAPI

Hi All,

This is a very general question, please tell me if this is the wrong place to post this.
I am very new to the world of COM and .NET, as most of the programming i Have done has been in straight C (used to be a hardware engineer and have made some basic Apps in win32).

I am currently reading "Understanding Active X and OLE" by David Chappell and am having a hard time understanding how to implement an external interface to our existing application.

This application is essentially written in legacy code in straight C as it was written almost 20 years ago.

If i write a COM interface, would it be a completely stand alone .dll or executable? or would it be compiled within the existing program?

Ideally I'd like to go with .NET for interfacing. Is this possible in my scenario? Would I have to rewrite the legacy code utilizing .NET architecture?

If it sounds like I don't know what I'm talking about, then you are not mistaken. In the meantime I will continue reading...

Thanks for your time!

Before you will write a COM interface for your legacy code you have to be very sure you do need it. And you'd better not do it if you don't need.

For example, since my professional programming with C++/VC++ in more than a decade I never needed develop or rewrite my code with a COM interface.

So the COM interface is not just some module I can append to the source code somewhere?

I would I have to rewrite the entire program?

Is the same true with .NET?

Thank you for your reply!

Quote:

---

and am having a hard time understanding how to implement an external interface to our existing application.

---

What is the requirement for external interface?

basically anything to allow clients to use the functionality of the software. We currently have DDE implemented, but my employer seems dead set on replacing it.

Quote:

---

Originally Posted by kingting

basically anything to allow clients to use the functionality of the software.

---

What if one of your clients wants a simple DLL, and not Active-X or .NET?

I know programmers who once they see something needs Active-X going on or they must use .NET, they say "no good". They then go on and see if there is another component that does the job using simple calls to an external DLL.

The simplest and most flexible is the regular DLL (non-ActiveX DLL, and not .NET). Also, you could create an ActiveX wrapper that relies on your regular DLL if you want to use Active-X.

Regards,

Paul McKenzie

Thanks for the responses.

is COM only used for active-x controls?

To be more specific of the requirements:

This application does scientific modelling of optics (lenses and such),
and so clients need to be able to set up a server and model from outside the program (e.g Matlab, or if someone was trying to write a plugin to use optics data within a CAD modeler, etc.) grab data values , and manipulate parameters within the application. They should be able to export these models as known CAD data types and perform ray tracing operations.

From my limited understanding of coding, a simple DLL won't work on all compilers etc. as this legacy code was written in C.

I am very lost, and I appreciate the responses!

Quote:

---

Originally Posted by kingting

basically anything to allow clients to use the functionality of the software.

---

Sorry, but "anything to allow to use" does not sound like a requirement. You need to analyze, what your current app is, what the workflows for externally invoked functions are, should it be some sort of RPC, or app's hidden start/stop is allowed. Does any GUI show up? Or embed to anything? What is your market target (developers, languages, existing products)? Any special cross language integration anticipated? Man, there are lots of ways how "functionality of software" could be used by clients. And further recommendations are definitely going to depend on the real requirements.

So, the first recommendation is: compose a requirements document.

Quote:

---

Originally Posted by kingting

From my limited understanding of coding, a simple DLL won't work on all compilers etc. as this legacy code was written in C.

---

DLL's have nothing to do with the language used to create the DLL. The DLL could be written using any language -- it doesn't matter.

Once you create the DLL's exported interface, the DLL will work with any language that can call DLL functions. This includes every C compiler, every C++ compiler, Visual Basic, C#, Delphi, you name it.

The issue is that you have is to take what you have, and put a simple external interface around it so that it can be used easily. Look at the many companies who sell DLL's to do certain things. My company creates DLL's to manipulate TWAIN devices, another company may make DLL's to process image files, another may develop one to aid in PDF or Postcript creation, etc. The trick is to hide all of the tricky details within the DLL, and have a few functions that the client calls to get the job done.

Regards,

Paul McKenzie

In response to Igor: HAHA yes, i reread that and realized how vague that was. I reiterated a bit in my post above. Does that kind of give you guys an idea or should I be more specific. To be honest, I have not used the software extensively ( i was brought on to write a standalone application).

To reiterate further:

Most of our users write plugins for the programs

for example: if a very specific calculation is required that we do not support, but can be attained from grabbing certain data values, they may run their plugin alongside the software to perform calculations for manufacturing requirements, tolerances, etc.

Clients will also want to run the application as a standalone extension in the background in accordance with programs like Matlab To communicate data values and print bitmaps of figures generated in the server application.

These are general examples, but do they clarify things a bit?

Paul:

So based on the requirements and examples I've described, is an Interface with COM or .NET unnecessary? Should I just be focusing on a .dll with the encapsulated functions?
I guess I am confused about the benefits of COM or .NET as they just sound more "Progressive" and "fresh," as we would like to expand the product and keep it relevant. If it is possible with COM, would I just be able to write some kind of wrapper around existing functionality to encapsulate these functions and data items?

Thank you all for the responses

Quote:

---

for example: if a very specific calculation is required that we do not support, but can be attained from grabbing certain data values, they may run their plugin alongside the software to perform calculations for manufacturing requirements, tolerances, etc.

---

This sounds like a plugin to your app. Could be a dll alright, though might be COM in-proc server all the same.

Quote:

---

Clients will also want to run the application as a standalone extension in the background in accordance with programs like Matlab To communicate data values and print bitmaps of figures generated in the server application.

---

This sounds totally opposite, like your app is an RPC server: out-of-proc COM, .NET web service, or even an old fashioned server with some stream based communication channel, like socket, pipe or http API. But this can be a plain file based processing alright.

Are you sure your app will be both client and server? If yes, you're in trouble as much as twice. :D

Seems you're gonna keep getting this bare theorizing here until you do some sort of requirements and high level design. Identify your problems, split them to more elementary questions, do some research on each. In other words, follow standard development procedure. :)

Quote:

---

COM or .NET as they just sound more "Progressive" and "fresh,"

---

Comparing to what? Dlls? Dll can be COM or .NET, whatever you want, or better, make it be.

I totally agree with you, this is essentially somewhat of an R & D project for me right now, as I should find what is possible using each of these implementations if possible at all.

But i was given 2 prerogatives that is:

1) Allow users to design plugins for the applications

2) Allow users to run our program in background for data acquisition

Meanwhile, the program will be running be running in both of these cases,so it would be a out of proc COM. So it looks like yes, it must be a client and server...

As for the individual requirements and functionality provided in each, I am still drilling down on those. I will do a little more delving on my own and probably ask more questions...

In any case I really appreciate the responses here

You could start with few use cases, and see if there are some resemblance in workflows, input and output data, etc., which would bring you to some basic design idea.

It's not clear whether you want to expose data through an interface or whether you are exposing some functionality that will present UI in the client app.

If clients that call your interface only retrieve data and are responsible for rendering their own UI, then the problem is considerably easier.

What are you looking for?

If a Client is writing a plugin, then the client needs to be able to make an exectuable that can both call functions of the server and exchange data back and forth. Same goes if he is using the application as a stand alone extension. So really there shouldn't be any UI exposure on my part

Exposing server functions cannot be a problem. And two-way exchanging data cannot be either. Of course, if your server exposes a predefined set of functions and data types (this is what they call 'interface'). But then what that plugin would be for? Plugins usually extend server functionality. So, the new functionality should be exposed from the server as well, along with data types it uses. Is this the intention? Or the plugins are just for special file format processing, like open/update data source? Or adding new communication channels? Something else? All of that? :D

Igor: I beleive the goal is all of that eventually, but I am going to start out very simple haha.

I think I got ahead of myself. So, I'm just going to start a new project and make it as easy as I can.

I want to create an application using C, have it store a string. Then I will create another application (as simple as a console application), run both at the same time, and be able to setString() and getString() from the latter application.

What kind of architecture should I implement? I know this could be simple as writing to a text file and reading it from the second application, but my employer wants something more sophisticated, I suppose. So Imagine these are the only requirements for this application.

The software is very complex, but basically the use cases can be simplified to this just as proof of concept.

EDIT: ALSO, I appreciate the ongoing conversation and your responses, it's been great just narrowing down the focus and all the design tips.

Quote:

---

I want to create an application using C, have it store a string. Then I will create another application (as simple as a console application), run both at the same time, and be able to setString() and getString() from the latter application.

---

1. 
   
   • Socket or named pipe as a data transport, hosted by server side
   • dll implementing custom data exchange protocol (or XML exchange maybe) loaded on client side
2. COM out-of-proc server, singletone

Since you are only dealing with data, I would use a WCF web service (.Net C#).

I would wrap your exisiting C code as Managed C++ assemblies and expose them with the above C# WCF service.

That way, any client capable of consuming web service code can connect to the service.

Yeah, I actually thought of web service. But frankly, as per my experience of dealing with WCF, it looks painless only for native .NET clients. It would be a pain to immerse its service part to existent C app (as a plugin I guess) as well as implement a proxy WCF client library for non .NET clients (API transponder dll). Knowledge of cross language techniques is mandatory. Though, really nothing impossible in that.

So does this C executable have to be compiled a s a COM object or can I have this C application and a .idl resource file and compile them together to create a separate exe for the application and the interface. Also would it be wiser to use the dispInterface of the normal vtable interfaces? I'm about 150 pages into this book and am still somewhat confused about this... maybe I am just dumb.

EDIT: Didnt see the past 2 posts made by u guys

I hadn't even considered WCF. Should I read more into it? I'm also not very sure how to wrap my code...

All this "progressive" and "fresh" stuff is quite tricky, and typically requiring for quite a long learning curve. Why don't you consider oldie-goldie socket solution with XML exchange?

So it seems...I'm thinking about just going with the COM out of process server. I will try to draft up a simple project ASAP and see what happens.

Regardless thanks for the input so far!

Hi All,

I am currently following this tutorial
http://www.codeproject.com/KB/COM/com_in_c1.aspx

but this teaches you how to build a .dll. If i already have an existing application, how do incorporate this into the build?

There is also no mention of .idl files does this mean I can bypass all this somehow if i just compile my own .idl?

Now you got caught. :) COM is extremely complicated in its details, so all the contemporary COM coding is wizard aided. Which means, it's quite easy to start from scratch end evolve, as wizards do that for you. But it's a real pain to modify something existent. Should I mention that I warned you before? ;)

http://www.codeproject.com/Articles/...-skeleton-code
I am actually using this now, and plan on adapting the code for the out of process automatation enabled server. Is this executable supposed to be running while my simple app is running? Am i meant to have the implementation of my application within the compilation of this code or will I essentially have 3 executables: client, server, and the COM interface?

I already regret my decision haha

If you are planning on going the COM route, then I suggest you look at the various ATL projects. The ATL related project templates allow you to create in process or out of process COM servers as well as a Windows service project that hosts COM servers.

So all these books and tutorials help me understand the concepts within COM, such as implementing IUnknown, IClassFactory, etc, etc. but what I don't understand how I can piece this together with a currently existing application. It seems like the application has to be designed from the ground up using COM. If I'm not mistaken, there are several ways to approach this.

a) out of process .exe server
b) create a COM dll with the object and function implementation... and load it into a project?

in both of these cases do i essentially have to rewrite the entire existing application?

The thing is the application is meant to be operated on its own, with these interfaces and communication protocols just as added functionality but in no way the main use of the application, so rewriting the code seems excessive...

I am also looking at WCF and am wondering how to convert this legacy C app into managed .NET code. would you have to rewrite all functionality into a .dll and start a new project, loading this dll using calls with CLR compliant languages?

Honestly, I am so torn on this issue. I realize that there is a steep learning code to all these things, but I feel hesitant in wasting time on something that will not work or seems to be obsolete (everyone tells me not to use COM because of this) or not be at least semi-easily attainable (e.g can be accomplished within the span of a couple of months), as I would imagine rewriting the source in .NET is the best way to go, new development and features of the app would be completely stalled for at least 6 months I'd imagine.

I also feel really dumb that I've spent a week and a half researching what to do and Feel more lost than I was when I started

The main point of this small rant is that I have no idea how to deploy COM within the current configuration of my application

Quote:

---

Originally Posted by kingting

So all these books and tutorials help me understand the concepts within COM, such as implementing IUnknown, IClassFactory, etc, etc. but what I don't understand how I can piece this together with a currently existing application. It seems like the application has to be designed from the ground up using COM. If I'm not mistaken, there are several ways to approach this.

a) out of process .exe server
b) create a COM dll with the object and function implementation... and load it into a project?

in both of these cases do i essentially have to rewrite the entire existing application?

The thing is the application is meant to be operated on its own, with these interfaces and communication protocols just as added functionality but in no way the main use of the application, so rewriting the code seems excessive...

---

COM allows you to expose functionality that allows external processes to manipulate data. If your app isn't designed with this in mind from the get go, then it's usually very difficult to tack this on afterwards.

Quote:

---

Originally Posted by kingting

I am also looking at WCF and am wondering how to convert this legacy C app into managed .NET code. would you have to rewrite all functionality into a .dll and start a new project, loading this dll using calls with CLR compliant languages?

---

If you write this in WCF, then the main WCF service would be written in C#, and you would have to either rewrite your existing functionality in C#, or write assemblies in Managed C++ that calls your C code. If the existing C code is in dll form, then you might be able to directly pinvoke to it in C#.

Quote:

---

Originally Posted by kingting

Honestly, I am so torn on this issue. I realize that there is a steep learning code to all these things, but I feel hesitant in wasting time on something that will not work or seems to be obsolete (everyone tells me not to use COM because of this) or not be at least semi-easily attainable (e.g can be accomplished within the span of a couple of months), as I would imagine rewriting the source in .NET is the best way to go, new development and features of the app would be completely stalled for at least 6 months I'd imagine.

I also feel really dumb that I've spent a week and a half researching what to do and Feel more lost than I was when I started

The main point of this small rant is that I have no idea how to deploy COM within the current configuration of my application

---

As I said, tacking on COM to an existing app isn't trivial.

If it were me, I would probably avoid the COM route (and I am quite proficient at writing COM apps with ATL).

I would look into going the WCF route (as COM is a bit of dated technology and WCF has several hosting options).

I have a Tray Notify article series that might help you get your feet wet with WCF. It shows how to host a WCF service inside a Windows service app.

See my signature line for the links.

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