LabVIEW
1097 error calling DLL
It seems you are trying to interface WinASPI API directly. It has been a very long time when I checked into this (more than 10 years) but ASPI definitely is NOT an API that you want to interface to directly from the LabVIEW Call Library Node. An intermediate DLL written in C is almost the only feasable and for the long run maintainable solution. This intermediate DLL mediates between the ASPI API and a more LabVIEW friendly API that can be much easier interfaced from the Call Library Node.
If you insist on going this (IMHO fruitless) path you will need to provide much more information such as your VIs you have done so far, the API function declarations you try to interface to, together with all other declarations that might be used in there, and aren't standard WinAPI declarations. The chances that someone has tried to do the same as you did, is minimal and in that case the information you have provided so far is virtually useless as nobody is going further than clicking on your link, and it is unlikely anyone knows that this is in fact about WinASPI and even much more unlikely that someone will bother to dig up all the technical details across the web to understand what the complications might be. Even in the unlikely case someone does, there is no starting point in helping you since there is simply no information as to what you have tried so far and how, and where it might be really going wrong.
Writing a wrapper has nothing to do about knowing the source of the DLL you wrap, although it never hurts if you have that source available to check into particular implementation details. But if you use a C compiler to create a wrapper DLL and hand it the correct header files for your APIs you interface, this C compiler can handle some of the things that you must deal yourself manually when trying to configure the Call Library Node correctly. And it forces you more strictly to think about things like proper memory allocation and deallocation, things you have to do in LabVIEW as well when interfacing to C functions, but which often can get forgotten, since everythign else in LabVIEW is so automatic when it concerns memory management.
Well the WinASPI API is indeed a DLL wrapper to device specific APIs but don't let the word wrapper mislead you here. There are wrappers and wrappers. WinASPI is a so called manager wrapper that provides a common API to application to deal with any SCSI device or SCSI like device (it can also access IDE devices through the Windows API if done right, since IDE is simply a low cost way of SCSI device with a much lower level hardware interface exposed by the peripheral in order to save some logic circuitry on every peripheral. That was an important cost saving at a time, FPGA and such didn't even exist and you had to make custom mask semiconductors for anything integrated.
Now a wrapper for LabVIEW use is a different thing. It basically just exposes functions that have parameters that are easier to interface with the Call Library Node. C allows for arbitrarly complex parameter types. If the LabVIEW Call Library Node would support all variations and incarnation of what you can do in C, the configuration dialog would get extremely complex to the point were nobody but a professional C prgrammer could understand it anyways. It doesn't mean that you can't interface to more complex parameter types but you have to do sometimes pretty low level C stuff, that are at least partly taken care of by the C compiler if you program that API call in C. Other things like memory allocations and such have to be done in either case explicitedly but it is a standard thing for a C programmer to have to do that explicitedly and a very rare thing to do for a LabVIEW programmer on the other hand. So it is a steep learning curve for the average LabVIEW programmer.
Now the API you show as example isn't even one of the more complex variants to interface. However you make the standard error of mistaking fixed size arrays in a struct as being the same as array pointers. That is truely wrong, as a fixed size array gets always inlined in a structure by any C compiler, so it is in fact more synonymous to a LabVIEW cluster of that many elements embedded inside the outer cluster. This is since LabVIEW doesn't know fixed size arrays and even if it did it is not clear that it would use the same inlining as is common in C. And if the structure contains real array (or string) pointers you still couldn't just assign LabVIEW arrays to that cluster element. A LabVIEW array is always a pointer to a pointer to a data structure that contains both the number of elements in the array as well as the array data. A C array only is a pointer to the array data without any explicit size indication. This makes passing arrays to C functions also very error prone for buffer overflows unless the API designer takes a lot of care to use extra parameters that give the function information about the size of the array. And to make things even more complex there is something called alignement. This means that a C compiler usually aligns every element in a cluster to the smaller of either its inherent memory size or a default alignment. And Windows DLLs usually use a default alignment of 8 so a double would be always aligned to an address that is a multiple of 8, and int32 bit to an address that is a multiple of 4 and so on. LabVIEW uses on Windows 32 Bit a default alighment of 1 meaning it packs data as tightly as possible into the memory. So to interface to a DLL using a default alignment of 8 you often have to add filler bytes between parameters. To make matters even more interesting a DLL programmer can change the default alignment used for parts or the entire DLL by either using @pragma derectives in the C source code (which is usually visible in a header if you get that) or through a compiler command option, that you seldom will see if you don't get the makefiles too with the DLL (and that usually means only for DLLs where you get the source code too).
So for the API you show you could get away by replacing your arrays by clusters of 16 unsigned 8bit integers each. Other WinASPI APIs however do sometimes take structures with embedded pointers and handling that without some serious C detail knowledge is a very crash intense exercise.
Well my remark about "fruitless" was specifically targeted at the attempt to interface the original ASPI API directly with the Call Library Node without using any intermediate C DLL. The reason for this is, that APIs like ASPI with functions with rather complex parameters require a level of C knowledge that makes the creation of an intermediate DLL a snap. Add to that the fact that a convoluted VI library, doing all kinds of crazy C like things in the diagram of the different VIs to prepare various parameters in a way that the C function will be able to use, is a complete nightmare to maintain in the long term. These two reasons alone make the creation of an intermediate library that can mediate between the original C API and an API that uses more LabVIEW friendely parameters a very desirable thing.
That all said, if you are specifically only targetting modern Windows systems with this, a more desirable approach would be probably to interface directly to Windows SPTI API instead of installing FrogASPI which seems just an ASPI<->SPTI translation layer anyways. And no the SPTI interface isn't easier to interface with a Call Library Node directly, but IMHO you end up doing the intermediate DLL anyways, so interfacing SPTI or ASPI shouldn't make any difference. The only reason to use FrogASPI would be if you want to maintain binary compatibility for Win95/98/ME which had no SPTI but came with a licensed version of WINASPI. But honestly who is going to support Win9x/ME for new developments nowadays? And what market could that possibly serve?
