CINTOOLS for ARM exists? Resize String in c++

[x y z]

Hello!

I'd like to resize LStrHandle string in a C++ based DLL ... which is perfectly working on desktop Windows (ex.:Win7 32/64 bit) platform by include "extcode.h"  and linking "labviewv.lib", with calling "NumericArrayResize" function.

BUT I'd like to do the same on Windows Embedded Compact 7.0 with ARM(Cortex-A8).

When I build the DLL project on "Smart device / WindowsCE" platform it compiled successfully but the linker stopped because "NumericArrayResize" is unresolved symbol ... I think the reason is that the "labviewv.lib" generated for x86 architecture not for ARM.

So my question is: Is there any libviewv.lib for ARM platform?

Edited June 27, 2017 by x y z

[Rolf Kalbermatter]

On 6/27/2017 at 7:12 PM, x y z said:

Hello!

I'd like to resize LStrHandle string in a C++ based DLL ... which is perfectly working on desktop Windows (ex.:Win7 32/64 bit) platform by include "extcode.h"  and linking "labviewv.lib", with calling "NumericArrayResize" function.

BUT I'd like to do the same on Windows Embedded Compact 7.0 with ARM(Cortex-A8).

When I build the DLL project on "Smart device / WindowsCE" platform it compiled successfully but the linker stopped because "NumericArrayResize" is unresolved symbol ... I think the reason is that the "labviewv.lib" generated for x86 architecture not for ARM.

So my question is: Is there any libviewv.lib for ARM platform?

The LabVIEW PDA Toolkit is not supported anymore as you may know and that is the only way to support Windows CE platform.

That said, labview.lib basically does something like this which you can pretty easily program yourself for a limited number of LabVIEW C functions:

 

MgErr GetLVFunctionPtr(CStr lvFuncName, ProcPtr *procPtr)
{
	HMODULE libHandle = GetModuleHandle(NULL);
	*procPtr = NULL;
	if (libHandle)
	{
		*procPtr = (ProcPtr)GetProcAddress(libHandle, lvFuncName);
	}
	if (!*procPtr)
	{
		libHandle = GetModuleHandle("lvrt.dll");
		if (libHandle)
		{
			*procPtr = (ProcPtr)GetProcAddress(libHandle, lvFuncName);
		}
	}
	if (!*procPtr)
	{
		return rFNotFound;
	}
	return noErr;
}

The runtime DLL lvrt.dll may have a different name on the Windows CE platform, or maybe it isn't even a DLL but gets entirely linked into the LabVIEW executable. I never worked with the PDA toolkit so don't know about that.

 

 

[x y z]

[...]The LabVIEW PDA Toolkit is not supported anymore [...]

Just for the record: I'm working with LV2010 + Touch Panel module (Windows CE 5.0)  the device is a Windows Embedded Compact 7.0 (ARM Cortex-A8) based HMI.

 

So what you suggest in your post it would be a cool idea, but as you suppose, LabVIEW Touch Module build a single EXE file.

When I looked into the EXE with hex editor there wasn't any sign of NumericArrayResize function and this is normal for EXE. That's why the example code above not working.

Two way left:

1. Before DLL call, presize buffers and strings in LabVIEW and check the size limits in DLL
2. DLL callback functions to give back buffers and strings to LabVIEW to resize them with the LabVIEW memory manager and give them back to DLL (overkill)

I've chosen solution #1.

Thank you for your help!

Edited July 18, 2017 by x y z

[Rolf Kalbermatter]

On 7/18/2017 at 1:33 PM, x y z said:

[...]The LabVIEW PDA Toolkit is not supported anymore [...]

Just for the record: I'm working with LV2010 + Touch Panel module (Windows CE 5.0)  the device is a Windows Embedded Compact 7.0 (ARM Cortex-A8) based HMI.

 

So what you suggest in your post it would be a cool idea, but as you suppose, LabVIEW Touch Module build a single EXE file.

When I looked into the EXE with hex editor there wasn't any sign of NumericArrayResize function and this is normal for EXE. That's why the example code above not working.

Two way left:

1. Before DLL call, presize buffers and strings in LabVIEW and check the size limits in DLL
2. DLL callback functions to give back buffers and strings to LabVIEW to resize them with the LabVIEW memory manager and give them back to DLL (overkill)

I've chosen solution #1.

Thank you for your help!

I never worked with that Toolkit but if it is even possible to use the PDA Toolkit for development of Windows Embedded Compact 7.0 targets (there might be some serious trouble since Windows CE 5.0 is really a quite different platform than Windows Embedded Compact 7.0, almost as different than Android and iOS in comparison. Windows CE 5.0 was mainly for MIPS based platforms which was what Microsoft thought would be the future for embedded, although it also supported x86 and ARM platforms, but I'm not sure if the PDA Toolkit comes with support for all these platforms).

But, I have a feeling that if it is possible, there are some object libraries that need to be linked with the compiled object files that were created by the PDA Toolkit. These object libraries provide all the LabVIEW manager functions in one way or the other. So it might be enough to simple create a C file that calls these functions and add it to the list of files to compile and link to create the final executable.

The PDA Toolkit works AFAIK such that LabVIEW basically creates C++ files from the VI files, that then get compiled and linked with Toolkit provided support libraries to the final executable with the help of the Microsoft CE development system and compiler. So those functions must somehow call the manager functions too to manipulate the used memory blocks. I remember that it was kind of tricky to get at the according C++ files as the build process creates them only temporarily and then deletes them immediately after the C compiler compiled them into the object files. But I remember that when I played around with one of the Toolkits back in the very old days, I actually managed to get at those files somehow.

Edited July 24, 2017 by rolfk

[x y z]

On 7/23/2017 at 6:33 PM, rolfk said:

The PDA Toolkit works AFAIK such that LabVIEW basically creates C++ files from the VI files, that then get compiled and linked with Toolkit provided support libraries to the final executable with the help of the Microsoft CE development system and compiler. So those functions must somehow call the manager functions too to manipulate the used memory blocks. I remember that it was kind of tricky to get at the according C++ files as the build process creates them only temporarily and then deletes them immediately after the C compiler compiled them into the object files. But I remember that when I played around with one of the Toolkits back in the very old days, I actually managed to get at those files somehow.

Sorry for late reply, I didn't see any alert from this topic ... my bad

So I've found an other solution/hacking and it is similar as you mentioned, but at lower level of building process.

#1 Create "Smart Device" C++ project in Visual Studio 2008. Choose SmartPhone 2003 (ARMV4) SDK (this is an another story but in short Labview2010 need for this, see: Arm vs. Thumb)

#2 DLL or LIB project type is fine (DLL project won't linking because of missing NumericArrayResize reference but its ok we need only OBJ files of the project).

#3 Build the project! OBJ files are generated as intermediate files between compiling and linking phase of the building process.

#4 Grab all OBJ files and attach them to LabVIEW Touch Panel project tree

#5 Add the OBJ files as "Additional files"  in LabVIEW project -> Touch Panel -> Build Specifications -> "Source files" -> "Additional files"

#6 Build Touch Panel project, it should compiling successfully.

This trick made the LabVIEW linker to link the referenced functions (NumericArrayResize) between my code and the LabVIEW code. In other word I've injected my codes as OBJ files into the LabVIEW building process.

I've used this method because it is pleasure to work with Visual Studio and test the code on HMI. When everything is ok with C++ code, then just build VS SmartPhone LIB project and use it in the Labview project.