LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

The BOM (byte-order mark) in header file not understood by the DLL importer

Solved!
Go to solution

Hello,
It seems that the BOM (byte-order mark) in header file is not understood by the DLL importer.
When having a BOM (for example \0xEF \0xBB \0xBF) at the beginning of the header file:

The DLL importer cannot complete the DLL import.

It is stuck in the step "Parse Header file", with the message "This might take a few minutes. Please wait."

The only option is to kill Labview with the Windows task manager.

Version: Labview 2016

Is this bug corrected in future versions?

Is there any work-around for Labview 2016 (other than changing the text files encoding) ?

Best regards

0 Kudos
Message 1 of 7
(676 Views)

No, the Import Library Wizard requires clean 7-bit ASCI files. No BOM, pseudo or real Unicode or whatever format is allowed. No normal programming editor should actually use BOMs as the C language is fully 7 bit ASCII code conformant so there is no use in even trying to add BOM headers or whatsover to it.

 

The BOM most likely comes from editing the file in Windows Notepad, which despite being a minimalistic text editor insists in treating files as Unicode files. I would recommend Notepad++ instead which is much more capable and allows you to specify in what format the file should be saved.

Rolf Kalbermatter
Averna BV
Message 2 of 7
(631 Views)

"No normal programming editor should actually use BOMs as the C language"

=> So : QT creator, Visual Studio, Notepad++ are not "normal programming editors"?

Visual C++ and GCC are not normal compilers?

😂 

 

"The BOM most likely comes from editing the file in Windows Notepad, which despite being a minimalistic text editor insists in treating files as Unicode files. I would recommend Notepad++ instead which is much more capable and allows you to specify in what format the file should be saved."

=> Actually I am using Notepad++, which perfectly manages UTF8+BOM files.

 

I am new to this forum and my first impression is that bug reports and ideas are not taken with enough consideration.

It also seems that I am not the only one 

0 Kudos
Message 3 of 7
(593 Views)

Hi pierre,

 


@pierre.belissent wrote:

I am new to this forum and my first impression is that bug reports and ideas are not taken with enough consideration.


Did you post any idea in the IdeaExchange?

Did you file any bug report to NI and did you get a response, maybe even a bug report number (formerly known as CAR)?

 

All you did was asking volunteers in the public forum about an opinion on your observation…

 


@pierre.belissent wrote:

Actually I am using Notepad++, which perfectly manages UTF8+BOM files.


That's fine!

Then you just need to implement the workaround you already wrote in your first message by saving the text as pure ASCII text. That's what the tool you want to use expects…

Best regards,
GerdW


using LV2016/2019/2020 on Win8.1/10+cRIO
0 Kudos
Message 4 of 7
(590 Views)

The fact that your Visual C editor can deal with reading files with a BOM does not mean that those files MUST or even SHOULD contain BOMS. i use Visual Studio too and it does not force BOMs into a file when I save them.

 

Same about Notepad++. It can handle a myriad of file encodings and you CAN configure it which to use when saving files. You do not NEED to save it as UTF8 with BOM like when you use the normal Notepad editor!

 

As about this being a bug, I disagree. C does not know any syntax element that requires more than 7 bit ASCI codes so it is perfectly fine to save a C file as such. The ability to read UTF8 files with BOMs is a feature that you could request in the idea exchange but the lack thereof is certainly not a bug.

 

Besides, the import library wizard is a nice tool but unfortunately gives many users the wrong impression that importing DLLs into an environment like LabVIEW is child's play. it’s not! The C syntax in a header file is not able to describe the more difficult aspects of proper memory management for string and array parameters and consequently the Import Library Wizard has to do a lot of guessing and assuming in that regard. Generally speaking any more than trivial C API requires a very detailed and diligent manual review and correction of the generated VIs after the Import Library Wizard is finished. And that’s not a bug either of it. The wizard simply can’t invent information that isn’t in the header file. That’s why guys like Microsoft invented .Net and called it managed, as it comes with a whole set of rules too who has to manage the memory for parameters and in which way when passing around memory buffers to callees and back. It also comes with provisions such as a type library which describes more aspects of a API than what a C header file could do, even when it would use non-portable attributes and pragmas. 

 

LabVIEW is also a managed environment but its rules were developed more than 10 years before Microsoft thought about creating a copy rival for Java and are therefore different than what . Net uses. But the LabVIEWs .Net interface does the necessary translations for you. Nothing like that exists in C DLLs. Memory can be allocated by the caller or callee in whatever way the DLL programmer desires. Yes there are certain conventions but they are conventions and any DLL programmer is free to follow them or not, for good reason or simply to show off how cool he is!

Rolf Kalbermatter
Averna BV
0 Kudos
Message 5 of 7
(580 Views)
Solution
Accepted by pierre.belissent

I am sorry, but the fact that the tool is stuck, without message, and the only option is to kill Labview with the Windows task manager, looks like a bug to me.

I know that the DLL importer is not a trivial tool, and this is why I spent hours investigating what was wrong in my DLL (there are so many things that could go wrong...).

A message "Bad file format" or "Can't read file" or anything else would have been nice.

Best regards

0 Kudos
Message 6 of 7
(543 Views)

Hi pierre,

 


@pierre.belissent wrote:

I am sorry, but the fact that the tool is stuck, without message, and the only option is to kill Labview with the Windows task manager, looks like a bug to me.

A message "Bad file format" or "Can't read file" or anything else would have been nice.


So did you file a bug report to NI? Did you get a bug number?

Best regards,
GerdW


using LV2016/2019/2020 on Win8.1/10+cRIO
0 Kudos
Message 7 of 7
(528 Views)