Unicode problem on Linux and Windows

[Q^Q]

I recently noticed that LabVIEW has different character encoding format for Chinese characters on Linux and Windows.  I'm not sure but feels like that LabVIEW accept and display unicode characters on Linux, but it use non-unicode on Windows.   So, if I put some Chinese characters in a VI on Windows, they cannot be displayed if I open the VI on Linux; if I fix the Chinese characters on Linux, then they will not be displayed on Windows.

Is there any way force LabVIEW use the same encoding format on both systems?

[ensegre]

You display a NI badge and you're asking this from us??? What is this, a joke? Anyway, the problem is solved for NXG and so there is no need to ask further.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Support-Unicode/idi-p/921449

 

 

 

[Q^Q]

Thank you for your information!

It's not a joke. I was a NI employee 10 years ago.  The badge is still here, I just don't know how to update the badge.

 

[Q^Q]

The linked post didn't have an answer.  It looks like it just doesn't support unicode.  But from my recent experience, I can see why it is so difficult to support unicode in LabVIEW.  It is not just showing some characters on the FP or BD.  But the most difficult part is that many many LV projects have non-unicode VI names.  

This was what I encountered recently:  I had some projects that was using Chinese VI names.  They were built on a Windows that the default language for all non-unicode characters were Chinese.  I couldn't load any of projects either on Linux or on a Windows without Chinese as the default language.   This is because the same bytes of digits represent different characters on unicode and non-unicode systems, and LabVIEW rely on those characters to load a VI.

I suspect that if LabVIEW starts to support unicode, it will break all the projects that previously built on non-English characters.  

[ShaunR]

What ensegre is getting at is that LabVIEW has never (officially) supported unicode and at one point NI said they don't need to (in classic) because NXG supports it.

There are some UTF8 primitives that means you can support UTF8 internally but many of the controls and primitives don't support it (like the file control and functions). For that you have to have replacement windows file functions but that will not help you loading projects and is not cross-platform.

[Rolf Kalbermatter]

On 12/30/2021 at 5:56 PM, ShaunR said:

What ensegre is getting at is that LabVIEW has never (officially) supported unicode and at one point NI said they don't need to (in classic) because NXG supports it.

There are some UTF8 primitives that means you can support UTF8 internally but many of the controls and primitives don't support it (like the file control and functions). For that you have to have replacement windows file functions but that will not help you loading projects and is not cross-platform.

To precise: NI uses whatever is the locale on the machine. For Windows this is typically the normal single byte codepage for most western installations and the multibyte codepage for some of the asian languages. So LabVIEW can in principle deal with multibyte encoding.

Linux since many moons has defaulted to UTF-8 as default locale for the desktop for most standard distributions. UTF-8 being in fact another multibyte code standard, this means that LabVIEW on Linux by default uses UTF-8 by the virtue of pretty much completely transparent text handling in the OS standard C library. But there are areas in the LabVIEW code that have traditionally made certain hardwired assumptions that do not work well with multibyte character sets so you are bound to see weird effects sometimes.

All that said Windows does support a Beta feature since about Windows 7 that allows to set the locale to be UTF-8 instead of one of the standard codepages, but it is not for nothing still Beta. For some reason Microsoft did not feel that it warranted the necessary effort to try to iron out certain problems that still exist or it may be even pretty much impossible without more or less completely rewriting the Windows text APIs due to some deeply ingrained code assumptions.

Also LabVIEW certainly is not without blame. The code dealing with text handling was mainly written in the beginnings of the 90ies of last century at a time where Windows only had codepages and Unicode UTF-16 support was still an optional feature that you had to install explicitly and was working by using a completely separate API rather than trying to shove a multibyte encoding based on the Unicode standard under the traditional text management. As such while there might be certain code sections under Linux that deal with the UTF-8 encoding more appropriately, this need hasn't arisen on Windows before NI decided to embark on the NXG adventure and pretty much deferred all improvements on existing code features in LabVIEW Classic to be solved in NXG. With NXG gone they basically have a 10 year catch up game to do.

 

 

Edited January 3, 2022 by Rolf Kalbermatter

[ShaunR]

8 hours ago, Rolf Kalbermatter said:

this need hasn't arisen on Windows before NI decided to embark on the NXG adventure and pretty much deferred all improvements on existing code features in LabVIEW Classic to be solved in NXG

We were asking for unicode support well before NXG was a twinkle in the milkman's eye. I'm sure if we searched this forum we would see that we've been moaning about it for at least the last 10 years. I certainly remember raising it when Delphi got full Unicode support and, IIRC, that was RAD Studio in 2008 but we were able to use it in Delphi before then if the OS supported it.

LabVIEW's problem has always been displaying Unicode, hence that hit & miss kludge in the ini settings (LabVIEW 8.x?). Since they never gave us the ability to create the proper controls/indicators, we were never really able to work around it.

Edited January 3, 2022 by ShaunR

[Rolf Kalbermatter]

20 hours ago, ShaunR said:

We were asking for unicode support well before NXG was a twinkle in the milkman's eye. I'm sure if we searched this forum we would see that we've been moaning about it for at least the last 10 years. I certainly remember raising it when Delphi got full Unicode support and, IIRC, that was RAD Studio in 2008 but we were able to use it in Delphi before then if the OS supported it.

That's about right. I mentioned the 10 year catch-up game NI has to do with LabVIEW. The full 64-bit compiler support in LabVIEW 2009 was one of the last architectural projects NI did with LabVIEW Classic. After that they did not really do much more than add some peripheral libraries, fix bugs and make minor improvements to core functionality of the LabVIEW kernel. Anything that was structurally touching the LabVIEW core code base was deferred to LabVIEW NXG.

Even the Map and Set datatype in LabVIEW 2019, while a great addition, was for the most part a completely separate code base that had literally no impact on the LabVIEW kernel in terms of needing any significant changes to it.

The problem NI had/has with much of the LabVIEW code base is that some of the most fundamental code modules come from a time about 30 years ago, when C++ was simply not an option at all, NI had to fight with symbol tables in the C compiler exceeding the compiler provided memory space and 8 MB of RAM in a computer was for many users considered an unacceptable minimum hardware requirement. This code is inherently C syntax, and littered with global variables that all had to be protected with mutexes when introducing multithreading in LabVIEW 5. LabVIEW NXG was about getting rid of that entirely by replacing the entire UI system with something more modern. In hindsight I think it was overambitious and NI underestimated the impedance mismatch between the .Net environment and the LabVIEW system and didn't anticipate the vocal push back from non Windows users about the fact that LabVIEW on top of .Net was likely never going to support anything other than Windows, despite their repeated claims that it COULD be made to work on other platforms. But COULD in lawyer speak usually means WON'T and a lot of those non-Windows users are academics who know a thing or two about language semantics too.

Edited January 4, 2022 by Rolf Kalbermatter

[hooovahh]

On 1/3/2022 at 12:59 PM, ShaunR said:

We were asking for unicode support well before NXG was a twinkle in the milkman's eye. I'm sure if we searched this forum we would see that we've been moaning about it for at least the last 10 years.

I agree that people have been asking for unicode support in LabVIEW for a while.  But there's a good chance NXG development definitely started more than 10 years ago.  The first alpha available for people outside of NI was around 2013.  And the Web UI Builder was showcased at NI Week 2010, which has some core components of what NXG would become.

[hooovahh]

On 12/30/2021 at 10:51 AM, Q^Q said:

I was a NI employee 10 years ago.  The badge is still here, I just don't know how to update the badge.

I'm not sure how to change this either, I'll contact the site admin.