chore(windows): support Delphi 11/12 compilation + Delphi 12 CE dev workflow

[MattGyverLee]

Summary

Lowers contributor friction on #4599 (deprecate Delphi) by letting developers on the free Delphi 11 / 12 Community Edition tier compile the still-Delphi parts of the tree. None of the compiler / runtime stack moves; this is purely build-environment work plus narrow source-compat patches.

CI is unchanged: with KEYMAN_DELPHI_VERSION unset, every build script keeps using Delphi 10.3 (BDS 20.0) exactly as before. Every Keyman-owned source change is an additive VER350 / VER360 IFDEF arm; the existing VER330 paths are not touched.

Why this matters for the Delphi removal roadmap

Delphi 10.3 Pro is no longer obtainable, and CE 10.3 has been removed from Embarcadero's downloads. New contributors who want to help finish #4599 currently hit a wall: they can install CE 12, but CE blocks the dcc32 CLI that build.sh drives, and the tree itself doesn't compile cleanly against the modern Delphi RTL. This PR closes that gap without shifting CI off 10.3 — it's a bridge that makes the Delphi-side easier to chip away at, not a commitment to keep Delphi alive.

What's in the change

1. Build-script knob (CI-safe)

• resources/build/win/configure_environment.inc.sh and delphi_environment.inc.sh — DELPHI_VERSION now reads ${KEYMAN_DELPHI_VERSION:-20.0}. Default unchanged. CI doesn't set the var; nothing about the canonical 10.3 flow changes.

2. Delphi 11/12 source compat in Keyman-owned code

Five files under common/windows/delphi/. Every change is additive IFDEF arms for VER350 / VER360; the VER330 (10.3) paths are untouched. Each was hit by a real compile failure on Delphi 12 CE; the patch is the minimum needed to keep the existing code shape on 10.3 while letting it compile on 11/12.

File	Change	Why
tools/devtools/SourceRootPath.pas	Add VER350/VER360 → '22.0'/'23.0'	DelphiMajorVersion needs to know about the new BDS install dirs
web/Keyman.System.HttpServer.Base.pas	Extend the IFNDEF VER330 tripwire to also accept VER340/350/360	Existing comment says "may need to check this with updated versions of Delphi" — this is that check
components/FixedTrackbar.pas	Same tripwire extension	Same pattern as above
general/CleartypeDrawCharacter.pas	EnumFontFamiliesEx integer-return comparison on VER340/350/360 (was VER340-only)	The Win32 wrapper return type changed in 10.4+; existing guard only covered 10.4
general/JsonUtil.pas	Pass [] options arg to TJSONAncestor.ToChars on VER350/360	Delphi 11+ added a required Options parameter

Plus windows/src/engine/engine.groupproj: drop the inst\insthelper reference. The path doesn't resolve — insthelper.dproj lives at windows/src/engine/insthelper, not .../inst/insthelper — and IDE "Build All" was failing on it. build.sh-based builds were never affected because they don't walk the groupproj.

3. Vendored third-party patches (please look here first)

⚠️ This is the highest-risk piece of the PR. Three files under developer/src/ext/. Each hunk is annotated with a // Keyman local patch comment plus a refresh strategy noting the upstream package and what to re-apply when those projects ship Delphi 12-compatible releases.

File	Change	Why
jedi/jcl/jcl/source/common/JclSynch.pas	Wrap Boolean args to CreateEvent / OpenEvent / CreateWaitableTimer / OpenWaitableTimer / OpenSemaphore / CreateMutex / OpenMutex in explicit BOOL(); switch JclWin32.CreateMutex → Winapi.Windows.CreateMutex	Delphi 12 tightened implicit Boolean→BOOL conversion at call sites. BOOL() is an ordinal-preserving typecast, equivalent to the implicit conversion 10.3 was doing — no runtime semantic change. The CreateMutex unit-resolution switch matches the file's existing pattern for the other Winapi calls
jedi/jvcl/jvcl/run/JvComponent.pas	On VER350+, unconditionally call DoCreate	Embarcadero removed the OldCreateOrder property in Delphi 11; the modern default is equivalent to OldCreateOrder=True
mbcolor/mxs.inc	Add VER350/VER360 blocks defining DELPHI_5_UP … DELPHI_10_UP	Without these, HTMLColors.pas silently drops Variants from its uses clause and breaks with "Undeclared identifier: 'null'"

The annotations point future contributors back at the patched hunk when those projects bump (and let a reviewer audit the local delta cleanly).

4. Docs + helper scripts

• docs/build/windows.md: one-line pointer to windows-d12.md from the existing "Delphi 10.3 CE no longer available" warning, so future CE users find the workaround instead of dead-ending.
• docs/build/windows-d12.md: ~990-line guide — prerequisites, registry library-path setup, source patches, the canonical build order (including the tsysinfox64 → .bin → tsysinfo_x64.res chicken-and-egg), install-and-overlay workflow, debugging, troubleshooting catalog, and a section labeling which patches are safe to upstream.
• windows/scripts/preflight-resources.ps1 — runs rc.exe over every .rc, generates manifest.xml from manifest.in. Equivalent of build.sh's _prebuild_resources phase.
• windows/scripts/run-codegen.ps1 — drives devtools.exe + build_standards_data.exe plus the tsysinfox64 chicken-and-egg.
• windows/scripts/overlay-dev-builds.ps1 — copies dev binaries onto an installed Keyman 19 (equivalent of build.sh install; needed because TKeymanPaths.KeymanDesktopInstallPath() is hardcoded to Program Files).
• windows/scripts/install-build-env.ps1 — one-time toolchain installer.

All four PowerShell scripts auto-detect the repo root via $PSScriptRoot (two levels up from windows/scripts/) and honor $env:KEYMAN_ROOT as an override, so they work from any clone path.

• .gitignore: patterns for per-arch version*.res, meson wraplock files, and the per-script log files that the helper scripts write.

Reviewer notes

• The vendored ext patches in section 3 are the only place real behaviour potentially shifts. The intent is no runtime change — every cast is value-preserving, and OldCreateOrder=True is what Delphi 11 already does by default. But that's the spot most worth a second pair of eyes.
• The helper scripts intentionally live under windows/scripts/ (not at repo root) to match the existing component-local-helpers convention.
• The engine.groupproj fix is independent of the Delphi-12 work and helps any IDE-driven build — it was just discovered while doing this.
• Untouched on purpose: the compiler stack (kmcmplib, kmc-*, developer/src/kmc-*, Keyman Core). Those are already Delphi-free per chore(windows): Deprecate use of Delphi #4599 progress and shouldn't be in this PR's blast radius.

User Testing

User testing not required: build-environment / docs change with no runtime behaviour modification. CI will exercise the 10.3 default path; CE flow is manually validated via the steps in docs/build/windows-d12.md.

Relates-to

Relates-to: #4599

[keymanapp-test-bot]

User Test Results

Test specification and instructions

ERROR: user tests have not yet been defined

[keyman-server]

This pull request is from an external repo and will not automatically be built. The build must still be passed before it can be merged. Ask one of the team members to make a manual build of this PR.

[mcdurdin]

Thank you for this contribution. A couple of thoughts:

1. We don't want to add powershell scripts to the repo -- it's just more maintenance and difference and they will get out of sync over time with the main shell scripts. Changes need to be built into the existing build.sh scripts.
2. It would be better to make the Delphi 10.3 changes and the CE-build-chain support as two separate PRs, both for reviewability, and for rollback and maintenance.

[MattGyverLee]

1. We don't want to add powershell scripts to the repo -- it's just more maintenance and difference and they will get out of sync over time with the main shell scripts. Changes need to be built into the existing build.sh scripts.

I'm happy you're considering adding it to the repo. :)

I'll have to think on this. Implementing this in build.sh wasn't my expectation since the powershell scripts are a workaround to not being able to automate the Delphi parts of the build.sh. Nevetheless, gating this new code by Delphi version and making it interactive (Please build XX.dproj manually in the IDE now.) should work.

2. It would be better to make the Delphi 10.3 changes and the CE-build-chain support as two separate PRs, both for reviewability, and for rollback and maintenance.

Makes perfect sense.

[MattGyverLee]

Duh... The 12 upgrades would allow you to upgrade the build server and any paid desktop licenses (which you probably have) in the future.

The CE workarounds are just for us cheapskates.

Makes perfect sense. I'll see what I can do.

[mcdurdin]

Nevetheless, gating this new code by Delphi version and making it interactive (Please build XX.dproj manually in the IDE now.) should work.

Yes; we could do the same thing in .sh scripts, and I'd prefer that so there's only one set of instructions needed with minor tweaks for CE. When using CE, building the .groupproj files reduces the manual steps by making only 4 builds I think (there are 7 .groupproj files but only engine, desktop, developer are needed, plus building and installing the design time components, which is currently fragile anyway 😢), so could think about that?

[MattGyverLee]

Closing per @mcdurdin's review — split into two PRs:

• chore(windows): Delphi 11/12 source compatibility #16043 — chore(windows): Delphi 11/12 source compatibility. The additive VER350/VER360 IFDEF arms, vendored-ext patches, and KEYMAN_DELPHI_VERSION knob. CI default is unchanged.
• feat(windows): Delphi CE interactive build workflow #16044 — feat(windows): Delphi CE interactive build workflow. The KEYMAN_DELPHI_CE=1 interactive delphi_msbuild shim (replacing the PowerShell helpers from the original revision), the renamed windows-delphi-ce.md guide, and the orthogonal engine.groupproj cleanup.

The PowerShell helper scripts that prompted the original feedback are gone in #16044; the CE workflow now runs through KEYMAN_DELPHI_CE=1 ./build.sh. #16044 depends on #16043 for the source-compat patches.