nivirtualbench.lib for Borland C++ builder

[ja_sws]

I am working on a project which involves integrating Virtual Bench into an existing desktop application that was developed by our customer using Borland C++ Builder.

I have run the virtual bench installer "NIVirtualBench1700f0.exe" and I have been able to operate the virtual bench using the packaged application. Also I have compiled the example code provided under visual studio and it is working fine.

But I am unable to link the virtual bench library when I compile using Borland C++ Builder. I have checked the install path for the library and found that the file named "nivirtualbench.lib" is missing from the ni folder where the borland library should be.

I attached screen shots below showing the folder locations for both the borland and visual studio library files.

It looks like the library is missing.

Does anyone know where I might be able to download the Borland library for virtual bench?

[andres.vargas]

I am sorry if I am missing something, shouldn't the .lib files be exactly the same?

Have you tried copying it from the Visual Studio folder to the Borland folder?

[rolfk]

Yes you are missing something. The object libraries for Borland C are using the OMF (Intel Object Module Format) while Microsoft C uses COFF (Common Object File Format). LabWindows CVI used to be able to support both although it was a (re)installation choice which one it would support (for importing, it could generate both library formats if one selected that). The latest versions of LabWindows CVI however only support the Microsoft COFF format, which is likely the reason that the Borland link libraries are now missing in the Virtual Bench API installation.

So there are likely two solutions for the OP (kind of late but still):

1) find an older NI Virtual Bench installation that was generated with an older version of LabWindows CVI and still contains both libraries.

2) Use one of the several COFF to OMF conversion tools out there and pray that the resulting library works correctly. Borland C used to come with such a tool preinstalled. But since these libraries are simply import libraries for the actual DLL in question, chances are pretty good that the conversion tool is not tripping over its own feet and succeeds to create a correct import library in the other format.

3) If all else fails one could create its own import library by using the LoadLibrary() and GetProcAddress() Windows APIs to create thin wrappers that can then be linked into the resulting project. If you only need a few API functions, then this might be the quickest solution. For more extensive APIs this quickly can turn into a major project of its own however. With some somewhat advanced C macro magic it can be however kind of semi automated.