COM or DLL

[Jens Munk]

What is you recommendation for interfacing other programs to LabView - COM
or just a plain DLL?

I am developing a program controlling a test system and I would like to add
the ability to have this program / test system controlled by LabView. From
my (limited) knowledge of LabView there are two standard ways to do so: COM
or a DLL. I have spent some time with COM because I though it was a
Microsoft standard and I wouldn't have to bother with calling conventions
etc. However, I have experienced different and it is rather tricky indeed.
In addition, and this is what makes me really frustrated, the remote
operation COM, the DCOM, should be very easy when COM is first working but
due to various security issues in Windows it is semi-impossible to get
working. So I
would so much prefer to write a DLL instead. They are much,
much simpler, no huge overhead and most importantly, you know what's going
on.

So is there any reason why I should just not make a DLL interface for
LabView to my program / test system?

I am looking forward to your comments,

Jens Munk.

[Greg_McKaskle2]

> What is you recommendation for interfacing other programs to LabView - COM
> or just a plain DLL?
>

While all of them should work, you do a pretty good job of listing the
tradeoffs. Here are a few more. You need to decide if your DLL will be
thread-safe. If not, then be very sure to document it. It is quite
easy for the user to work around, but they have to know about it. If
you want it to be thread-safe, that is a bit hard to do in C code, or at
least there are lots of possibilities for doing it. Both of these are a
bit simpler in COM since it will mark it and will protect it for you --
though this is often part of the reason for the high overhead per call.

Finally, COM does help with identifying datatypes. Either document your
public funct
ions well including which side is responsible for creating
and destroying any dynamic pieces, or go with COM.

When the stars align and all the COM altars have the proper offerings,
COM works well, and it is equivalent to a DLL call. Problem is that
this is difficult to achieve, and difficult to debug when it isn't
working -- IMO.

Greg McKaskle

[Jens Munk]

Thanks,

Yes COM sounds nice and has useful settings to automatically handle
threading. However, I have certainly learned the hard way what you also say
in your final remarks. Therefore I am leaning more and more towards to keep
things simple and clear. And indeed a DLL call is way simpler than a COM
call although it is wrapped up for you. The DLL call is just the instruction
pointer and some data some pointers passed whereas the COM does a whole
bunch of things for you that you don't have a clue about. Subsequently when
it doesn't work you are simply lost in space.

Regards,

Jens


>
> While all of them should work, you do a pretty good job of listing the
> tradeoffs. Here are a few more. You need to decide if your DLL will be
> thread-safe. If not, t
hen be very sure to document it. It is quite
> easy for the user to work around, but they have to know about it. If
> you want it to be thread-safe, that is a bit hard to do in C code, or at
> least there are lots of possibilities for doing it. Both of these are a
> bit simpler in COM since it will mark it and will protect it for you --
> though this is often part of the reason for the high overhead per call.
>
> Finally, COM does help with identifying datatypes. Either document your
> public functions well including which side is responsible for creating
> and destroying any dynamic pieces, or go with COM.
>
> When the stars align and all the COM altars have the proper offerings,
> COM works well, and it is equivalent to a DLL call. Problem is that
> this is difficult to achieve, and difficult to debug when it isn't
> working -- IMO.
>
> Greg McKaskle
>