Implementing JEP 400 on Windows 10 and Windows 11
John Platts
john_platts at hotmail.com
Wed Oct 6 12:33:26 UTC 2021
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 <magnus.ihse.bursie at oracle.com>
Sent: Tuesday, October 5, 2021 3:34 AM
To: John Platts <john_platts at hotmail.com>; core-libs-dev <core-libs-dev at openjdk.java.net>
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
More information about the core-libs-dev
mailing list