Anyone tried cygwin's DDLs?

[OlegUA]

Hi All!
I understand that strange idea, but..... I came from UNIX and it's most easy way for porting some of my old toolkits to WIN32. I compile test DLL by GCC with -shared key. The test worked fine, but LabView simply and silently disappears ..... 

Thank for any advices,
Oleg.

[Andy F.]

Oleg,

Usually when LabVIEW disappears like that the calling data types are not correct in the Call Library Function node.  I would check to see if there are any questionable data types (those that would be difficult to translate into C data types) and check the calling convention as well (stdcall versus C style).  Here are a couple links about calling external code in LabVIEW.  

Using External Code in LabVIEW

Hope this helps!
Andy F.

[OlegUA]

Hello,
I successfully use those documents for developing CIN. But a problem is far more difficult unfortunately..... And not relates to external code in LabView in general case.  As I understood, the cygwin's DDLs has different internal structure and not to be directly calling from M$ compiled programs.

There is two important reasons for use cygwin:
The firstly, I do not like study of M$'s horror.... 😞 The cygwin and gcc cover all tasks needed for me at all. The secondly, I like deal with GPL instead M$'s license Visual Studio.

Oleg.

[rolfk]

---

@OlegUA wrote:
Hello,
I successfully use those documents for developing CIN. But a problem is far more difficult unfortunately..... And not relates to external code in LabView in general case.  As I understood, the cygwin's DDLs has different internal structure and not to be directly calling from M$ compiled programs.

There is two important reasons for use cygwin:
The firstly, I do not like study of M$'s horror.... 😞 The cygwin and gcc cover all tasks needed for me at all. The secondly, I like deal with GPL instead M$'s license Visual Studio.

---

I assume you mean DLL when you talk about DDL. As such it is very much about external code.

I'm not sure what the issue might be with DLLs created by cygwin, but as far as exported standard C functions are concerned there really shouldn't be any problem with creating such a DLL in Cygwin and calling it from other applications no matter what environement. You can have problems trying to call a C++ DLL from another environment, directly or through COM, but that is common as the C++ interface is usually not binary compatible between different compilers anyhow.

If your claim that interfacing standard C exported functions in a DLL created with cygwin is not possible from non cygwin environment is true, the whole cygwin DLL creating would be almost utterly useless, but I can't believe that. The DLL load library, get proc address and calling such a proc address interface is fairly well standardized. The only other problem might be the startup C runtime intialization of a cygwin DLL, but if they made that incompatible to MS then they look a little bit oprotectionistic to me.

In that case you may instead want to look into Mingw. That is a compiler toolchain environment build around Gnu C that attempts to provide a compatible environment to MS Visual C.

Rolf Kalbermatter

[DFGray]

It appears you are trying to develop a CIN rather than a DLL.  CINs are much slower than DLLs.  They also are more difficult to debug.  Compile your code as a standard, C callable DLL with basic data types (see previously mentioned documentation for details) and you should have no problems.

[rolfk]

---

@DFGray wrote:
It appears you are trying to develop a CIN rather than a DLL.  CINs are much slower than DLLs.  They also are more difficult to debug.  Compile your code as a standard, C callable DLL with basic data types (see previously mentioned documentation for details) and you should have no problems.

---

Would you care to explain what you mean by saying that CINs are much slower than DLLs? In runtime performance there is nothing I have found that would support that statement. In development time it is basically a question of your experience with either CIN or DLL development.
As such I prefer and definitely recommend to use DLLs nowadays but performance definitely is not a reason a priori to choose for one or the other. A CIN at least on Windows is technically just a DLL too, with a single exported function. It supports multthreading as well, so I really would be interested to know where this slowness would come into the game.
Debugging is also not much more difficult if you know how to add an __asm {int 3} statement to your source code.

However if you are right about your assumption that the OP does want to create a CIN with cygwin I definitely agree with you that he will run into C runtime initialization problems with the LabVIEW CIN interface initialization. Using a DLL instead is likely to ease those problems but I'm not familiar with cygwin and it may be indeed that cygwin created DLLs are intrinsically incompatible with normal MS C compiled applications.

Rolf Kalbermatter

Message Edited by rolfk on 02-02-2006 03:35 PM

Message Edited by rolfk on 02-02-2006 03:35 PM

[OlegUA]

---

However if you are right about your assumption that the OP does want to create a CIN with cygwin I definitely agree with you that he will run into C runtime initialization problems with the LabVIEW CIN interface initialization. Using a DLL instead is likely to ease those problems but I'm not familiar with cygwin and it may be indeed that cygwin created DLLs are intrinsically incompatible with normal MS C compiled applications.

---

Hello Rolf,
Thank you for detailed explanation. You right..... I found in internet many infos about incompatibility cygwin's DLL 😞 I will try minigw, thank you for advice.

Oleg.

[DFGray]

Rolf, you are right.  Thanks for keeping me honest.  There is no significant performance difference between CINs and DLLs.  In fact, CINs can be faster due to inherent interface optimizations. However, Oleg is still stuck using DLLs, since you can't make a CIN under Windows with gcc.  Oleg, unless you are using some data type LabVIEW does not support (e.g. function pointer) you should be able to make the cygwin DLL work, provided you remember to use the C calling convention in the Call Library Node.  Unless you know your code is thread safe, run in the user interface thread.