COM and .NET vs WinAPI

[kingting]

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!

[VictorN]

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.

[kingting]

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!

[Igor Vartanov]

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

What is the requirement for external interface?

[kingting]

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.

[Paul McKenzie]

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

[kingting]

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!

[Igor Vartanov]

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.

[Paul McKenzie]

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

[kingting]

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

[Igor Vartanov]

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.

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.

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.

[Igor Vartanov]

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.

[kingting]

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

[Igor Vartanov]

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.

[Arjay]

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?