Would be nice ig it didnt drop support for anything before Malware 10 version 1903

Would be nice ig it didnt drop support for anything before Malware 10 version 1903

1. No need for the inflammatory language.

2. It shouldn’t: https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests#activeCodePage

   This element was first added in Windows 10 version 1903 (May 2019 Update). You can declare this property and target/run on earlier Windows builds

it didnt drop support

It doesn't drop anything, as there was no support for Unicode (i.e. legacy -W API conversion) for Windows in libjxl tools to begin with. This at least adds UTF-8 for Windows 10 1903 and later. On earlier Windows versions it continues working just the same as today, i.e. ASCII only.

Let me rephrase, maybe add something that works before 1903?
Because I run it and still cant read image data , in my case it has some chinese and Tiếng Việt chars)

Let me rephrase, maybe add something that works before 1903? Because I run it and still cant read image data , in my case it has some chinese and Tiếng Việt chars)

There's no 'something' if you use Windows that is older than Windows 10 version 1903, other than patching the code to use -W API, but that would mean a complete overhaul of the entire codebase.
You can, however, use a PowerShell script to temporarily rename the name of the files.

Get-ChildItem *.png,*.jpg | ForEach-Object {$name = $_.BaseName;Rename-Item -Path $_ -NewName ($_ -replace $_.BaseName,'a');cjxl -e 9 -d 1 "a$($_.Extension)" "a.jxl";Rename-Item -Path "a$($_.Extension)" -NewName "$name$($_.Extension)";Rename-Item -Path 'a.jxl' -NewName "$name.jxl"}

maybe add something that works before 1903?

To put things into perspective: this addition was almost trivial, around 20 lines (of configuration, not even code), and covers >96% of Windows users.

To cover the remaining <4% (and declining; also no longer supported by the OS vendor), the code changes required are non-trivial, need a more substantial developer effort and time, and can introduce new bugs that would need to be tested and addressed...

it didnt drop support

It doesn't drop anything, as there was no support for Unicode (i.e. legacy -W API conversion) for Windows in libjxl tools to begin with. This at least adds UTF-8 for Windows 10 1903 and later. On earlier Windows versions it continues working just the same as today, i.e. ASCII only.

He's not completely wrong, but like it's only an issue once you get to XP. The official release doesn't work on pre-7, but a build with clang can run just fine on XP, but it requires a change to the manifest.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <windowsSettings>
        <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
      </windowsSettings>
    </application>
  </compatibility>
</assembly>

Nevermind, apparently this breaks UTF-8 support on 10.