On Thursday, April 13, 2000 4:15 PM, Steven Harrison [SMTP:steven.harrison@ni.com] wrote:
> In the last few weeks, there have been lots of posts from people trying to
> implement various functionality in CINs, having trouble building CINs,
> crashing their VIs after calling CINs, etc. We at NI are interested in the
> reasons people are choosing to use CINs rather than shared libraries (DLLs).
> The most obvious advantage is that you don't need to carry around an extra
> file; I'm sure that's important to some people. What other reasons do you
> have? Are there people out there that are really using CINLoad, etc?

Sure enough. It gives me a great control as to how and when the VI is
correctly initialized and allows to use data space globals. I like them!

> This question is motivated in part by the fact that CINs are inherently
> difficult for us to support; any time a new version of a compiler is
> released, there is a good chance that part of our CIN documentation will
> instantly become obsolete. The fact that the list of supported compilers on
> the various platforms is already fairly large complicates this.
>
> On the other hand, I know of no modern compiler that can't painlessly create
> a DLL, and I don't see many posts on info-LabVIEW from users struggling to
> build DLLs.

What is the problem about CINs? On Windows 32 bit at least they are nothing more
than DLLs with a specific exported interface, so I do not see why a new Visual C
version will give that much problems. Also I'm regularly calling LabVIEW manager
functions and for those functions I need the correct import libraries. However independant
of if I use CINs or DLLs I can only use those compiler environments which LabVIEW
has CIN libraries for and that is independent if I create a CIN or DLL for this.

> CINs existed in LabVIEW long before DLLs were in vogue, and we've maintained
> support for them through the current version with no plans to stop doing so.
> But I'm interested in hearing from the LabVIEW community now. Speak up if
> you prefer CINs, and tell us why. (Also speak up if you prefer DLLs).

CINs give me a much more intimate control over the data passed from and to LabVIEW
and unless I use native data types (and maybe even then) in LabVIEW, DLL parameters
seem always to be copied for the actual call, where as CIN parameters CAN operate in
place.
The Win32 LibMain function gives also some control over the initialization of DLL data
space but not in the way the CIN functions do.
And last but not least I can easily write and have done so many times one CIN source
for multiple platforms. If you ever drop CIN support you will have one disappointed guy
here.

The reason why CIN questions come up so often here are probably manifold. One is they
are initially more difficult to do as one has to learn the CIN specifics whereas many
people may already have had some exposure to DLL development before. But technically
a DLL is just as difficult to write than a CIN and in my not very unbiased opinion they are
even more difficult.
Second DLL questions and problems are usually directed to other resources such as
Microsoft and Apple support channels and mailinglists whereas those for CINs are logically
directed towards NI and the associated mailinglists such as Info-LabVIEW.

Rolf Kalbermatter
CIT Engineering Nederland BV tel: +31 (0348) 460 232
Ohmweg 11A fax: +31 (0348) 460 233
3442 AA Woerden http://www.citeng.com
Netherlands mailto://rolf.kalbermatter@citeng.com