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 <[email protected]
<mailto:[email protected]>> 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.
