Import Shared Library -> missing .h generic header files

[EMCCi]

Hello everybody,

I'm trying to use the Import Shared Library wizard for the first time. I have included the .h specific  header file of the dll but the wizard says that I'm still missing all this list of generic .h files:

From where I should get all this .h files?

Best regards, thanks for your time,

EMCCi

[EMCCi]

I have been able to find part of them from "Windows Kits" and Visual Studio, but still there are some that I can't find, or I can find them on the internet/system but there are a lot of different ones with different sizes.

How I should provide the .h files with "/" in the middle of the name?

Any help is appreciated.

[rolfk · Accepted solution]

They are unix specific files. Most likely your header contains conditional preprocessor macros that excludes these include statements if a specific define has been definde such as _MSC_VER which is defined when the code would be compiled with Microsoft Visual C.

Aside that this is the wrong way of testing macros (testing for Microsoft Visual C in order to exclude Unix/Linux headers is not correct as those two have no logic connection together) you will have to investigate the headers and define in the Import Library Wizard the according macros to make the unneeded includes go away.

Another remark: A header file with such a long list of includes has at least one of these problems:

1) It probably hasn't been cleaned up to only contain includes that are really necessary for the processing of the header file itself but also contains includes that were needed for the compilation of the DLL itself. Not a good practice at all.

2) If it really needs all those headers then it is a total mess. A header file is the interface description to a module. And a module should export a concise interface.

With all those headers included, if they are really needed at all, that interface is pretty much going all over the Linux API including low level specifications that an application should not be concerned about. Almost all double level header files (header files in sys, net, netinet directories) in Unix are close to the platform itself and describe features that are often not easy to translate to other platforms including other Unix platforms. It is sometimes necessary to include one of them in a header file, but so many!!!!!!! That library must be pretty much violating the principle of doing one thing good and only one thing and instead tries to do many different things, most likely badly.

And plese don't rely on the Import Library wizard to generate fully functional VIs, because it simply can't do that. The C syntax in a header file is by far not rich enough to describe all aspects of an API. In addition the C syntax is in several ways ambigious.

For instance there is no syntactical difference between a single scalar passed by reference and an array. So if the Import Library wizard decides to pass a single U8 character to a parameter declared as char * he is totally correct, even if the library function expects a 1MB buffer there to write something into it!

Aside from that anything that requires memory management decisions such as arrays, strings etc to pass to the function needs manual care by the programmer anyways as the Wizard can not even start to guess what it should really do. It has basically the choice between doing nothing, preparing a small buffer that is often to small, or using a huge buffer that could still be to small but most times will just hog memory unneccessarily.

[EMCCi]

Hi rolfk,

I know nothing about C, and the DLL's come from the source code of the mongo-c-driver. So it's probably my fault. When I was trying to do it with the wizard, it was always complainning about more and more missing header files. Then, as you already said, all VI's where broken and incomplete.

So I have spent some days reading about C and I'm doing it well manually with call library function. Also partly, thanks to answers from you and nathand to already existent questions. So you have already helped me with the project.

Thany you so much,

EMCCi

[rolfk]

---

@EMCCi wrote:

So I have spent some days reading about C and I'm doing it well manually with call library function.

---

That's what I always do. The Import Library Wizard is an impressive piece of software that tries to solve a problem that is in reality unsolvable. The C syntax is simply not strong enough to describe all the intricacies of calling functions and especially has absolutely no indications about memory management requirements for particular parameters. So unless the API is really very trivial, it creates mostly a bunch of VIs that are partly correct. Creating those VIs itself is indeed some boring repetitive work that could be automated but in comparison to the real work of making sure that the VI works efficiently and most importantly correctly, this is a minor effort.

Also I almost always ended up modifying the wizard generated VIs very significantly since it sticks very tightly to the C API and can't do useful adaptions to how a casual LabVIEW user would expect VIs to work in respect to handling arrays and strings. Besides it is totally lost about proper buffer management for string and array parameters and that is not just a cosmetic problem but a fundamental problem that makes the difference between crashing (or silently corrupting memory) and properly working.

Much of the knowledge of proper buffer management is specific to a particular API and generally only understandable by reading the library documentation if available, consulting sample C source code to understand what needs to be done, or in the worst case common sense derived from variable naming and lots of trial and error.

Another factor might be the icons 😀. As a somewhat OCD challenged person I really do not like the import wizard generated icons! 😎