ci: use windows 2025 runners

[ShortDevelopment]

windows-2019 actions are unsupported as of 30.06.2025.

This PR updates the ci-config to run on the supported versions of the windows runner:

• windows-2022 → windows-2025
• windows-2019 → windows-2022

💥 Breaking changes

• The default CC configuration on windows used the WinGlob api.
  This config is broken on recent versions of Windows 11 as CC does not initialize WinRT using RoInitialize to allow for some optimizations.
• CC now uses the version of libICU that is shipped with Windows by default
  This removes compat of the default config with all windows versions < Version 1903 (May 2019 Update)
  Should be fine as Windows 10 is out-of-support anyway...

🧪 Tests

• Tests did assume win32 => WinGlob; that is obviously wrong now.
• Some baselines were WinGlob only => updated
• libICU did return incorrect values so two tests were disabled => fixed
  The "new" behavior is consistent with recent node.js and bun.js
  • Intl: platform.normalizeLanguageTag does not correctly handle valueless unicode extensions #4490
  • Intl: Investigate different behavior between engines on CanonicalizeLocaleList #2964

---

See actions/runner-images#12045
Fixes #7045
Fixes #4490

[rhuanjl]

So, the Windows globalisation implementation doesn't work on latest windows AND the ICU alternative fails too, weirdly the test runner seems to be crashing out after one of the fails rather than finishing and saying how many tests failed.... that is awkward.

A couple of test fails look like things that are may be fairly easily fixable e.g. ICU version mismatches to amend tests for or inconsistent conditions in the test suite that expect windows to not be ICU etc. Hopefully it's not overall too big a job but I have no setup I can work on this on.

[ShortDevelopment]

I'll look into this in the next view weeks

[rhuanjl]

The windows-2019 test runners are now disabled.... So all CI runs now fail.

[ShortDevelopment]

See History of changes to the ICU library in Windows.

[rhuanjl]

Would it be possible to do version detection and build with the older libs if someone is building on older windows? I know we can't test it but may be helpful to someone.

[ShortDevelopment]

If you decide to support this config I could add another build-flag or detect the config based on the current windows version.

[rhuanjl]

@ppenzin what do you think of this?

Previously we used Windows Globalisation on windows for the support we use ICU for on Linux and macOS.

• I have long hoped we could standardise on ICU to avoid this platform difference.
• A recent windows update broke CC's use of Windows Globalisation, we could fix it but it seemed an opportune time to instead switch windows to ICU.
• BUT from May 2019 onwards windows has shipped with a single DLL for ICU before that it was two DLLs if we build expecting the single DLL (as per this PR) we don't support those older (unsupported) versions of windows

[ppenzin]

Would it be a big change to try to detect if one or two DLLs needed? I would lean towards having the check, but if additional logic makes configuration too complicated, I this we should be OK breaking older versions.

[ShortDevelopment]

Adding a check would be very easy using the Exists condition in MSBuild. I would simply check if the newer icu.dll exists in System32 and use that instead of the older two if available.

The actual problem is that we might start using apis in the future that won't be available in either of the older two libs.
And we won't get any ci failures for that as we're not running ci on such old windows version.
(This PR is because win-2019 is no longer supported on Azure after all)

[ShortDevelopment]

I'm now checking for the existence of icu.dll in the System32 folder of the machine we're building on (See e661393).
This checks if we are buildin on a machine that supports the "new" libicu not whether we compile against a version of windows, that supports it.

[rhuanjl]

@ppenzin What do you think? This fixes INTL on windows newer than the May 2019 Update but breaks it on older versions - though the key change is just build config we could perhaps document how to build the older version?

[rhuanjl]

Thank you for the work on this. Hoping we'll merge it within a week though I have a few questions - see comments.

[rhuanjl]

Would it be possible to do version detection and build with the older libs if someone is building on older windows? I know we can't test it but may be helpful to someone.

[ppenzin]

LGTM; I am fine with either direction on detecting two DLLs vs one - it would be good to detect it, but not sure if additional logic is worthwhile.

[ppenzin]

Would it be a big change to try to detect if one or two DLLs needed? I would lean towards having the check, but if additional logic makes configuration too complicated, I this we should be OK breaking older versions.

[ppenzin]

LGTM