LabVIEW
Unicode characters in file names
You are mixing and matching different things together here.
Saying that the OS is Russian most likely means for you that the user installed a Russian version of Windows. That will mean that all messages and some program names will be in Russian as well as the texts you see in your command line tool for Windows built in tools,
You still can configure that Windows system to use the Western European codepage 1252 instead of the Cyrillic codepage 1251 (provided the codepage support is installed).
The whole thing is made more complex since nowadays you don't really configure the codepage directly anymore but you configure a country, which determines your default codepage inherently and then you can go and add a list of other languages you would want to have available in your system, which will among other things also define additional codepages that an application could use. However there are not many applications which can use more than one codepage at the same time. The API for that is involved, badly documented and made kind of obsolete with Unicode support since an application compiled to be fully Unicode will not have to deal with this very much.
In a modern system it should be possible to configure additional languages in the Windows regional settings such as Russian (Cyrillic) and then install the Russian variant of LabVIEW (if it existed) and LabVIEW would handle everything as it was running on a native Russian system since Windows will see that the executable was created for the codepage 1251.
Please note that I don't have much experience with creating multilingual applications beyond Western European languages. So I can't really give you detailed answers to your specific questions.
Your first question should be pretty easy to test and answer yourself. I believe the default paths will be in latin charset but nobody will hinder you to create then new directories and filenames that use the Cyrillic charset since that is now what your keyboard is set to use too.
LabVIEW is not latin. LabVIEW is English, German, French, Japenese or Chinese (Simplified). This only is really relevant as far as the titles, menus, help files and such things are concerned. What characters LabVIEW will use for filenames that you create, for instance by typing them in a path control or inside the file dialog will be determined by your local language settings in the Windows Control Panel.
The LabVIEW path control will simply accept whatever the user types in and since his current language setting is Russian it means the Cyrillic codepage 1251 will be used so the characters of that code page will be visible. If you want to avoid the possibility that your user can not select a file that you ship with your application in the file dialog box you will need to make sure to limit any and every character in those files to the ASCII 7 bit characters. Same would apply for VI files that you try to load dynamically at runtime since otherwise the string on your diagram will be interpreted in the current local, then passed to Windows to be translated to Unicode to access the file, which now will not match with the Unicode name stored on disk during installation.
At least the path datatype could have been made to support Unicode filenames years ago, since its internal data structure is only documented to be an opaque datatype, so the only problem would have been for the Flatten and Unflatten function which would have required an extra option to define if any path should be flattened to the old ASCII local dependent format or a new Unicode (most likely UTF-8) format. But the according change would have been a serious engineering task with quite a few possible side effects that would have likely taken 4 or 5 LabVIEW version iterations to be ironed out. I guess the introduction of a project space in 8.0 together with making all file operations work on more than 2GB files and LabVIEW classes in 8.2 were already such a resource drain that this would not have been possible to add also. All these things required several LabVIEW versions before they were really stable and usable. Bad luck as some would say 🙂
The problem is that Unicode in LabVIEW is not officially supported because it is not a seamless thing to do. For pure UI things it mostly works since there are only Strings but as soon as it interacts in any way with your programming logic it goes quickly bad. That includes anything that has to translate in any way between Unicode and non Unicode characters such as paths, any flattened data and so on.
Paths in LabVIEW are no Unicode yet, so here you have a problem. Changing paths to use internally Unicode would be possible but there would be many problems whenever it needs to be converted to anything else than paths, like path to string and such. Or when paths get stored in flattened format inside VI resources.
So you want to use the Unicode feature in LabVIEW, which is not officially supported because there are many areas where it simply doesn't work seamless. And a lot of them are very hard to fix and sometimes simply impossible if you don't want to completely throw out compatibility with earlier versions of LabVIEW.
Someone at NI made a decision that because there is basically no way to cleanly support Unicode in current LabVIEW without breaking compatibility with earlier versions, and there are also a lot of edge cases that require a very substantial work effort to fix them, Unicode is not going to be an official feature for the time being. With LabVIEW NXG now out, which is for the UI part pretty much tied to .Net now, that Unicode support comes a lot easier and the compatibility issues with earlier LabVIEW versions are more or less moot because there are already many areas where you have to go and check and adapt code when upgrading old LabVIEW code to LabVIEW NXG anyways.
Basically the current Unicode support in LabVIEW will remain what it is (a not officially supported feature with its limitations) and if seamless Unicode support is something you absolutely need to have, you will have to check out LabVIEW NXG and assess its suitability for your application. With the next LabVIEW NXG 2.0 release this should start to get feasible for quite some applications although it will take some more time before LabVIEW NXG will be able to handle everything that current LabVIEW can do now.
The drawbacks of LabVIEW NXG besides that it can't currently do everything current LabVIEW can do, is that it is most likely not going to be available for any desktop platform other than Windows 64-bit. But that is likely not a big problem for more than 90% of the users since most use LabVIEW only on Windows anyways.
