Implementing JEP 400 on Windows 10 and Windows 11

Bernd Eckenfels ecki at zusammenkunft.net
Tue Oct 5 10:02:47 UTC 2021


I think the last sentence was missing a „not“ and referring to the same manifest?

However the results are a bit of a mess, but utf-8 handling for argv would be great plus (if converted correctly), right?


--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Gesendet: Tuesday, October 5, 2021 10:34:26 AM
An: John Platts <john_platts at hotmail.com>; core-libs-dev <core-libs-dev at openjdk.java.net>
Betreff: Re: Implementing JEP 400 on Windows 10 and Windows 11

On 2021-10-05 03:22, John Platts wrote:
> I wrote a test program (in C++) to detect the codepages that would be returned by the GetACP(), GetOEMCP(), and GetConsoleCP() functions when the <utf8:activeCodePage>UTF-8</utf8:activeCodePage> setting is added to the manifest.
>
> The <utf8:activeCodePage> manifest element (supported on Windows 10 Version 1903 or later) is in the http://schemas.microsoft.com/SMI/2019/WindowsSettings namespace and is added to the asmv3:WindowsSettings element as shown below:
> <asmv3:windowsSettings xmlns:dpi1="http://schemas.microsoft.com/SMI/2005/WindowsSettings"
>                         xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings"
>                         xmlns:utf8="http://schemas.microsoft.com/SMI/2019/WindowsSettings">
>      <dpi1:dpiAware>true/PM</dpi1:dpiAware>
>      <dpi2:dpiAwareness>PerMonitorV2, PerMonitor, system</dpi2:dpiAwareness>
>      <utf8:activeCodePage>UTF-8</utf8:activeCodePage>
> </asmv3:windowsSettings>
>
> Here is the output of the test program without the <utf8:activeCodePage>UTF-8</utf8:activeCodePage> setting present in the executable manifest:
> GetACP() result:       1252
> GetOEMCP() result:     437
> GetConsoleCP() result: 437
> System default LCID:   1033
> User default LCID:     1033
> User default UI LCID:  1033
> Codepage from system default LCID:  1252
> Codepage from user default LCID:    1252
> Codepage from user default UI LCID: 1252
>
> Here is the output of the same test program with an executable manifest that includes the <utf8:activeCodePage>UTF-8</utf8:activeCodePage> setting:
> GetACP() result:       65001
> GetOEMCP() result:     65001
> GetConsoleCP() result: 437
> System default LCID:   1033
> User default LCID:     1033
> User default UI LCID:  1033
> Codepage from system default LCID:  1252
> Codepage from user default LCID:    1252
> Codepage from user default UI LCID: 1252
>
> Note that the <utf8:activeCodePage>UTF-8</utf8:activeCodePage> setting in the application manifest changes the results of the GetACP() and GetOEMCP() calls but not the GetConsoleCP() call.
This is really confusing. I'm glad you are gathering empirical evidence
of how it works. :-)

> I wrote another test program, and the argument strings passed into the main(int argc, char** argv) function are converted to UTF-8 if the <utf8:activeCodePage>UTF-8</utf8:activeCodePage> setting is there in the application manifest whereas the argument strings passed into the main (int argc, char** argv) function are converted to the ANSI codepage (which is usually code page 1252 on US English systems) if the <utf8:activeCodePage>UTF-8</utf8:activeCodePage> setting is there in the UTF-8 manifest.

I'm not sure I understand this. What is the difference between "the
application manifest" and "the UTF-8 manifest"?

/Magnus


More information about the core-libs-dev mailing list