How to add a simple API to my C++ application for access by LabView?

Question

I have a data acquisition program written in C++ (Visual Studio 6.0). Some clients would like to control the software from their own custom software or LabView. I would like to come up with a simple API with a dll I can distribute to them and would like some tips on how to get started. This is going to be VERY basic, maybe 4 or 5 commands. My DAQ program will still be running in its own window on the same machine, I would just like to set it up to be controlled from another program.

Answer 1

You are on the right track with a DLL. The real trick, it sounds like, will be deciding what sort of inter-process communication (IPC) you want to use. Options are: sockets, pipes, shared memory, synchronization objects (events, etc.), files, registry, etc.

Once you decide that, then implement a listener within your executable to wait for incoming IPC messages from whatever software is using your DLL.

As far as the API is concerned, you can keep it simple just like you were wanting. Have the DLL expose your 4 or 5 functions (make sure you only use native data types, like char* and long, to avoid module boundary issues), and then those will use your IPC mechanism to communicate with your executing app.

Answer 2

Things that start simple like this have a habit of growing over time, so you may be better off doing a little more work up front and using a technique that will grow with you.

Implementing a COM interface to your program would give the clients are lot of freedom in how the interface with it, and you wouldn't have to worry about the mechanics of IPC, etc since COM is designed to hide all that from you.

In the future COM already has well define idioms for things like events that are well support by scripting languages, etc should you need them.

Update: there are a lot of ways of implementing COM. You can build it from the first principals with the guide of a good COM book, or use of framework like ATL to save some of the boiler plate. There are a lot of good samples, for example see MSDN.

Answer 3

I agree with Rob. use COM, it might be more work right now but in the long run you will be thankful. However Brian's suggestion is better if you want to control the integration layer right down to the nitty gritty.

Answer 4

There is a related question here. I don't want to end up with something that is LabView-specific, and it appears that LabView can access dlls if they use stdcall. A dll like this would be callable from a VB or other Windows software as well which is what I'm shooting for.

I'm not sure about it's ability to access a COM interface but would appreciate some more detail on what that would look like for my application.

Answer 5

The big advantage of COM is that you don't need a DLL! Your application would always be running, you say. That means that it can act as the COM object creator ("local server").

If someone would want a "stdcall" DLL instead, you could give them a DLL that internally just forwards all calls to the COM interface. Writing it would be quite trivial. You only have 5 functions, you say. That suggests you have one COM interface, with those 5 methods. When the wrapper DLL loads, it asks your EXE to create its COM object. The DLL in turn exposes 5 stdcall methods, each of which calls one method on the COM object.

Answer 6

You could use a dll. I'd consider it. But I'd also consider whipping up a simple http-based API, preferably RESTful.

Advantages: Easy to port. Can write a client app from any language trivially. Can work across a network. Testing becomes easier (use a scripting language or your browser).

Disadvantages: Performance is going to be slower. Significantly more plumbing to set it up in C++. I'm not sure if LabView can make http calls.

Something like:

http://xxx/data [GET, maybe POST for testing]

http://xxx/data/start [POST]

http://xxx/data/stop [POST]

http://xxx/data/parameters [POST]

Given your requirements it may be slightly overkill but then maybe not. Many apps I've worked on have had to be ported and would have been quicker to extend if we could have used a faster dev language to test and extend it.

Answer 7

If you want really quick and dirty automation on the same pc, you could also use autohotkey. It's cheating, but it doesn't require changes to your existing app.