<i18n dev> RFR: 8337077: Java uses wrong Charset in System.out when running on MINGW

[Naoto Sato]

Hi Rostislav,

I am sorry but initializing Java runtime by checking if an application's 
own DLL is loaded or not is something the Java runtime should not do. 
That won't even work with Cygwin, or other Unix like shells. The only 
option I would see is again check the POSIX environment variables 
(regardless of the shell) and use it, but I don't think that is a viable 
option as I wrote in the previous email.

Naoto

On 8/23/24 3:56 PM, Rostislav Krasny wrote:
> On Tue, 20 Aug 2024 at 19:34, Naoto Sato <naoto.sato at oracle.com 
> <mailto:naoto.sato at oracle.com>> wrote:
> 
>     Hello,
> 
> 
> Hello Nato. Nice to meet you.
> 
>     As I commented in the bug report, I closed the issue as "not an issue",
>     as LC_* environment values on Windows has never been supported (or even
>     considered) as a means to set locale/encoding as the way POSIX does. It
>     would create some inconsistent state between Windows' locale settings
>     which may cause some unexpected behavior in applications.
> 
> 
> We are talking not about the whole Windows but only about the MSYS2/ 
> MINGW console that has its own support of UTF-8 that is enabled by 
> default. We also are talking about a console encoding exclusively and 
> not about any other locale parameter. The MSYS2/MINGW console is widely 
> used by many developers on Windows because of the Git popularity and the 
> Git for Windows project that comes with the MINGW64 variant of MSYS2, 
> including its UNIX-like console with UTF-8 enabled by default. Many 
> software engineers use that console not just for running Git commands 
> but also for doing many other things, including running Java console 
> applications. There are some developers who use the MSYS2 project 
> directly and also may run Java applications inside the MSYS2 console.
> 
> The LC_* environment variables are defined by MSYS2 only and not by 
> Windows. The same is also true about  the OSTYPE and MSYSTEM environment 
> variables. The only problem using OSTYPE or MSYSTEM to identify MSYS2 in 
> Java could be if cmd.exe is started from the MSYS2 console. In this case 
> that cmd.exe process will inherit all environment variables, including 
> the above that were set by MSYS2 previously. But practically I don't see 
> any reason for anybody to run cmd.exe from MSYS2 console.
> 
> Ok but there is another way to identify that your process is running 
> under MSYS2 by another, probably a more reliable way. You can find your 
> parent process and check what DLLs it has loaded. If it has msys-2.0.dll 
> loaded then your process is running under MSYS2 and not under cmd.exe 
> even if that cmd.exe was started from MSYS2. Please take a look at the 
> attached PoC code made by ChatGPT.
> 
> Example of how this PoC works after it was built by Visual Studio 2022 MSVC:
> 
> $ ./stam01.exe
> Parent Process ID: 1460
> Parent Process Name: bash.exe
> Parent Process Full Path: C:\Program Files\Git\usr\bin\bash.exe
> Loaded DLLs in Parent Process (ID: 1460):
>          C:\Program Files\Git\usr\bin\bash.exe
>          C:\Windows\SYSTEM32\ntdll.dll
>          C:\Windows\System32\KERNEL32.DLL
>          C:\Windows\System32\KERNELBASE.dll
>          C:\Windows\System32\USER32.dll
>          C:\Windows\System32\win32u.dll
>          C:\Program Files\Git\usr\bin\msys-2.0.dll
>          C:\Windows\System32\GDI32.dll
>          C:\Windows\System32\gdi32full.dll
>          C:\Windows\System32\msvcp_win.dll
>          C:\Windows\System32\ucrtbase.dll
>          C:\Windows\System32\advapi32.dll
>          C:\Windows\System32\msvcrt.dll
>          C:\Windows\System32\sechost.dll
>          C:\Windows\System32\RPCRT4.dll
>          C:\Windows\System32\bcrypt.dll
>          C:\Windows\SYSTEM32\CRYPTBASE.DLL
>          C:\Windows\System32\bcryptPrimitives.dll
>          C:\Windows\System32\IMM32.DLL
> Parent process has msys-2.0.dll loaded. Running under MSYS2.
> 
> D:\develop\cpp-tryouts\x64\Debug>stam01.exe
> Parent Process ID: 13016
> Parent Process Name: cmd.exe
> Parent Process Full Path: C:\Windows\System32\cmd.exe
> Loaded DLLs in Parent Process (ID: 13016):
>          C:\Windows\System32\cmd.exe
>          C:\Windows\SYSTEM32\ntdll.dll
>          C:\Windows\System32\KERNEL32.DLL
>          C:\Windows\System32\KERNELBASE.dll
>          C:\Windows\System32\msvcrt.dll
>          C:\Windows\System32\combase.dll
>          C:\Windows\System32\ucrtbase.dll
>          C:\Windows\System32\RPCRT4.dll
>          C:\Windows\SYSTEM32\winbrand.dll
>          C:\Windows\System32\bcrypt.dll
>          C:\Windows\System32\sechost.dll
> Parent process does not have msys-2.0.dll loaded. Likely running under 
> native Windows.
> Once you have found that your parent process has msys-2.0.dll loaded, 
> you can safely check the LC_* environment variables.
> If the parent process doesn't have msys-2.0.dll loaded, continue to 
> identify the console encoding as you do it now.
> 
>