The DLL is already on my computer. It's on every computer with Windows. If you were going to send anything, maybe you could send the .lib file that is being statically linked, except I already know what is in it: undocumented garbage. I'm not going to reverse engineer their code, I'm just going to isolate it to the function in question, then debug it to the point where it stops functioning as advertised, and Microsoft never officially advertised that setlocale() would ever work with UTF-8. In fact, the most recent non-fake news is that Microsoft will release a version of setlocale() that will work with UTF-8, but only for Win10 ...
"As of Windows Version 1903 (May 2019 Update), you can use the ActiveCodePage property in the appxmanifest for packaged apps, or the fusion manifest for unpackaged apps, to force a process to use UTF-8 as the process code page" (https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page) The function of setlocale() is to set the code page for a local process, so if setlocale() actually could already support UTF8, why the need for the "update" as officially described above? The fact that you could get setlocale(), or some version of it to work, doesn't mean it was supposed to work, it means it was a mistake or a loophole that MS never intended you to use. Stick to the documentation and not the anomalies. Anyways, that is why I'm not really keen on the idea of using setlocale(), even if I could get it to work, because "getting it to work" means it would have to be a hack job. Best Regards, Andrew PS -- By the way, Haiku is really good with international apps -- maybe you should think of porting IUP to a really good and consistently documented OS like Hailku (32- and 64-bit versions)? On 2020-05-06 at 8:00 AM, Antonio Scuri <antonio.sc...@gmail.com> wrote: All the programs I sent you are intentionally statically linked with the run time library, except the mingw version. To avoid I have to send you the respective DLL. No, each Visual Studio now uses a different msvcrt.dll. I uploaded the same samples built to use the run time in a DLL: http://webserver2.tecgraf.puc-rio.br/~scuri/tmp/setlocale_utf8_dll.zip Best, Scuri Em qua., 6 de mai. de 2020 às 10:32, Andrew Robinson <arobinso...@cox.net> escreveu: Hi, VS2017 calls a static library while the rest of your programs make a dynamic library call to msvcrt.dll. The code in the static library is much different from the code for setlocale() in the msvcrt.dll. Since I do not have VS2017 on my computer, can you change the default command line parameter/compiler option of VS2017 to switch from making static calls to making calls to a dynamic library? Every version of VS is different from the last one, so I can't tell you how to do that, but I do know that somewhere in VS2017 should be a setting for determining whether an external function should come from a static library or should it be a call to a dynamic library. If you force both programs to do the same thing, then they should act the same way. That in a nutshell is what is going on with your programs. .... but ... The *official* documentation for setlocale() on Microsoft's online help and the help file in their compiler never says they directly support UTF8. What you read online was an unofficial comment and not an official statement. .... but ... You can directly call setlocale() in the msvcrt.dll with the VS2017 program and get consistent results that way, and while that sounds nice, it is only nice so long as MS doesn't suddenly do something in the future to make it so even that doesn't work. Regards, Andrew On 2020-05-01 at 3:11 PM, Antonio Scuri <antonio.sc...@gmail.com> wrote: Hi, I wrote a test that don't even use IUP, just to test fopen with UTF-8. It is attached. I found out that it worked using setlocale only in Visual Studio 2017. It seems to be a new feature. I decide to describe this in the IUP documentation: --------------------------------------------------------------------------------------------- Notice that IUP, CD and IM libraries use the fopen based functions to read and write files. In Windows fopen expects the filename string in the ANSI encoding by default. If your filename, including the path, has characters that can not be converted to ANSI, fopen will fail to open the file. In Windows we could use _wfopen combined with UTF-8, but this is a Microsoft only function and most of fopen usage in these libraries are in portable modules. This is an IUP limitation in Windows. The simple workaround is to not use special characters in folders or files name in Windows... Legacy applications will also have the same problem. Another option is to call: setlocale(LC_ALL, ".UTF8"); But it will work for fopen only in Visual Studio 2017 or newer Microsoft compilers (setlocale will return NULL on other compilers). fopen will successfully open the file if filename is an UTF-8 string, even with special characters. So you will be able to set both UTF8MODE and UTF8MODE_FILE to YES. If you decide to use this feature, another interesting option is to set the console code page to UTF-8 executing "chcp 65001" on the command line. This will allow your printf output to be properly displayed when using UTF-8 strings. This feature actually works for all Microsoft compilers in Windows, and for MingW, even when setlocale returns NULL. Notice that some font packages must be installed for this to fully work for all characters (for instance Chinese, Japanese and Korean, along with some symbols too). --------------------------------------------------------------------------------------------- Yes, this is all an IUP limitation because its external API do not support Unicode. I also fixed a bug in IupConfig to handle the case where the system folder has special characters, but they can be converted to ANSI. I was not doing that conversion. Just committed to the SVN. Best, Scuri Em ter., 11 de fev. de 2020 às 22:14, Andrew Robinson <arobinso...@cox.net> escreveu: Hi Antonio, The following code: config = IupConfig(); IupSetAttribute(config, "APP_NAME", "xyz"); IupConfigLoad(config); only seems to work if the current directory has no atypical (non-English) characters in it, e.g. -- "E:\My\Files" vs "E:\My…\Files". I am using the English version of Windows with code page 1252. Iup crashes at IupConfigLoad within the function IupLineFileClose. The character "…" is Unicode codepoint 2026 (which translates to UTF-8 as 0xE2 0x80 0xA6). Regards, Andrew
_______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
