Import shared library(dll)

[Jacemdom]

Salut.

I want to import the GetVolumeInformationW function from the Windows kernel32.dll.

Microsoft says:

Requirements

Client Requires Windows Vista, Windows XP, Windows 2000 Professional, Windows NT Workstation, Windows Me, Windows 98, or Windows 95.

Server Requires Windows Server "Longhorn", Windows Server 2003, Windows 2000 Server, or Windows NT Server.

Header Declared in Winbase.h; include Windows.h.

Library Use Kernel32.lib.

DLL Requires Kernel32.dll.

Unicode Implemented as GetVolumeInformationW (Unicode) and GetVolumeInformationA (ANSI). Note that Unicode support on Windows Me/98/95 requires Microsoft Layer for Unicode.

1- I start the wizard, select "Create VIs for a shared library" then click next

2- Then select C:\WINDOWS\system32\kernel32.dll for the shared library.

3- Then select C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\WinBase.h for the header file

4- Click next

5- Add C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include to the include path (for Windows.h)

6- Click next...wait

7- Then NI says :

The shared library contains 949 function(s), among which the declarations of 0 function(s) are found in the header file and these function(s) will be imported. The remaining 949 function(s) listed below cannot be imported.

How can i make it work? Is it possible?

[David Boyd]

Salut.

I want to import the GetVolumeInformationW function from the Windows kernel32.dll.

Dominic,

Just off the top of my head :

Many or most of the functions in kernel32 have both widechar and ANSI versions (like GetVolumeInformationW and GetVolumeInformationA). The prototyping in the .h file has some fancy #ifdef directives which get you to one or the other version, if you're a C compiler, since the C programmer just uses the syntax GetVolumeInformation, which is platform-independent. I think that the wizard is able to parse more straightforward header files, but loses all hope when presented with one of the Windows core components headers.

You can look up all the kernel32, advapi, winspool, etc. function documentation using the online MSDN references, then do all the CLN configuration yourself. It's a drag, but I just don't think the new wizard is capable of following all the preprocessor #ifdefs and nested #includes found in the header files you have.

Sorry this isn't the answer you sought.

Best regards,

Dave

[Jacemdom]

Sorry this isn't the answer you sought.

When i ask a question, all answers are welcome

Your answer is the biggest direction/tip i got so far...

[Mike Ashe]

... <snip> ... It's a drag, but I just don't think the new wizard is capable of following all the preprocessor #ifdefs and nested #includes found in the header files you have.

Sorry this isn't the answer you sought.

So close, but NQRFPT yet. Maybe in 8.5 or 9.0 ...

[Rolf Kalbermatter]

So close, but NQRFPT yet. Maybe in 8.5 or 9.0 ...

I think it is amazing they even got it that far. As to supporting any and every header file format, this is going to be impossible. The windows.h header file hierarchy is so complicated, riddled with almost magic macros and other compiler specific stuff that to get this done you would have to create a real compiler. And that together with writing an OS is one of the things you absolutely do not want to do in LabVIEW.

Every C compiler out there comes with its own platform SDK header files in order to support the specifics of that compiler. To try to compile with the original Windows SDK headers with another compiler than Visual C is almost impossible and a sure way to go insane, while you try to figure out which modifications need to be done to the several 100 headers to get them to not cause compile errors anymore.

In addition there are several more or less commonly used C features LabVIEW simply can't deal with (yet), such as function pointers and complicated structures.

Rolf Kalbemratter

[Mike Ashe]

I think it is amazing they even got it that far.

I agree. I didn't meant the NQRFPT as a criticizm, just recognition that, like many new features we get over the years, the first version or two still needs some smoothing out. I said elsewhere that the new DLL stuff is one of my favorite features of the new LV version.