PDA: How does the VI in the "Calling External Code (Inline C Method)" example link to the called functions?

[Dan57]

The PDA module provides an example of calling external code via an inline C

The inline source code from the example:

     OSVERSIONINFO info;

     info.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);

     Err = GetVersionEx(&info);

     MajorVersion = info.dwMajorversion;

     MinorVersion = info.dwMinorversion;

The PDA build specification includes *no* additional source files of any kind.  The only source file in the build is the top-level VI.  Where are the definitions for the OSVERSIONINFO type, and the GetVersionEx function drawn from?

The VI builds and runs fine on the PDA, but I don't understand how.

[Donovan_B]

Hi Dan57,

OSVERSIOINFO is a structure that receives the operating system information.  It is defined in windows.h.  The GetVersionEx function is drawn from the Windows kernel32.dll.  There is no need to include the header files and dlls with the build because the C code generator with the Inline C Node automatically includes these.  This can be done because the LabVIEW PDA Module and LabVIEW Touch Panel Module only target machines running Windows operating systems (Windows Mobile and Windows CE).  For more information on these structures and functions, please visit the Microsoft Developer Network and reference the GetVersionEx Function.  There is a link at the bottom of the GetVersionEx Function page that will take you to the details of OSVERSIONINFO.

[Dan57]

Thanks, Donovan.

I'm still not clear on where the dll types and functions are coming from.  There's no kernel32.dll file on my PDA (running Windows Mobile 6, showing hidden files).  The only kernel32.dll on the host PC is located in the C:\Windows\system32 directory.  Does the Lab View PDA module link the XP version into the executable?  This would explain why some OS calls behave oddly (MessageBox displays empty squares for the ipCaption and ipText parameters - unknown font?).

[Donovan_B]

Hi Dan,

It looks like there is an OSVERSIONINFO struct and GetVersionEx function available in the coredll.lib for the application to call on a PDA running Windows Mobile 5.0.  On both operating systems, it looks like the GetVersionEx function is defined in winbase.h, so I am not sure if there is some kind of linking between the two or if the header file is automatically included when building the executable or not.  Let me do some more research and I'll let you know.

The information for the function on Windows Mobile can be found here.

Message Edited by Donovan B on 12-19-2007 06:33 PM

[rolfk]

---

Donovan B wrote:

Hi Dan,

It looks like there is an OSVERSIONINFO struct and GetVersionEx function available in the coredll.lib for the application to call on a PDA running Windows Mobile 5.0.  On both operating systems, it looks like the GetVersionEx function is defined in winbase.h, so I am not sure if there is some kind of linking between the two or if the header file is automatically included when building the executable or not.  Let me do some more research and I'll let you know.

The information for the function on Windows Mobile can be found here.

Message Edited by Donovan B on 12-19-2007 06:33 PM

---

While the API functions are mostly the same for Windows Mobile and normal Windows the actual implementation and compilation is obviously not and there is no need for that. Windwos Mobile is typically (not sure if there are other versions at all) ARM based, while the desktop version is x86 based. A huge difference.

And when LabVIEW creates a PDA executable it mostly creates a bunch of hidden C files, invokes the Visual C for Windows CE
tool chain and lets it create the executable. The Visual C for Windows CE tool chain comes with its own import link libraries for accessing WinAPI functions and those import link libraries reference the functions in the DLLs as they are implemented for Windows Mobile (CE). There is no kernel32.dll in Windows Mobile and why should it? You can't move normal Windows code that would expect that DLL to Windows Mobile anyhow, since it has a completely different CPU and there is always a complete recompile with the Windows CE toolchain necessary anyhow.

Rolf Kalbermatter