Use a different method to block support on Windows 8.1 (and future versions as needed)

Summary of the new feature / enhancement

Per the discussion in #18854, we can’t use any way - even via DLL custom action - in Windows Installer to properly block install on Windows 10 and newer (and whatever equivalent Server SKU…2019?) because of AppCompat shims that cause every version API - including RtlGetVersion and friends - to lie about the version. At best you can check for Windows 8.1 era SKUs.

Instead, we need a different way to block install as needed to prevent customers getting into a bad situation where PowerShell may not work - especially problematic if they just upgraded a version that did work.

Proposed technical implementation details (optional)

I discussed a couple options with @SteveL-MSFT offline, listed in preferred order:

1. I can write an EXE appropriately manifested that does not get shimmed by AppCompat (hopefully; it tends to be sticky). DLL custom actions get lied to because they run in an msiexec.exe host process which does get shimmed, but a separate EXE appropriately manifested and using RtlGetVersion could return 0 or 1 for supported or not supported, respectively. In this case, we’d probably just bake the requirements into the EXE rather than some way of passing an expression in, leading to potential overflows, etc. This could be built in the native repo and packaged along with other native binaries - consumed in the PowerShell/PowerShell repo.

2. Write a burn chainer using WixStdBA that provides a simple XAML-like syntax, but we’d have to port the existing MSI-based UI. Initially this wouldn’t be cheap, but may be slightly cheaper to maintain going forward that MSI-based UI authoring in Wix. IMO, the XAML-like grammar is a little easier to grok. But every package manager reference would have to be updated, so it’s not just the authoring cost but the cost of updating all the references; though, this would likely be a one-time cost. What’s unknown is how this would affect admin deployments that might assume the MSI, like any existing Active Directory deployments via GPOs. It also adds some amount - though relatively small - to the overall package size.

[heaths]

EXEs can also be distributed via WSUS, AD, etc. I wrote various extraction tools that took single- and multi-package chainers (Burn, or our previous chainers including those we’ve used since VS2005 and ~.NET 3.0) that would transpose is-installed and can-install logic. It’s doable, but still overkill if an EXE CA can avoid the version lies.

[stdin82]

What i ment is that Windows 10 update team is using that LaunchCondition how it’s undocumented? that registry value exist since WinXP