I was actually referring to the
src/java.base/windows/native/launcher/java.manifest file (or the
jdk/src/windows/resource/java.manifest file on JDK 8) that gets embedded as a
manifest in the JDK executables.
When I was mentioning "UTF-8 manifest", I was referring to the java.manifest
file (embedded as a resource in JDK executables) that had the
<utf8:activeCodePage>UTF-8</utf8:activeCodePage> setting added.
Here is what the java.manifest file would look like with the
<utf8:activeCodePage>UTF-8</utf8:activeCodePage> setting enabled:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0"
xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"
>
<assemblyIdentity
name=""
version=""
processorArchitecture="X86"
type="win32"
/>
<description>Java(TM) SE process</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<!-- Identify the application security requirements. -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<!-- Indicate JDK is high-dpi aware. -->
<asmv3:application>
<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>
<!-- Enable UTF-8 as the active code page -->
<utf8:activeCodePage>UTF-8</utf8:activeCodePage>
</asmv3:windowsSettings>
</asmv3:application>
<!-- Indicate this JDK version is Windows 7 compatible -->
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!-- Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!-- Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!-- Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
</application>
</compatibility>
</assembly>
________________________________
From: Magnus Ihse Bursie <[email protected]>
Sent: Tuesday, October 5, 2021 3:34 AM
To: John Platts <[email protected]>; core-libs-dev
<[email protected]>
Subject: 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
