Importing DLL Preprocessor help needed

[geekodude]

Hello all:

I am using LV 2023 32-bit and I am trying to create DLL wrappers using the Import Shared Library wizard.  The first 15 functions the wizard can import, but the latter 13 the wizard wants preprocessor definitions.  I am not a C++ programmer so any help would be greatly appreciated.

Attached is the 32-bit DLL, and the header files.

[Jacobson]

For the functions that can't be imported, does the wizard give any indication of what types it can't interpret? Not sure all of the following is 100% correct but here's what I remember.

When a function is defined it's pretty typical that not all of the parameters will be basic C types but LabVIEW generally needs to be able to figure out how to break these types down into their basic components. As an example of something that might be an issue, if LabVIEW is trying to build a wrapper for the COFFR_GetFileHdr function, it needs to figure out what the inputs and outputs to the wrapper VI will be. Now one of the parameters is TI_FILHDR but that parameter doesn't seem to be defined in any of the files you gave us so LabVIEW might not be able to figure out what input/output type is supposed to be used.

When the wizard is asking for additional preprocessor definitions it's essentially asking you to locate where that TI_FILHDR type is defined. The resolution might be as simple as just finding what header includes the TI_FILHDR typedef or #define.

[rolfk]

f2833x.prg.h doesn't seem to use any non standard C datatypes other than DWORD and three functions with parameters that you can not implement in LabVIEW.

PRG_SetMessageCallBack() and RG_SetReportCallBack() use a callback pointer which can't be implemented in LabVIEW and PRG_GetInterface() uses a structure with function pointers, again nothing LabVIEW could do without some (quite a bit actually) extra help from an intermediate DLL written in C(++).

If you need any of these 3 functions you would have to spend some major effort in writing some intermediate C code to interface to them from LabVIEW in any meaningful way. Most likely however the callback functions are not necessary and the GetInterface() function looks like something only a low level C hacker wants to use.

cofflib.h seems more complicated. There are several functions that use datatypes starting with TI_something that are nowhere defined, so the import library wizard of course has to complain. There must be somewhere some extra TI header that would define these types.

Datatypes that you can't (easily) deal with in LabVIEW:

- STRTAB defines a linked list with internal pointer pointing to its own type

- COFF_FILE_INFO has several pointer data elements in there, not impossible to do but a real pain in the ass even for anyone with A LOT of C(++) programming experiences. Impossible to do if you know virtually nothing about C.

COFF_HNDL_INFO contains a COFF_FILE_INFO and therefore has the same problem.

You can however avoid this whole stuff by replacing the definition:

typedef COFF_HNDL_INFO * COFF_HNDL;

with this one:

typedef void * COFF_HNDL;

This declares the COFF_HNDL datatype as a opaque pointer so that LabVIEW simply can use a pointer sized integer for it. You better make sure that you call on every successful COFFR_FileOpen() call that returns such a handle an according COFFR_FileClose() or you loose potentially large amounts of memory with every FileOpen() call that is not eventually matched with a FileClose() call.

Then you have the functions that use some TI_ datatypes that are nowhere declared. You'll have to hunt down the according header file and add it to the import library wizard input.

COFFR_GetFileHdr() uses the unknown datatype TI_FILHDR

COFFR_GetOptionalHdr() uses the unknown datatype TI_AOUTHDR

COFFR_GetSectionHdr() uses the unknown datatype TI_SCNHDR

COFFR_GetSymbolTableEntry() uses the unknown datatypes TI_SYMENT and TI_AUXENT

COFFR_GetSymbolName() uses the unknown datatype TI_SYMENT

COFFR_GetSectLnno() uses the unknown datatype TI_LINENO

[geekodude]

Thanks guys, I really appreciate the responses.

[geekodude]

Hi Rolf, attached is the file for the following declarations:

"Then you have the functions that use some TI_ datatypes that are nowhere declared.

COFFR_GetFileHdr() uses the unknown datatype TI_FILHDR

COFFR_GetOptionalHdr() uses the unknown datatype TI_AOUTHDR

COFFR_GetSectionHdr() uses the unknown datatype TI_SCNHDR

COFFR_GetSymbolTableEntry() uses the unknown datatypes TI_SYMENT and TI_AUXENT

COFFR_GetSymbolName() uses the unknown datatype TI_SYMENT

COFFR_GetSectLnno() uses the unknown datatype TI_LINENO"

[dineshkumar2004]

when i tried to import functions in import shared library x mark is shown before the functions i want to eradicate this problem as soon as possible i searched so mant times but didn't find the solutions. it's so difficult for me because i really don't know about c++ .then what can i do here i found you in ni community you helped someone to sort out the problem so please me out.

[Andrey_Dmitriev]

---

@dineshkumar2004 wrote:

when i tried to import functions in import shared library x mark is shown before the functions i want to eradicate this problem as soon as possible i searched so mant times but didn't find the solutions. it's so difficult for me because i really don't know about c++ ...

---

This wizard is "designed" to work with basic types that LabVIEW recognizes. It means that some of the more complex types in your header file might not be supported by this tool. While it often works well for simpler cases, you may sometimes need to manually adjust the header to make it compatible with the wizard. In more complicated situations, it might be easier to create an intermediate wrapper or manually create SubVIs with according CLFNs.

It's worth noting that this is related to "c++". If you're not familiar with C language, it might be challenging to deal with this task. In that case, I'd recommend starting with the classic book written by Kernighan and Ritchie (sometimes termed K&R) to build a solid foundation in C programming first. This knowledge will make it much easier to understand and work with such headers and functions in the future.

[rolfk]

First we don't have your headers, so can't tell you what might be the problem.

Second as Andrey pointed out already, this is C programming knowledge. If you don't know how to program in C, you can not really use the Import Library Wizard for anything but the most trivial DLL interfaces.

You have then pretty much 3 options:

1) Learn C programming to understand the difficulties with this and be able to fix them yourself by modifying the header files, add some extra defines or extra include directories to the first stage in the Wizard, or if things involve datatypes that are difficult or impossible to implement directly through the Call Library Node, write an intermediate DLL in C(++).

2) Pay someone to do these things for you.

3) Post all the relevant information including the header files and any documentation for your API and hope that someone here can point you out what steps might be helpful to let the Import Library Wizard work for you, although the advice may also be that you can't really make this work with the Import Library Wizard alone but may need to either abandon the Import Library Wizard and work very hard on the LabVIEW diagram to play C compiler to make this work, or write your own wrapper DLL in C to convert between convenient LabVIEW datatypes and your DLL interface.