Migrating LabXML tool to 64bits

[MountainClimber]

Hello !

This post is not exactly about LabVIEW concerns, but I'll try anyway 😉

We have been using the LabXML tool in several applications for a long time, without problems (downloaded from here : http://sourceforge.net/projects/labxml/files/LibXML-toolkit/).

Now, we are migrating one of those big application to LabVIEW 64bits, so we need to update LabXML to 64bits.

Theorically, we just have to recompile the dlls to 64bits and that's all ! But it's not that simple...

LabXML is using 'Call library function' nodes to call 2 dlls : libxml and IXMLWrap.

To update these dll to 64 bits, I tried the following :

- libxml : this one is depending on other dlls (iconv, zlib). I downloaded the 64 bits versions from : ftp://ftp.zlatkovic.com/libxml/64bit/

- IXMLWrap : this one is depending on libxml and libxslt (also downloaded from above). I have the .c file (enclosed) and I tried to compile it with visual studio, and successed ... almost !

I get a home compiled 64bit IXMLWrap dll, but impossible to load it with LabVIEW 64 bits...

When reading the dll with "Dependency Walker" 64bits, I get some errors about missing export functions.

Indeed, when I compare the 32 and 64 bits dlls with Dependency Walker, I do have the same functions in the dlls, but do not have the same exported functions ... (see images enclosed)

I have 2 questions :

- has someone already tried to use LabXML with 64bits labVIEW, and already has the dlls to share ?

- does someone has some hint about what is the problem with my IXMLWrap dll : incorrect downloaded dlls, problems in the configuration of my Visual studio project, ... ?

I'm sorry about my "stupid" questions, but my C developer experience is far away behind me ... 😞

Thanks for your help !

[MountainClimber]

missing some enclosed files

[MountainClimber · Accepted solution]

OK, it's all my fault...

I did the link with .lib files ... coming from linux (not windows)!!

No problems then to compile and use the 64bits dll

[TroyK]

Hello Saphir,

There is a NI community page on using libxml2 here: https://decibel.ni.com/content/docs/DOC-30377

We would like to also include a 64bit version. As you noted above, most of the 64bit dlls are available for Windows except IXMLWrap.dll.

Could you please attach the 64bit IXMLWrap.dll that you compiled so others can make use of it?

Thanks,

[EricH]

Hi,

My colleagues and I managed to compile lXMLwrap.c into a 64 bit dll. Also required are the 64 bit versions of several dll dependencies. Attached is a 64 bit lXMLwrap.dll and all the other required 64 bit dlls. All the contents should be extracted into the same folder.

Cheers,

Eric

[MikaelH]

Hi Eric,

I love the 64 bit version. I've made a wrapper class that supports both 32 and 64 bit (LV2016). But from time to time the 64 bit version crashes the application. I guess it's a reference handle coming out from the dll that is defined as U32, but when it gets compiled into 64-bit it will use U64 (e.g. void*).
So when the pointer happens to be >2^32 then the application will be instable and soon crash.
I normally use the Data Type: “Unsigned Pointer-sized Integer: for the return value from a dll that was a void* pointer return value.
This will make it 32 or 64 bit depending on what LV version you are using.

So my question is what does the header file for the IXMLwrap_64.dll look like?
Can you share the files you used to build the 64 bit version?

I’ve attached a wrapper class that makes it simple to convert NI’s version to LibXMLs, see example VIs

[MikaelH]

Hi Again

I've modified all pointer inputs and outputs to the dll to be using the data type: “Unsigned Pointer-sized Integer".

(Or at least all DLL calls for reading and parsing)

That means in 64 bit I get a 64-bit pointer value out from all dlls calls.

In my wrapper class I've but a Conditional Strcuture around all DLL calls to use different dll's depending on the "TARGET_BITNESS".

That means my driver works in both 32 and 64 bit versions.

After doing this change I've not yet seen anymore crashes.

I've had this issue before on other dll's that got converted to 64 bit. The pointer(ref-handle) coming out from a dll that is build in 64 bit could have a value over 2^32, but that doesn't happen too often (depends on how much memory you have installed and the current ram memory usage).

But if I get a higher number then 2^32, I'll get the wrong value, and when using this pointer to the next dll call the pointer value will most often crash LV.

[nottilie]

Hi

I try to use the x64 xml class in LV 2017f2 x64.

When I open the class itselves Labview is always working in background for some seconds and is finally unusabe.

Has anyone tried to use it in LV2017.

I also observed from a different DLL that the calling (sepecially x64 pointers) are much more critical in LV2017 compared to LV2016.

Please can somebody state onto the LabXML status on LV2017.

Thank you all

[MikaelH]

I see similar issue on Win10, in LV 2016 & 2018 64 bit.
When LV loads the dll: libwinpthread-1.dll, it freezes for a while and Windows adds an error in the Event Log.
It keeps filling up the Event log, this is from my event log:

Faulting application name: LabVIEW.exe, version: 18.0.1.4001, time stamp: 0x5ba1d799
Faulting module name: libwinpthread-1.dll, version: 1.0.0.0, time stamp: 0x02911bc0
Exception code: 0xc0000005
Fault offset: 0x0000000000006500
Faulting process id: 0x3ab0
Faulting application start time: 0x01d4bc0f902c6407
Faulting application path: C:\Program Files\National Instruments\LabVIEW 2018\LabVIEW.exe
Faulting module path: C:\Program Files\National Instruments\LabVIEW 2018\user.lib\_LabVIEWCommon\LcXML\LibXML2_class\private\dll\libwinpthread-1.dll

Faulting application name: LabVIEW.exe, version: 16.0.0.4024, time stamp: 0x59efba36
Faulting module name: libwinpthread-1.dll, version: 1.0.0.0, time stamp: 0x02911bc0
Exception code: 0xc0000005
Fault offset: 0x0000000000006500
Faulting process id: 0x3d40
Faulting application start time: 0x01d4b9d99c9a275c
Faulting application path: C:\Program Files\National Instruments\LabVIEW 2016\LabVIEW.exe
Faulting module path: C:\Program Files\National Instruments\LabVIEW 2016\user.lib\_LabVIEWCommon\LcXML\LibXML2_class\private\dll\libwinpthread-1.dll

I puzzled 😞

[nottilie]

We have moved to .NET xdocument to solve this problem.

We only needed some XML features which were "easily" possible created in the .NET xdocument class.

The speed of this implemetation is absolutely fine compared to the labviews internal XML speed.